Rozumiem, że tu jest forum programistów a programiści tworzą kod. Naturalnym wydaje się być, że dobry programista tworzy dobry kod i po tym można odróżnić tego dobrego od złego. Choć też głównie jestem programistą to widzę to zupełnie inaczej. Dobry programista powinien umieć napisać dobry kod, powinien umieć tworzyć generalizacje w postaci często nadmiarowych abstrakcji ale realizując konkretne zlecenie do jego rozwiązania powinien potrafić zastosować narzędzia i techniki odpowiedniego kalibru do problemu. Na to co należy użyć będą miały wpływ termin realizacji zadania czy cena końcowej aplikacji. To dwa niezmiernie ważne czynniki aspekty, o których większość programistów zapomina, uważając że kod musi być super bo inaczej aplikacje będzie zła... Niestety to nie jest prawda.
W pewnym przypadku dobrym kodem będzie relatywnie łatwe do ogarnięcia "spaghetti" w całości umieszczone w funkcji main a w innym przypadku starannie zaprojektowany zbiór dziedziczących po sobie klas może okazać się porażką. Tu nie ma ogólnie dobrych wytycznych.
Skupianie się na samej jakości kodu to projektowy błąd. Sama jakość kodu bardzo rzadko przekłada się na biznesowy sukces projektu. Dobry kod może być dumą programisty ale w tym samym czasie konkurencyjna firma sprzeda 10 razy więcej licencji mimo, że kod mają beznadziejny ale wystartowali pół roku wcześniej.
Po ponad 20 latach projektowania i pisania systemów, aspekt jakości kodu uważam za pomijalny - nie mówię tu o ewidentnych kaszanach i "druciarstwie". Każdy kod napisany z zachowaniem minimum staranności da się rozwijać i modyfikować nawet po 10 latach.
Jeśli jednak miałbym wskazać coś co ma potwierdzony wpływ na łatwość rozwoju systemu, nawet po wielu latach, to będzie to jego architektura.
Nie sam kod a odgórna idea narzucająca reguły i ramy, w których będą poruszać się programiści tworzący poszczególne moduły systemu.
Nie da się jednak łatwo powiedzieć jaka architektura będzie dobra bo to już zależy od specyfiki rozwiązania, które się tworzy. Nie mając wystarczającej wiedzy na temat tego jak projekt się rozwinie możemy popełnić poważny błąd a wtedy nie uratuje nas nawet najpiękniejszy kod, z którego zbudowana jest źle zamodelowana aplikacja.
Na oceną kodu ma duży wpływ też to, kto za niego płaci. Myślę, że niejednemu głosicielowi idei pięknego kodu przyszło zapłacić za większy projekt z własnej kieszeni to szybko zrewidowałby swoje poglądy na temat "jakości".
Nie zawsze naszym klientem jest bank, automotive czy inny finansowy moloch. Łatwo jest się "wymądrzać" kiedy budżet mamy niemal bez ograniczeń.