"Czysty kod" to (poza nazwą książki) po prostu zwykły buzzword i jest duża obawa, że jak ktoś co chwila mówi o "czystym kodzie" / "clean code", to dla takiej osoby ważniejsze jest przestrzeganie regułek niż pragmatyzm. Zbytnie nastawienie na "czysty kod" dla mnie byłoby niepokojące, i często kontrproduktywne.
Pamiętam pracę w zespole, w którym były kłótnie o niewłaściwą liczbę enterów, albo o wydzielenie lokalnej zmiennej pomocniczej, bo leadowi się to po prostu subiektywnie nie podobało. No bo troska o jakość kodu musiała być. Ale po owocach ich poznacie i tamten projekt, mimo, że dopieszczany na poziomie duperelek, to na poziomie lotu ptaka nie miał ani specjalnie dobrej architektury (np. za duży coupling między modułami). No i też te moduły (i powiązania między nimi) nie były zbyt czytelne, ciężko się było połapać. Więc tyle w temacie troski o czysty kod.
Dla mnie gadanie o "czystym kodzie", "jakości kodu", "dobrych praktykach" to czerwone lampki, że ktoś uprawia jeszcze jeden cargo cult i się jara czystym kodem dla samego jarania, ew. stosuje zasady dla samego stosowania.
(S.O.L.I.D.)?
SOLID to fajny zestaw reguł, ale przestrzeganie ich jest wynikiem wiedzy developerów o tych zasadach, ich rozumienia i oddolnej chęci zastosowania, a nie tego, że jest kładziony odgórny nacisk na czysty kod. Jak ktoś ma to zinternalizowane, to po prostu intuicyjnie stara się pisać, żeby te zasady zachowywać, ew. łamać je, kiedy wymaga tego sytuacja. Czyli pytanie bardziej o to, czy firmy zatrudniają programistów, którzy znają i potrafią stosować te reguły.