Niektórzy tak się nie mogą pogodzić z tym, że dobre teoryjki wcale nie są takie dobre i uniwersalne, że z góry przyjmują założenia, że robię oprogramowanie wg scenariusza: napisać -> kilka razy użyć -> wyrzucić, bo przecież niemożliwe, abym skutecznie utrzymywał oprogramowanie napisane z pominięciem dobrych teoryjek. Jasne, że nie jest to jakiś gigantyczny projekt, bo nawet najlepsza strategia nie przezwycięży normalnych, ludzkich ograniczeń pojedynczego człowieka.
Przykład dobrej praktyki, który podałem (trzymanie w kodzie kilku niewiele różniących się od siebie wersji tej samej funkcjonalności) jest ewidentnym złamaniem dobrej teoryjki DRY. I nie jest specjalnie wdzięczny marketingowo, dlatego nie nazywam go dobrą teoryjką. Jest tego mnóstwo w praktycznie zrealizowanych bibliotekach, jak choćby w SQLite, ale to się generalnie robi a nie opowiada o tym - bo wytłumaczenie, dlaczego w tym konkretnym przypadku było to właściwą decyzją, nie jest takie proste i nie wzbudza takiego entuzjazmu u słuchacza/czytającego.
I też jest dość łatwo wyobrazić sobie charakterystykę projektów, w których ta technika będzie bezużyteczna/szkodliwa; u mnie akurat jest przydatna, mimo że nie robię bibliotek do wykorzystania przez innych.
