Profesjonalizm zawodowych programistów

Witam piękne Panie i miłych Panów.

Mam takie myśli ostatnio. Sporo programuję zawodowo, nie od dawna ale jednak. No i takie myśli na mnie spadły czy jestem dobrym programistą. Chodzi o tak zwany "profesjonalizm" czy tam "dobre praktyki programowania" czy jak kto tam zwał. Nie pracuję w zespole tylko sam a rozliczany jestem za wyniki a nie za subtelność więc nie mam nikogo kto by krytykował mój kod. Zastanawiam się czy jestem chociaż w środku klasyfikacji tzw "dobrych" programistów.

Nakreślę mniej więcej jakim programistą jestem i powiedzcie czy macie podobnie czy całkiem inaczej. Chodzi mi szczególnie o opinie aktywnych zawodowo programistów. Wiadomo że na uczleni jest sporo kozaków którzy na pamięć znają wszystkiw wzorce i potrafią sortować ziemniaki w czasie O(n/2).

Więc wyglądam tak:

• Kodze ostatnio głównie w C#
• Nie używam raczej żadnych wzorców oprócz takiego użycia że sesję buduję przez jakieś factory udostępnione przez API bazy danych
• Czasem mam problemy z dobraniem nazw pól, klas etc.
• UML tworzę na kartce lub w głowie, 10% przed rozpoczęciem projektu a resztę w trakcie albo nigdy
• Jak np konstruktor struktury zgłaszał mi błędy że pola niezainicjowane to zamiast wgryźć się i rozwiązać problem, sprawę olałem i zamieniłem słowo struct na słowo class
• Nie szanuję procesora optymalizację mając daleko w tyle
• Soft tworzę raczej iteracjami a nie od zera do końca
• Tylko z teori wiem (i to nie do końca) co to agile, scrub, techniki wytwarzania oprogramowania i inne hasła korporacyjno socjalistyczne
• Inżynieria oprogramowania to coś co wydaje mi się ważne ale kurde nie mam czasu.
• Staram się pisać dokumentację na bieŻąco (Boże, widzisz takie błędy i nie grzmisz) odkąd odkryłem w Visualu xml-owskie tagi dla automatycznej dokumentacji ale jest ona trochę bez ładu i składu

Powiedzcie czy wy też macie takie podejście czy może przystępując do projektu wypluwacie z siebie tonami zgrabne kostrukcje typu
while(*dest++ = *src++)
jedną ręką pisząc kod a drugą dokumentację?

Powtarzam: nie chodzi mi o efekty waszej pracy jako soft. Bo takie u mnie są ok, tylko o sposób dojścia do celu.

Ankieta bardziej dla śmichu.

W kodzeniu w dużych zespołach (czyli zwykle korporacje). Wszystko rozbija się o standardy, które są stosowane po to by ułatwić życie osobie, która przejmie w przyszłości dany kod:

1. coding convention - czyli estetyka kodu, nazewnictwo metod, pól zmiennych, klas - co ułatwia czytanie kodu
2. dokumentacja i komentarze - np doxygen
3. testy jednostkowe - bardzo ważna sprawa, pokrycie kodu poniżej 50% oznacza kłopoty w przyszłości, a najlepiej jakby to było co najmniej 75%. Im większy projekt tym ważniejsze są testy jednostkowe. A dla kodu powyżej 5-10k linii to obowiązek nawet jeśli projekt robiony jest przez jedną osobę.
4. testy funkcjonalne (jeśli coś wymaga interakcji z użytkownikiem)
5. ...

Agile, Kanban to tylko taka moda na samo-organizujący się chaos w kodzeniu zespołowym, nic niezwykłego i nie wymaga specjalnego treningu.

Co do szablonów projektowych, to zależy. W większości ludzie stosują je nawet nie zdając sobie z tego sprawy. To po prostu kolejny standard, który ułatwia czytanie cudzego kodu (i pisanie nowego kodu też), więc warto je znać. Poza tym wpisując w komentarz "szablon taki a taki" upraszczasz dokumentację.

co do stosowania konstrukcji *dest++ to zdecydowanie NIE. W wielu przypadkach zaciemniają one czytelność kodu, więc poza standardowymi przypadkami, stosowanie ich jest zdecydowanie niewskazane (zwykle jest to częścią coding convetion).

nie chce mi się za bardzo wczuwać więc...

programujesz na tyle dobrze na ile Ci pracodawca pozwoli - tzn super jest, gdy jest ciśnienie na dobry kod. Zaczynając pracę w firmie która tego wymaga, uczysz się i po jakimś czasie masz to we krwi.

Jednak wydaje mi się, że w większości firm jest ciśnienie na szybkość implementacji - byle jak, byle było, byle na wczoraj. A, że później powoduje to płacz i opóźnienia przy nowych implementacjach........ z jednej strony mnie to wkurza bo nie jest zgodne ze sztuką i człowiek marnuje czas na walkę z wiatrakami - z drugiej powoduje, że praca sama się nakręca i jesteś potrzebny ; )

W temacie piszesz o profesjonalizmie, ale tak naprawdę w postach prawie w ogóle o tym nie widać. I jeszcze padają NIEprofesjonalne stwierdzenia, takie jak:

"programujesz na tyle dobrze na ile Ci pracodawca pozwoli"

To po prostu szczyt, kwintesencja nieprofesjonalnego (!) podejścia!

Profesjonalizm wiąże się przede wszystkim z ODPOWIEDZIALNOŚCIĄ. Programista, który jest profesjonalny, po prostu tworzy dobry kod. Można pójść więcej i powiedzieć: tworzy aplikacje, z których klient będzie zadowolony.

To podejście jest bardzo, bardzo różne od tego, że "koduje na tyle dobrze na ile mi pozwalają" i "godzę się na wszystkie bzdury które mi każą zrobić". Jedynym celem profesjonalisty jest osiągnięcie dobrego rezultatu. Tak się składa, że istnieją dwa główne rezultaty pracy programisty: aplikacja oraz sam kod.

Za aplikację my też odpowiadamy. Profesjonalny programista może czuć powinność zgłoszenia np. kretyńskiej decyzji projektowej. Np. koder webowy może oprotestować i spróbować zmienić przydługi formularz rejestracyjny, który mało kto wypełni. Albo interfejs na zwykłej stronie, którego użytkownik będzie się musiał uczyć choćby przez kilka minut. Bo profesjonalista nie ma w dupie tego, że aplikacja będzie do bani. On jest jednym z jej twórców, on za nią ODPOWIADA. Nie zwala winy na słabych designerów i głupich PM-ów.

Nie będę szerzej rozpisywał się na temat tego, że to my odpowiadamy za to, by aplikacja po prostu DZIAŁAŁA, tj. by była możliwie wolna od bugów. To oczywistość i tego już chyba nikt na nikogo nie zwala.

Ale jest jeszcze jedna ważna rzecz, za którą odpowiadamy: kod. To też zależy tylko od nas. Chodzi o jakość tego kodu. Żaden PM ani projektant nie pisze tego za nas. To nasza odpowiedzialność, by koleś, który przyjdzie po nas, powiedział "oo... ten kod wcale nie jest aż tak ch***y!" -- to zdanie powinno być muzyką dla naszych uszu ;).

Ponownie: profesjonalista jest ODPOWIEDZIALNY. Koleś, który wypuszcza słabiutki kod i płacze, że nie dają mu czasu na refaktoryzację, zachowuje się nieprofesjonalnie. Profesjonalista zastosowałby technikę tzw. "refaktoryzacji partyzanckiej". PM-owie nie chcą mu dać na to czasu? Nie przyjmują do wiadomości, że to zwiększy, a nie zmniejszy wydajność? No to niech nie dają -- profesjonalista sam sobie weźmie ten czas. Np. 10-15 min w ciągu każdej godziny. I nikomu nic na ten temat nie powie. Ew. wspomni o tym dopiero gdy po pół roku okaże się, że implementacja nowych funkcji w jego module zajmuje 2x mniej czasu niż w innych, gdzie kod jest totalnie zasyfiony.

Co do skomentowania tego, co robi autor topicu...

Klucznik napisał(a)

• Kodze ostatnio głównie w C#

I samo to czyni z Ciebie osobę nieprofesjonalną! Żartuję ;).

Klucznik napisał(a)

• Nie używam raczej żadnych wzorców oprócz takiego użycia że sesję buduję przez jakieś factory udostępnione przez API

Jeśli faktycznie kompletnie nie używasz żadnego z wzorców -- choćby nieświadomie -- to jest to niezbyt dobre. Nie musisz być guru wzorców, ale niektóre z nich po prostu nasuwają się same. Metoda wytwórcza, Metoda szablonowa. W językach typu C# wręcz musisz też używać wzorca Obserwator (C# udostępnia do tego piękne narzędzia składniowe), przydałby się też jakiś Iterator.

To wszystko wzorce.

Nie musisz od razu znać ich nazw, jeśli nie przeszkadza Ci to w komunikacji z kolegami z zespołu. Ale jeśli np. Twoja hierarchia klas się bardzo rozrośnie lub kod poszczególnych klas się zaśmieci, bo nie znasz (ani nie potrafisz intuicyjnie wymyślić) wzorców takich jak Most, Odwiedzający czy Dekorator... to będzie to mały fail.

Niektóre wzorce są swoistymi hackami łatającymi wady programowania obiektowego i dziedziczenia klasycznego. Gdy taka wada da Ci się we znaki, to warto znać leczący ją wzorzec.

Klucznik napisał(a)

• Czasem mam problemy z dobraniem nazw pól, klas etc.

Każdy ma. Oprócz tych, którzy nadają ch**** nazwy i twierdzą, że są dobre.

Najważniejsze to zmienić nazwę pole/klasy gdy tylko przyjdzie nam do głowy lepsza (refaktoryzacja!).

Klucznik napisał(a)

• UML tworzę na kartce lub w głowie, 10% przed rozpoczęciem projektu a resztę w trakcie albo nigdy

Mnie osobiście to wcale specjalnie nie rusza. Planowanie to zgadywanie. Można zaplanować ogólną strategię, czy jakieś ważniejsze elementy. Ale ja preferuję refaktoryzacje. Ciągłe, stopniowe ulepszanie, gdy tylko wyjdzie nam, że coś jest niewygodne lub nieeleganckie.

Klucznik napisał(a)

• Nie szanuję procesora optymalizację mając daleko w tyle

To dobrze, chyba że przesadzasz i olewasz to nawet wtedy gdy jest jakiś problem. Normalnie radzę olewać wydajność i skupić się na jakości kodu. Gdy aplikacja chodzi wolno, to wtedy trzeba zrobić benchmarki i zoptymalizować wąskie gardła. Wtedy mniej czytelne będzie te 5% kodu należącego do wąskich gardeł. Optymalizacja pozostałych 95% i tak nie przyniosłaby skoku w wydajności.

Mimo to, ja sobie wpajam pewne techniki, które zwiększają wydajność, a raczej mnie zmniejszają czytelności. I staram się je stosować od razu.

Klucznik napisał(a)

• Soft tworzę raczej iteracjami a nie od zera do końca

I bardzo dobrze. To jest podejście w stylu Agile. Dobrze by było, gdyby ktoś na wynik Twojej pracy zerknął po każdej iteracji. Najlepiej klient i ew. użytkownicy w testach usability.

Klucznik napisał(a)

• Inżynieria oprogramowania to coś co wydaje mi się ważne ale kurde nie mam czasu.

To jest typowo nieprofesjonalne podejście.

Klucznik napisał(a)

zgrabne kostrukcje typu
while(*dest++ = *src++)

Nie wiem, na ile to poważne, a poza tym takie śmieszne konstrukcje były pewnymi... idiomami w starych dobrych czasach C, ale dla porządku dodam, że dobry kod powinien zostać oceniony jako "prosty" i "oczywisty". A nie jako "sprytny" i "pokazujący ogromny skill autora, bo tylko on to może zrozumieć" :P

Aha: powiedziałbym, że sam zachowuję się wyłącznie profesjonalnie i nigdy się nie uginam, nigdy nie poddaję i nigdy nie akceptuję głupich decyzji szefa (który może być inteligentnym kolesiem i doskonałym managerem/biznesmenem, ale to JA jestem lepszym programistą). Mógłbym tak powiedzieć, ale nie chcę Was kłamać ;)

@up

nie wiem w jakim Ty utopijnym świecie żyjesz, ale mnie nie przekonałeś. 10-15-minut w ciągu każdej godziny? To jest 10h w tygodniu - jeśli ktokolwiek ma tyle czasu by robić co mu się podoba w firmie to ekstra.

Nie zrozum mnie źle - bardzo bym chciał dbać o kod tak żeby każdy był zadowolony, a firma rosła w siłę. Ale uderzasz w mur raz, drugi trzeci...50ty i niestety - pracodawca płaci pracodawca wymaga, a jak jest durny to żadne argumenty poza 'działającym' ( pewnie dość krótko) kodem do niego nie trafia.

Freakman napisał(a)

10-15-minut w ciągu każdej godziny? To jest 10h w tygodniu - jeśli ktokolwiek ma tyle czasu by robić co mu się podoba w firmie to ekstra.

Ja znam mnóstwo osób, co mają tyle czasu. Zresztą, w innych zawodach ludzie się przez pół dnia potrafią praktycznie obijać. U nas wydajność (tzn. może nie wydajność: udział czasu spędzony na klepaniu kodu) jest zwykle całkiem spora, ale i tak myślę, że mało kto robi 8h non stop. I ani nie sprawdzi maila, ani chwilę z kimś nie pogada, ani nie wlezie sobie na jakąś stronę www.

I mimo to jakoś nikt ich nie wylewa.

Zresztą, mniejsza z tym. Nawet jeśli polityka w firmie jest taka, że nie wolno się do nikogo odzywać, nie wolno odchodzić od kompa i faktycznie nie wolno sobie sprawdzić prywatnej poczty ani odbyć rozmowy telefonicznej z żoną na temat "Co kupić na obiad", to nie wierzę, że ktoś ślęczy Ci nad monitorem i patrzy, co dokładnie klepiesz w tym edytorze kodu.

Tzn. że jak zmienisz nazwę zmiennej, metody czy klasy, to ktoś to zauważy i Cię opieprzy, że "nie piszesz nowego kodu". Albo że zabronione jest przenoszenie czy wydzielenie metody lub klasy. Takie coś mogą zauważyć pracujący z Tobą programiści, bo zobaczą zmianę interfejsu. Ale też nie będą wiedzieli ile czasu na to poświęciłeś, a poza tym prawdopodobnie docenią, że posprzątałeś bałagan w kodzie. A czy jakiś manager to zauważy, nawet jeśli jest (programistycznym) idiotą i będzie Cię chciał ochrzanić, że zmieniłeś nazwę pola z "n" na "numberOfUsers"? Szczerze wątpię, by fizycznie był w stanie to zauważyć.

Zresztą nie mówię, że refaktoryzować trzeba np. przez bite 10 minut na końcu każdej godziny. Nie, ja to robię non stop. Równolegle z pisaniem kodu. Jak coś muszę gdzieś zmienić i widzę tam bałagan, to choć trochę staram się tam posprzątać. Małymi krokami.

Co do PM-ów i dyrektorów, to oni wbrew pozorom też debilami zwykle nie są i da się ich przekonać. Choćby analogiami. Można im tłumaczyć, że nie refaktoryzowanie kodu to tak jak nie sprzątanie pokoju. Albo: nie sprzątanie w restauracyjnej kuchni lub w sklepie. Takie materialne analogie są łatwiejsze do zrozumienia. Już po paru dniach robi się bałagan i wydajność pracy znacznie spada.

Bo przecież robimy to wszystko dla wydajności, nie (tylko) dla idei. Po co sprzątać kod, jeśli nawet nad syfem programiści potrafią pracować równie wydajnie? No właśnie: sęk w tym, że nie potrafią. I ja jakoś nie zauważyłem, że przez te moje ciągłe refaktoryzacje pracuję wolniej niż inni. Raczej odwrotnie, szczególnie po pewnym czasie, gdy moduły są większe, a bałagan w nierefaktoryzowanym kodzie staje się nie do zniesienia.

Tak czy siak, temat pyta o profesjonalne podejście. Więc profesjonalne podejście jest właśnie takie: zrobienie wszystkiego, by aplikacja i kod były jak najlepsze. To nas obchodzi, a nie jakieś wymówki.

To tak jak z designerami. Profesjonalny designer nie pozwoli, by kretyńskie uwagi i żądania klienta spieprzyły temu klientowi projekt. Bo klient się na designie nie zna, więc klient nie może być odpowiedzialny za swój własny projekt. To designer jest za to odpowiedzialny, jeśli jest prawdziwym profesjonalistą.

Freakman napisał(a)

pracodawca płaci pracodawca wymaga, a jak jest durny to żadne argumenty poza 'działającym' ( pewnie dość krótko) kodem do niego nie trafia

Za co płaci pracodawca? Za bycie koderską małpką? A może pracodawca płaci za to, by mieć dobrą aplikację i dobry kod? Jeśli za to drugie, to Twoim zdaniem jest zapewnienie tego. Nawet jeśli pracodawca Ci w tym przeszkadza.

Poza tym, jak jest faktycznie durny, to radzę się zwolnić. U nas akurat rynek pracy jest w miarę kapitalistyczny i to stosunkowo dojrzały pod tym względem. Tj. nie ma tych naleciałości komunistycznych, że pracodawca jest w lepszej sytuacji niż pracownik. Nie: u nas nikt nikomu nie robi łaski. Dobry koder znajdzie pracę bez większych problemów.

Freakman napisał(a)

w jakim Ty utopijnym świecie żyjesz

Tu są różne fajne odpowiedzi: 1. W takim, jaki sobie zrobię. 2. W takim samym jak Ty :P. Nigdzie nie napisałem, że świat jest idealny. Ale rozumiem, że w temacie mówimy o wzorze profesjonalnego zachowania. Wzorze. Utopią by było twierdzenie, że każdy takim wzorem jest i że ktokolwiek może ZAWSZE spełniać wszystkie wymagania stawiane przed pro-programistą. Tego nigdzie nie stwierdziłem.

edit: może inaczej. W tym temacie rozmawiać możemy i o wzorcach, i o tym, jacy jesteśmy w praktyce. Można założyć, że nikt z nas nie jest idiotą i wszyscy zdajemy sobie sprawę, że nikt z nas nie jest również supermanem.

Oczywiście masz rację - trzeba się starać, nie ma nic gorszego niż wylewanie do kompilatora jakiegoś badziewia a twierdzenie, że wszystko jest ok. Jednak nie w każdej firmie development wygląda różowo a metoda małych kroków jest w ogóle możliwa. Tak jak mówisz - wtedy wypadałoby jak najszybciej zmienić firmę, żeby nie nabrać złych nawyków.

Długo by pisać, jak tragicznie zorganizowane potrafią być firmy..... ale to temat na inny wątek.

A gdzie odpowiedź "staram się" ? :P

Freakman napisał(a)

Długo by pisać, jak tragicznie zorganizowane potrafią być firmy..... ale to temat na inny wątek.

Oj tak, potrafią. Choć ja miałem akurat to szczęście (plus świadomy wybór -- na rozmowach kwalifikacyjnych nie tylko JA jestem sondowany, ale również ONI przeze mnie), że współpracowałem albo ze świetnymi firmami, albo z firmami, które szczerze starały się być świetne. Prawdę mówiąc, nawet tych "wstrętnych PM-ów" absolutnie nie miałem złych. To byli inteligentni ludzie, a że programistów mieli w firmie dobrych (no, byłem jeszcze ja ;) ), to mieli do nich spore zaufanie w kwestiach związanych z trybem pracy.

Ale mam wielu kolegów-programistów i słyszałem różne historie.

Normalnie jestem zdania, że wolny, kapitalistyczny rynek (który w naszej branży w zasadzie mamy!) sam to całkiem nieźle reguluje. Odejście z firmy, która wręcz stara się (!) być niereformowalna, daje im pewien sygnał. Może im pomóc. Ale nie zawsze to działa. Są firmy, które co rok-dwa praktycznie wymieniają cały zespół koderów. I nigdy się nie uczą.

Keraj napisał(a)

A gdzie odpowiedź "staram się" ?

Świetne pytanie. Chciałem zagłosować, ale zabrakło mi tej opcji.

Bo co oznacza: "Tak, zachowuję dobre praktyki programowania"? Że zachowuję je zawsze i wszędzie? To bym odpowiedział: nie. Że poświęcam mnóstwo prywatnego czasu na nauczenie się ich i na nauczenie się ich wdrażania w życie, co zresztą nie wychodzi mi tak źle? To powinienem zagłosować na tak. W skrócie: staram się. Naprawdę. Czasem mi nawet wychodzi.

W dużej mierze za brak dobrych praktyk u programistów(tych po studiach) odpowiedzialna jest uczelnia i sposób kształcenia. Mogę to powiedzieć na swoim przykładzie. Będąc na 4roku miałem zaledwie dwa i to wybieralne przedmioty na których byłem zmuszony do stosowania i uczenia się tworzenia kodu dobrej jakości. Na piatym takich przedmiotów już nie ma więc mogę powiedzieć że przez 5lat na dwóch przedmiotach starali się mnie nauczyć dobrej pracy z innymi ludźmi. Tak pracy z ludźmi, bo jak już wcześniej wspomniano, wzorce, dokumentacja testy, standardy kodu są po to aby inni mogli go łatwiej zrozumieć. Na uczelni studenci najczęściej piszą kod sami, na zaliczenie. Więc dla nich dokumentacja nie jest potrzebna, standard kodowania nie jest potrzebny, bo przecież to mój kod, scm to może tylko po to aby sam sobie kod zabezpieczyć przed zniszczeniem, ciągła integracja -> po co przecież moge sam sobie na lokalu sprawdzić. Po paru latach takiej sielanki przychodzi pracować w grupie to jest z tym po prostu problem, bo zespół to grupka indywidualistów... A ciężko pozbyć się nawyków, których uczyło się kilka lat.

Ale wracając. Na wspomnianym przedmiocie trafiło mi się wykonywać projekt(praktyki) dla zewnętrznej firmy. I w tym przypadku z firmy dostawaliśmy zadania i byliśmy rozliczani z ich realizację. Prowadzący śrdnio interesował się samą funkcjonalnością (bo nie on ją oceniał), a przykładał dużą wagę do tworzenia kodu dobrej jakości. Ciagła integracja, pokrycie kodu, możliwie wysoki poziom abstrakcji, szablony, tworzenie komponentów wielokrotnego użycia itd. Owszem zajmowało to czas, przez co wolniej pisaliśmy samą funkcjonalność.

A teraz jestem w firmie w której tego brak. Napisanie infrastruktury do testów trochę zajmie więc jej nie ma. Ale kurcze brakuje mi tego, wcześniej jak coś popsułem to widzę na hudsonie wkurzonego Chucka Norrisa i listę testów mówiących mi co zepsułem. Teraz jeżeli coś popsuję to albo muszę sam przeklikać aplikację, albo ktoś z zespołu mi powie za jakiś czas że mój fagment sypie wyjątkami.
Dalej kod jest mało abstrakcyjny, tzn na praktykach tworzyliśmy komponenty wielokrotnego użytku. Cóż zdarzyło mi się kilka razy siąść i klepać szablon przez kilka dni, który później używało się jedną linijką. Teraz tego nie mam i co? Musze pisać wszystko od zera, dublować kod itd bo nie ma na to za bardzo czasu i sama struktura kodu średnio pozwala na wykorzystanie go w innych miejscach.
Dokumentacja i styl kodowania. W sumie to wiele nie kosztuje, ale np checkstyle pluło się tu pluło się tam. Więc się dopisało tych kilka linii javadoców co akurat sprowadziło się do wyuczenia prostego nawyku.

Cóż. Korzystanie z dobrych praktyk wymaga poświęcenia na to trochę czasu, przygotowanie np infrastruktury testowej, rozpisania standardów kodowania, ale daje naprawdę bardzo duże korzyści w przyszłości i zaoszczędzi czas, mnóstwo czasu. Zauważyłem też że takie coś wymaga w pewnym sensie umiejętności przyznania się do błędu przez człowieka, bo jak aplikacja się nie zbuduje to wszyscy widzą że to moja wina. Bez tego można oddać coś co może czasem działa. I tak podobnie wygląda sprawa przeglądu kodu. Dorosnąć do sytuacji w której ide do kogoś lepszego i proszę żeby rzucił okiem na mój kod bo nie jestem pewien czy jest poprawny.

Tak na koniec, kiedyś gdzieś znalazłem fajne zdanie, że programowanie to w 80% szukanie błędów. A teraz mając testy i ciągłą integrację praktycznie na dzień dobry lista bugów.