W wielu zespołach jest “guru”, który decyduje o architekturze, praktykach, narzędziach itd. Reszta zespołu, prawdopodobnie mniej doświadczona, podąża wytyczonymi przez niego ścieżkami. System się buduje, każdy klepie swoje, mijają miesiące, kolejne ficzery “się dodają”… a rozwój zespołu stoi w miejscu.
Nie powinno tak być, jednak częściej raczej niż rzadziej taki guru jest tak zadowolony ze swojej pozycji i tak zadufany w swojej nieomylności, że tak jak jest – jest dobrze – i już. I wszystkie kolejne projekty, jeden po drugim, tworzone są tak samo, jak wycięte z szablonu. “Bo to przecież działa”.
Nie chcę tutaj generalizować, ale z takim podejściem spotkałem się w swojej “karierze” więcej niż raz i więcej niż dwa razy. Więcej nawet niż trzy razy. I za każdym razem jest to smutne.
Zamykanie się na wpływy z zewnątrz, bądź czerpanie wiedzy tylko z jednego zaufanego źródła (MSDN?) to droga donikąd. Bez alternatywnego spojrzenia na to, co aktualnie robimy, nie możemy ulepszać efektów swojej pracy. Mało tego, takie postępowanie to najzwyczajniejsza w świecie rutyna bardzo prędko prowadząca do nudy i, potencjalnie, groźnego w skutkach “wypalenia”.
Jednym z najlepszych sposobów na poznanie zaawansowanych, nowych tricków programistycznych, a tym samym urozmaicenie pracy, jest czytanie cudzego kodu. Nie kodu kolegi z zespołu pracującego nad tym samym projektem – ale kodu zupełnie oderwanego od codziennych obowiązków. Przejrzenie, nawet pobieżne, dowolnego projektu open source może rzucić nowe światło na problemy napotykane na co dzień. Nie trzeba dogłębnie analizować wszystkich zawiłości takiego rozwiązania, które siłą rzeczy może być dość skomplikowane.
Bardzo interesujące kawałki kodu można znaleźć również na blogach. Mi dawno temu utknął, i siedzi do dziś, pamiętny post Udiego Dahana “Domain Events – Salvation“. Koncepcja ta, poparta przykładami w kodzie, znalazła zastosowanie w kilku moich systemach (z lekkimi modyfikacjami, o których pisałem w poście “Application Events“).
Czasami banalne, zdawałoby się, konwencje w cudzym kodzie potrafią bardzo urozmaicić nasze własne projekty. Przykład: nazwy interfejsów z NServiceBus. “IHandleMessages“, “IDoSomething“… To otworzyło mi oczy na jakże ciekawe wykorzystanie przyjętego standardu (btw, odpowiadającego mi w 100%) rozpoczynania nazwy interfejsu od litery I.
Przeglądanie kodu jest też najlepszym sposobem na naukę praktycznego zastosowania nowych mechanizmów. Jeśli chcesz poznać możliwości takiego np. dynamic (ExpandoObject) to lektura źródeł Simple.Data na pewno przyniesie więcej korzyści niż wertowanie MSDNa.
“Słowo pisane”, czy to kompilowalne, czy nie, nie jest jedynym źródłem błyskotliwych “gitsów”. Warto rozejrzeć się za nagraniami dostępnymi online z ciekawych konferencji jak Oredev, NDC czy DevDay, i tam poszukać inspiracji.
Kluczowe jest nietraktowanie swojego – bądź narzuconego w firmie przez lokalną alfę i omegę – kodu jako tego jedynie właściwego. Otwarcie na cudze pomysły może tylko pomóc.
Jeśli jesteś, Czytelniku Drogi, takim właśnie guru: kiedy ostatnio spojrzałeś na cudzy kod z nadzieją nauczenia się czegoś, a nie powiedzenia “też coś, zrobiłbym to lepiej!”? A jeśli jesteś nie-guru: to może właśnie na Twoich barkach spoczywa ciężar wprowadzenia do aktualnego systemu trochę powiewu świeżości? Rozejrzyj się, poszerz horyzonty – nawet jeśli w robocie ten czy ów fajny pomysł zostanie odrzucony, to zawsze zostanie dla Ciebie jako nagroda za trud do zastosowania w przyszłości.
Pamiętaj: wszędzie wokół pełno jest ciekawego kodu czekającego tylko na odkrycie i czerpanie z niego pełnymi garściami. Nie można polegać tylko i wyłącznie na własnym doświadczeniu i “oficjalnych” źródłach – bardzo wiele można wynieść z doświadczeń cudzych, prowokujących do zastanowienia i dyskusji.
Nie będziesz krył kodów cudzych przez sobą | Maciej Aniserowicz o programowaniu…
Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl…
No proszę, w sobotę prawie o tym samym miałem rozmowę. Moja konkluzja była taka, że każdy powinien podważać swoje kompetencje, negować je i szukać lepszych rozwiązań. Bez tego nigdy nie wyjdzie się poza advanced beginner z modelu Dreyfusa
Bardzo dobrym źródłem kodu do przeglądania jest oczywiście GitHub.. ale jak znaleźć tam coś ciekawego? Ot.. zakładka “Languages”, w której po wybraniu języka widzimy “topy” w różnych kategoriach – na pewno jest to jakiś wyznacznik, np: https://github.com/languages/Objective-C
“If the only tool you have is a hammer, you tend to see every problem as a nail.” (Abraham Maslow)
Coraz wiecej firm odchodzi od modelu “jeden mister guru” vs reszta swiata.
Idealne srodowisko to takie w ktorym Team Leaderowi zalezy na rozwijaniu pracownikow i ich talentow. Niestety duza czesc firm po prostu dziala jak kopalna wegla brunatnego wyeksploatowac zasoby a jak zaczynaja narzekac to wymienic.
@rafek a zostalo to naprawione? bo swojego czasu zle wybieral jezyk i ciezko bylo za pomoca jezyka sie poruszac. nawet ravendb server byl trakowany jako javascript.
Wybór “Objective-C” mnie jeszcze nie zawiódł… więc wg mnie wygląda, że naprawione.
@gutek, @rafek: kiedyś, standardowo, był problem z C# jako, że ‘#’ obcinał i wyszukiwał C. Teraz wydaje się działać prawidłowo.
Paweł
Dodatkowo dobrym patentem jest bycie członkiem jakiejś społeczności programistów, grupy .Net itp gdzie mnożna łatwiej o wymianę doświadczeń.
W sumie to dobrze jest zacząć od projektu z którego korzysta się w praktyce. Już wiadomo “co” robi, można równie dobrze zagłębić się w “jak” to robi.
[…] języków, metodyk, wzorców, technologii. Ciekawy i trochę dłuższy wpis na ten temat popełnił Maciej Aniserowicz. Warto poświęcić kilka chwil na lekturę, a później zabrać się do czytania cudzych […]