Kod który piszemy powinien odzwierciedlać/modelować rzeczywistość.
To jest tylko slogan, który jest bardzo szkodliwy. Sam go sobie powtarzałem jak miałem mało doświadczenia.
polecam obejrzeć w całości.
Nadal uważam że nasz kod powinien modelować rzeczywistość. Oprócz tego mam również zasadę kompozycja ponad dziedziczenie, DRY, KISS, SOLID, konwencja ponad konfiguracja, nie tworzyć bytów ponad stan, rozwiązanie powinno być tak proste jak to możliwe ale nie prostsze. Uncle Bob poruszył inną kwestię: zbudowanie wspólnej nomenklatury / żargonu pomiędzy biznesem a developerami oraz byciu agile a nie wdrażaniu agile. Wchodzimy tutaj w kwestie DDD. U mnie w kodzie odpowiedzialności są jasno podzielone: część kodu jest stricte związane z architekturą / frameworkami a część stricte z domeną. Ja piszę w androidzie - może tutaj prościej utrzymać wszystko w garści.
"To jest tylko slogan, który jest bardzo szkodliwy. Sam go sobie powtarzałem jak miałem mało doświadczenia." co mamy innego do zaoferowania? Wykorzystywać wszędzie Map<Object,Object> i robić instance of? Modelowanie rzeczywistości jest ważne, dzięki temu zdecydowanie prościej zrozumieć kod. Oczywiście przerost formy nad treścią albo robienie abstrakcji bo kiedyś to się przyda nie jest dobrze widziane.
//Edit: Ten temat nie jest wyczerpany, do tego dochodzą jeszcze optymalizacje wielowymiarowe, malejący wzrostt(diminishing return), second / third order thinking, automatyzacja, OKR, KPI, tworzenie strategii rozwoju aplikacji, zarządzanie ryzykiem, przesuwanie całego developmentu w kierunku zapewnienia niezawodności...