Sytuacja, w której kod komercyjny ustępuje jakością projektom open source, zdarza się stosunkowo często. Wynika to z:

  • niejednoznacznych wymagań biznesowych,
  • zaciągniętego długu technicznego,
  • narastającej złożoności,
  • rotacji programistów,
  • braku doświadczenia,
  • brak pokrycia w testach,
  • ograniczonych zasobów.

Istnieje duża szansa, że kod firmowy będzie daleki od ideału, wtedy nie trudno o jego krytykę.

Nie rób tego.

Krytykowanie kodu przez nowego członka zespołu jest często odbierane jako przejaw arogancji – nawet jeśli intencje były dobre. Taki początek współpracy potrafi bardzo szybko popsuć relacje, ponieważ w ten sposób możesz zrazić do siebie cały zespół oraz osoby zarządzające projektem.

Zanim skrytykujesz zastany kod, daj sobie czas na refleksję. To idealny moment, by zastanowić się nad przyczynami bieżącego stanu w kodzie.

Niska jakość kodu nie jest tu największym problemem. W pierwszej kolejności należy docenić fakt, że dany projekt jest aktywnie rozwijany. Co więcej – wciąż odpowiada na potrzeby użytkowników, a przede wszystkim jest projektem dochodowym.

W komercyjnym rozwoju oprogramowania nie chodzi o to, by za wszelką cenę dążyć do perfekcji i pisać kod idealny. Taka postawa rzadko przynosi korzyści. Próba stworzenia kodu doskonałego przypomina przedwczesną optymalizację, która – jak powszechnie wiadomo – bywa źródłem wszelkiego zła.

Ciągłe poprawianie kodu to ślepy zaułek. Chociaż czytelny kod bez wątpienia jest pożądany, to warto pamiętać, że oprogramowanie docelowo jest tworzone dla użytkowników, a nie dla samych programistów. Znacznie lepiej jest ukierunkować pracę zespołu na działania, które przynoszą realną wartość biznesową.

Nie oznacza to jednak, że powinniśmy unikać ulepszeń w kodzie. Wręcz przeciwnie, są one wskazane, ale tylko szeroka wiedza o projekcie pozwoli nam na wprowadzanie świadomych i przemyślanych zmian.

Pamiętajmy jednak o takcie – modyfikacje, choćby najbardziej trafne, potrafią dotknąć czyichś ambicji. Jeśli widzimy szansę na ulepszenie systemu, omówmy tą kwestię z bardziej doświadocznym programistą. Właśnie na takim dialogu opiera się prawdziwa praca zespołowa.