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.
