Co charakteryzuje Twój kod?
Profesjonalizm i elegancja. Staram się pisać sam kod w taki sposób, żeby nie wyróżniał się z tłumu — żeby jego styl i zastosowane konwencje były spójne z tym, co powszechnie przyjęte jest za dobre praktyki. Dzięki temu moje projekty nie powinny wygladać jak odrębny dialekt w porównaniu do kodu popularnych frameworków czy bibliotek.
Elegancja polega na tym, żeby trudne koncepty przedstawić w łatwy do zrozumienia sposób. Ale to również dyscyplina, więc brak „zagiętych rogów” wszelakiej postaci (niechlujne konstrukcje, haki, złe praktyki, code smells…).
Czym dla Ciebie jest projektowanie obiektowe?
Obiektówka, to podejście, które ułatwia stosowanie innych - istotnych dla jakości kodu — zasad czy technologii. Większość wzorców projektowych dotyczy modelu obiektowego; OOP ułatwia wprowadzenie takich elementów jak DRY, SOLID. Dobra obiektówka to również skuteczne narzędzie pedagogiczne dla juniorów. ;)
Czego nie lubisz w programowaniu? Każdy coś takiego ma ☺
Nie lubię systemów legacy. ;) I ogólnie pracowania z kodem czy ludźmi, którzy nie zauważyli literki „ć” w słowie „jakość” i są przekonani, że „jakoś to będzie”.
A poza tym — czasami nie jestem w stanie pojąć dlaczego niektóre rzeczy są bardziej skomplikowane niż powinny. Rozumiem przyczynę takiego stanu rzeczy, ale nie trafia do mnie dlaczego nie dąży się do ich upraszczania (mówię chociażby o bibliotekach, frameworkach czy infrastrukturze).
Czym dla Ciebie jest kod dobrej jakości?
„Dobra jakość” to przede wszystkim subiektywny stan rzeczy. Ale im wyżej w następujacej piramidzie wartości, tym lepiej:
- Przede wszystkim działa, czyli spełnia założenia biznesowe
- Jest bezpieczny, nie posiada rażących luk bezpieczeństwa
- Jest czytelny
- Objęty testami jednostkowymi (tak, dopiero na 4. miejscu)
- Elegancki — wykorzystujący ogólnie przyjęte zasady. Nie poświęcający prostoty i spójności dla innych wartości.
- Altruistyczny — stara sie dobrze współgrać z otoczeniem, a nawet pozostawić je w lepszym stanie niż je zastał. Niepospolity*.
Jakie widzisz plusy a jakie minusy stosowania spójnego stylu kodu źródłowego?
Zmniejszamy wysiłek poznawczy, czyli sam kod — w sensie literek i znaczków — staje się przezroczysty i w łatwiejszy sposób da się zrozumieć logikę, którą realizuje.
Naprawdę nie widzę praktycznych minusów. Zawsze co prawda znajdą się malkontenci, którzy nie rozumiejąc idei wspólnego coding style będą starali się wprowadzać swoje innowacje. Trzeba więc będzie im wytłumaczyć, że celem nie jest stworzenie najładniejszego czy najbardziej praktycznego stylu, ale właśnie spójnego, dlatego nie należy robić w nim odstępstw.
Wymaga to pewnej dyscypliny i kultury pracy, ale na szczęście od tego są narzędzia, które w większości mogą to zrobić za nas (PHP CodeSniffer, PHPStorm).
Po co dokumentować kod?
Trzy przykładowe, praktyczne zastosowania:
- Wzbogacanie kodu o metadane, które ciężko byłoby zrealizować przy pomocy samych konstrukcji języka (adnotacje, docblocki). W tym szczególnie dodawanie silnego typowania wartości zwracanych z metod (
@return). - Ostrzeganie zbłądzonych developerów przed ukrytym haczykiem, niestandardowym zachowaniem, bugiem lub inną pułapką, bez świadomości której gotowi byliby zacząć rzeczony fragment kodu poprawiać i oczywiście w tym zadaniu ugrząznąć na długie godziny bez zadawalających rezultatów.
Ukryta nadzieja, że któregoś dnia zobaczy się swój komentarz na stack overflow (mi osobiście zdarzyło się kiedyś zostawić ascii-artowego pieska w komentarzu)
/** a tu bedzie piesio: :) ^. .^ __ .) *BARK*- v \ '' "" **/
Oczywiście najlepszy kod to taki, który jest na tyle dobrze napisany, że nie potrzebuje dodatkowych komentarzy; często zamiast pisać eseje w docblockach wystarczy dokonać sprytnego refactoru.
Co poza programowaniem możesz wnieść w współtworzenie dobrej atmosfery współpracy?
Liczę na to, że będę miał szansę wpływać na kulturę i atmosferę przede wszystkim w sposoby inne niż poprzez programowanie. Wszak samo kodowanie jest rzeczą względnie obiektywną — tysiące ludzi na całym świecie robi to codziennie, czego efektem jest luźno przyjęty zbiór zasad i dobrych praktyk. Ja sam, jak ambitnie nie starałbym się do tego tematu podejść, mogę być jedynie kroplą w morzu.
Jeszcze w luźny sposób, w związku z samym programowaniem będę starał się być we wszelkich tych zasadach, dobrych praktykach i narzędziach na bieżąco, aby przekazywać tę w miarę obiektywną wiedzę reszcie zespołu. Do tej pory, nie chwaląc się ☺, idzie mi nieźle i planuję pozostać na tym torze.
W analogiczny sposób będę starał się eksperymentować (próbować) w kwestiach związanych z kulturą organizacji. Sprawdzać, czy takie modele jak np. #nomanagers mają szansę przynieść u nas jakieś korzyści. Czy netfliksowa kultura high performance ma praktyczne zastosowanie, itd.
Będę promował takie wartości jak transparentność oraz szczery i bezpośredni feedback.
No i przede wszystkim będę starał się być otwartą księgą i dawać od siebie dużo więcej, niż sam otrzymuję. Jestem całkiem dobrym nauczycielem (a z czasem i mentorem) i zależy mi na skutecznym przekazywaniu wiedzy: dostosowanym do odbiorcy, nastawionym na zrozumienie. To będzie prawdopodobnie moje podstawowe narzędzie w celu zwiększania efektywności zespołu i dążenia do jeszcze większego profesjonalizmu.
W sferze kulturalnej postaram się raczyć Was recenzjami filmów. ;) W sferze sportowej zabiorę zespół na laser taga, a jeśli się uda, to i na regularne mecze futsalu. Mam też nadzieję, że będę odrobinę szalony i w sam raz spontaniczny. :)
*Niepospolity:
Niepospolity człowiek pragnie pozostawić po sobie świat odmienny od tego, który zastał; świat lepszy, wzbogacony przez jego własną twórczość. Dla tego celu gotów jest poswięcić większość albo nawet wszystkie radości, którymi cieszy się człowiek pospolity.
— "Niedoskonali" A.N. i B.N. Strugaccy
Więcej na mój temat:
