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ć ;)