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

14

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.

MathAttack
źródło
1
Szybkie ponowne jej przeanalizowanie przypomniało mi o irytacjach, w których tekst wydaje się zaprzeczać przykładom, a różne części książki zalecają różne rzeczy. Poza tym nadal wydaje się całkiem niezły.
Izkata
@Izkata - przykłady?
MathAttack 12.12. O
Dodano jako odpowiedź
Izkata
1
Dobre pytanie, ostatnio zastanawiałem się, czy sam go ponownie przeczytać. Zastanawiam się, czy są plany nowej edycji?
Antonio2011a,
2
Studiowałem Code Complete (2. edycja) latem ubiegłego roku i tam nie czułem się przestarzały. O ile nie nastąpią radykalne nieoczekiwane zmiany w rozwoju oprogramowania, myślę, że zaleciłbym tę książkę za co najmniej pięć lat.
komara

Odpowiedzi:

11

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.

Robert Altman
źródło
Być może powinienem stworzyć podobne Q dla MM. Być może Brooks miał łatwiej, odkąd napisał książkę o zarządzaniu.
MathAttack,
Czy CC nie rozwiązuje problemu „kto wykonuje pracę” w rozdziale 33: Charakter osobisty?
mg1075
4

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.

Izkata
źródło
6
Tak, mylił się wtedy w sprawie drukowanych oświadczeń i nadal się myli. W przypadku błędu w nieznanej lokalizacji odbitki i dzienniki są na ogół moim wyborem.
Loren Pechtel,