Od pewnego czasu dochodzę do myśli, że dobre praktyki na temat czystego kodu wraz z konstrukcjami języków wysokopoziomowych coraz częściej są sprzeczne z pragmatycznym programowaniem.
1. DRY
Ciągle uważałem, że w kodzie nie należy łamać reguły DRY, że jeśli coś się powtarza to znak, żeby reagować i przeciwdziałać temu. Kod w takich wypadkach poddaje się grupowaniu i uogólnianiu na tyle ile to konieczne. Dlatego też po przejściach z C++ i Java, skakałem z radości na widok Pythona.
Mimo wszystko, im więcej uczyłem się na temat właściwych praktyk programowania tym coraz wolniej tworzyłem kod, a jego przejrzystość i tak pozostawiała wiele do życzenia. Link do kolejnego wątku jest idealnym przykładem rosnącej złożoności w próbie ochrony DRY: http://4programmers.net/Forum/Inzynieria_oprogramowania/201041-o_utrudnianiu_sobie_zycia_w_c++_za_pomoca_wektorow_metod_i_szablonow
2. Programista != Prorok aplikacji
W takcie moich przygód z programowaniem od czasu do czasu miałem styczność z kilkoma nietypowymi tekstami na temat porzucenia wysokiego poziomu abstrakcji i skupieniu się wyłącznie na kodzie faktycznym. Pierwotnie to zignorowałem, bo jak to tak programować bez uwzględnienia przyszłych jakże prawdopodobnych modyfikacji!
Pułapki programowania obiektowego: http://www.slideshare.net/Reg1773/puapki-programowania-obiektowego
Najbardziej uderzył mnie argument odnośnie uogólniania, bo fakt faktem kodując, nie wiem co przyjdzie dokładnie dodać za 3 miesiące tak więc uogólniam każdą możliwą opcję. W każdym razie to myślenie, a także kodowanie z myślą ponownego wykorzystania kodu w moich oczach jest coraz większą ściemą.
W odniesieniu do tego slajdu bardzo podobała mi się odpowiedź @Azariena w wątku: Projekt Szachów
Ujął aplikacje w proste koncepcje. Oczywiście, zaraz po jego wypowiedzi padło kilka tekstów, że rozbudowa pod wieloma kątami będzie mieć dużo bolączek.
W trakcie czytania wątku spodziewać się można było takich odpowiedzi skoro zwykle chce się opancerzyć kod tak, żeby był przygotowany na każdą ewentualność. W praktyce takie działanie wydaje mi się przerostem formy nad treścią.
Ciekawym momentem była próba patrzenia na projekt nie z perspektywy fragmentów aplikacji, a samej aplikacji. Wtedy interesowałem się metodykami tworzenia oprogramowania i przeczytałem "Zwinny samuraj. Jak programują mistrzowie zwinności" i "Zrozumieć Agile Project Management Równowaga kontroli i elastyczności". Głównie podobała mi się podstawa tych metodyk agile czyli Lean Software Development.
W kontekście odchudzania bardzo przypadła mi do gustu informacja, że wartością dla klienta w aplikacji nie jest wystrzałowa architektura, a konkretna funkcjonalność.
To też bardzo podobał mi się przykład z książki "Czysty Kod". Chętnie przepisałbym fragment z książki, ale nie mam jej przy sobie.
Został podany tam przykład, że kod to miasto, które z czasem się rozwija. Główną myślą było to, że nie ma idealnego kodu na czas całego systemu. Jako przykład została przedstawiona wieś i nieopłacalność budowy w niej autostrady. Dopiero gdy to wieś się porządnie rozwinie wtedy pojawi się sens budowy tej autostrady.
Innym przykładem na to, że próba wyprzedzenia potrzeb w projekcie jest daremna ukazuje ta notka na temat astronautów platformowych: http://www.devblogi.pl/2012/04/kiedy-wielcy-mysliciele-analizuja.html
3. Podsumowanie
Osobiście myślę, że języki oferują za wiele wygody programiście. Wcześniej gdy był C to ludzie też tworzyli duże systemy i dawali sobie z nimi radę, a teraz mimo licznych wygód to programowanie staje się coraz bardziej chore.
Na koniec TAO programisty o którym sobie przypomniałem.
3.2
Byl raz programista, ktory pisal niestrukturalne programy. Nowicjusz,
probujacy go nasladowac, takze zaczal pisac niestrukturalne programy.
Gdy nowicjusz poprosil mistrza o ocene postepow, mistrz skarcil go
za pisanie niestrukturalnych programow, mowiac: "Co jest odpowiednie
dla mistrza, nie jest odpowiednie dla ucznia. Musisz zrozumiec
Tao zanim przenikniesz strukture."
Myślę, że już wreszcie pojąłem o w tym tekście chodzi.
Jestem ciekaw waszych opinii, a szczególnie tego, czy jako programiści C++, C# czy Java doszukujecie się potrzeb łamania dobrych reguł?
