Które części Code Complete nie przetrwały próby czasu? [Zamknięte]

Patrzyłem na Code Complete na półce, myśląc: „Poza miesiącem Mitycznego Człowieka może to być jedna z niewielu książek o inżynierii oprogramowania, która przetrwa próbę czasu”. Z tego powodu zastanawiam się, czy nie wskoczyć, by go ponownie przeczytać.

Jestem ciekawy - czy ktokolwiek ostatnio ostatnio rzucił mu drugie spojrzenie? Tak, widziałeś coś, co bardzo się mylił?

To nie jest atak ani prośba o recenzję książki - bardziej interesuje mnie, jakie pomysły zmieniły się na przestrzeni lat.

I proszę - bez komentarza na temat: „Demarco / Spewak / Zachman przetrwał próbę czasu ...” Szczególnie interesuje mnie Code Complete ze względu na szerokość ziemi, którą obejmuje, i zasięg, jaki miał na polu.

Code Complete obejmuje wiele ponadczasowych koncepcji, takich jak:

• silna spójność
• luźne powiązanie
• dobre rutynowe nazwy
• programowanie obronne
• kod samokontrujący
• recenzje oprogramowania
• testów jednostkowych

które są z pewnością aktualne dzisiaj.

Niektóre z koncepcji bronionych w CC są teraz egzekwowane składniowo w nowszych językach, na przykład C # nie pozwala na definiowanie zmiennych w podzakresach w sposób, który ukrywa definicję super-zasięgową.

Inne koncepcje, takie jak węgierski zapis nazw zmiennych, odeszły na dalszy plan w głównym nurcie programowania (chociaż każdy, kto nadal pracuje z Win32 API, będzie stanowczo argumentował, że żyje i ma się dobrze). Niemniej jednak prawdziwą koncepcją konwencji nazewnictwa zmiennych jest przekazanie niezbędnego znaczenia i wyjaśnienie kodu. Pojęcia, które, jak twierdzę, są również ponadczasowe.

Wszystko, co mogę powiedzieć, z tego, co pamiętam (i szybki wgląd w moją czcigodną kopię CC), powiedziałbym, że z pewnością warto to przejrzeć.

Nie sądzę jednak, aby wznosiło się ono do naprawdę ponadczasowej natury The Mythical Man Month. MMM rozwiązuje problemy dotyczące tego, kto wykonuje pracę, w jaki sposób i dlaczego to robi; a także koszty i złożoność (ludzkiej) komunikacji. MMM rozwiązuje problemy, które są fundamentalne dla wszystkiego, co robimy. Dla porównania CC koncentruje się na praktycznych i pragmatycznych kwestiach związanych z tym, jak to robimy. Innymi słowy, jeśli projekt jest opóźniony, a kierownik decyduje się na dodanie do zespołu 100 osób, napisanie zrozumiałego kodu tak naprawdę nie robi różnicy.

CC tak naprawdę nie rozwiązuje istotnych problemów nękających naszą branżę; ale zapewnia dobrą podstawę do dążenia do najlepszego wyniku w często niemożliwej sytuacji.

Z pewnością uznałbym, że oba wymagają czytania dla każdego, kto dba o rozwój oprogramowania; i polecam ponowne przeczytanie MM, gdy będziesz potrzebować odświeżenia. CC warto ponownie przeczytać, jeśli kierujesz zespołem programistów, ustanawiasz standardy grupy lub szkolisz nowych programistów; poza tym osobiście uważam, że dawno temu zinternalizowałem materiał w CC i ćwiczyłem go codziennie.

Mam nadzieję, że to pomoże. Z pewnością są dwoma moimi ulubionymi.

Ogólnie rzecz biorąc, książka jest nadal dobra. Mam jednak kilka drobnych problemów:

• Rozdział 17 ( „Niezwykłe Struktury kontrolne”) robi oświadczenia straży wzmianka jako powrocie z funkcji wcześnie, ale przykłady podane w rozdziale 15 na „jeśli” Sprawozdania doradzić przeciwko sprawozdaniu straży. (Nazywane klauzulami ochronnymi / wczesne zwroty w książce)
• Przykład w sekcji 14.2 wydaje się zaprzeczać samemu sobie. Najpierw podaje przykład „złego” kodu i sposób uczynienia go „dobrym”. Następnie stwierdza, że ​​przy grupowaniu powiązanych ze sobą instrukcji, dane lub podobieństwo zadań byłoby „dobre”. „Zły” przykład należy zatem również uznać za „dobry” - i myślę, że jest dużo łatwiejszy do odczytania niż „dobry” przykład, ponieważ wszystkie dane są obliczane z tą samą szybkością - w twojej głowie jest mniej stanu do utrzymania .
• Rozdział 23, Debugowanie, w którym wypisywane są znaki wypunktowane w punkcie wypunktowanym. Chociaż zgadzam się, że nie powinny być jedynym narzędziem, są one niezwykle pomocne w zmniejszaniu zakresu kodu, w którym występuje błąd. Posyp kilka, aby zobaczyć, gdzie dane nagle nie są zgodne z oczekiwaniami, co stanowi dobry punkt wyjścia do debugowania, w zależności od kodu, z którym pracujesz.

Mam niejasne wspomnienie dotyczące innych argumentów funkcyjnych, ale w tej chwili nie mogę ich znaleźć. To mogła być kolejna książka.