Jak można zdefiniować dobrego inżyniera? Jako kogoś kto potrafi opisać złożony system bez machania rękami ;-)
Mnie się wydaje, że sztuka polega na tym by widząc problem dokonać jego rozebrania na mniejsze problemy i patrzeć na te problemy jak klocki, z których można budować rozwiazanie.
Może niektóre klocki są niepotrzebne, a znów inne przydadzą się do czegoś jeszcze? Wtedy nie budujemy ficzera X, budujemy środki do osiągnięcia tego co ma robić ficzer X i zwiększamy ilość dostępnych klocków.
W komputerach zwykle nie rozwiązujemy za każdym razem nowych problemów, a raczej inną wersję tego samego problemu.
Nagle celem staje się nie tyle tworzenie tych klocków, a używanie tych klocków do budowania czegoś większego.
Nie znasz pełnych wymagań? Nie musisz na nie czekać, identyfikujesz kluczowe problemy i je rozwiązujesz tak, że w razie czego chociaż część z nich z niedużymi modyfikacjami pozwoli rozwiązać prawdziwy problem.
Przeszedłem w życiu przez kilka firm ;-) i widzę, że często popularne jest budowanie ficzera w którym sam ficzer staje się ważny. Wydaje mi się, że ja od pewnego momentu patrzę na kawałki i znając historię umiem mniej lub więcej przewidzieć, że ten kawałek przyda się jeszcze w innych miejscach.
Patrzę na kod (bo kod jest wg mnie nadal ważny) ale bardziej patrzę na powierzchnie styku. Co jest w środku to szczegół implementacyjny. Ważne jest co jest na zewnątrz, jaki jest interfejs.
Do tego patrzę na kod i staram się myśleć jak on się będzie mógł zmienić, większej zmiany nie zrobimy "na raz" ale na raty się może udać. Nawet nie wiedziałem, dowiedziałem się, że to jest Strangler Fig Pattern ;-)
Żeby nie było ja potrafię napisać brzydki kod ;-) ale zwykle potrafię też zbudować coś co można dalej modyfikować i rozwijać, nie zalewam tego betonem. Zawsze gdzieś można włożyć "coś pomiędzy" i ukryć zmianę przed resztą kodu... fakt czasem jest to trudne, ale zwykle się daje.
Ogólnie lubię robić to tak, żeby komponenty zbytnio o sobie nie wiedziały.... i też nie piszę jednak za bardzo OOP kodu bo u mine class members jako zmienne to głównie jakieś "serwisy" czyli instancje klas robiących coś... zwykle jak spojrzeć to moje klasy są takie semi-bezstanowe.... choć fakt nie jest idealnie bo zdarza mi się, że metoda może modyfikować swój input.... to jest jednak inżynieria nie religia ;-)
To samo podejście próbuję stosować do większych komponentów. W moim idealnym świecie zmiana jednego komponentu jest niewidzialna dla pozostałych... Tak, to znaczy, że może jak gdzieś jest np. pipeline który dostaje format A, pierwszy kawałek przerabia na B, drugi pracuje na B i go ulepsza i w końcu publikuje... to ja bym wolał wejście A, ale pierwszy robi (A,B) i drugi pracuje na (A,B) i produkuje A... więc z czasem mogę funkcjonalności z pierwszego przenieść do drugiego i go później zabić.
Czyli ogólnie architektura czy kod to jest tylko snapshot całego rozwiązania tu i teraz. Nie musi być doskonały, musi robić tylko to czego od niego na dziś wymagamy, a do nowych wyzwań zawsze może urosnąć.
Podobne postybeta
W tworzeniu softu droga od tego jak jest do tego jak ma być jest ważniejsza od tego jak ma być
Rozdzielanie dwóch światów ;-)
Tagowanie postów MLem - trzeba to przepisać ;p
Struktury danych vs algorytmy
Cybernetyka w działaniu ;-)
