Какие части Code Complete не выдержали испытание временем? [закрыто]

Я рассматривал Code Complete на полке и думал: «Вне Мистического Месяца Человека это может быть одна из немногих книг по разработке программного обеспечения для массового рынка, которая выдержит испытание временем». По этой причине я думаю о том, чтобы прыгнуть, чтобы перечитать это.

Мне любопытно - кто-нибудь еще недавно смотрел на него второй раз? Я так, ты видел что-нибудь, что он получил очень неправильно?

Это не атака и не просьба о рецензировании книги - меня больше интересует, какие идеи менялись с годами.

И, пожалуйста, не комментируйте: «Демарко / Спевак / Захман выдержали испытание временем…». Я особенно заинтересован в Code Complete из-за широты, которую он охватывает, и широты влияния, которое он оказал на поле.

Code Complete охватывает множество вечных концепций, таких как:

• сильная сплоченность
• Слабая связь
• хорошие рутины
• оборонительное программирование
• самодокументируемый код
• обзоры программного обеспечения
• модульное тестирование

которые, безусловно, актуальны сегодня.

Некоторые концепции, отстаиваемые в CC, теперь синтаксически применяются в более новых языках, например, C # не позволяет определять переменные в подобластях таким образом, чтобы скрывать определение в суперобласти.

Другие концепции, такие как венгерская нотация для имен переменных, отошли на второй план в массовом программировании (хотя любой, кто все еще работает с Win32 API, будет категорически утверждать, что они живы и здоровы). Тем не менее, реальная концепция, лежащая в основе соглашения о присвоении имен переменных, заключается в том, чтобы передать необходимое значение и прояснить код. Концепции, которые, я бы сказал, также вечны.

В общем, из того, что я могу вспомнить (и быстрый взгляд в мою почтенную копию CC), я бы сказал, что это, безусловно, стоит рассмотреть.

Я не думаю, однако, что это восходит к по-настоящему вневременной природе Мистического Месяца Человека. МММ решает вопросы о том, кто выполняет работу, как и почему она это делает; а также стоимость и сложность (человеческих) коммуникаций. МММ решает проблемы, которые являются основополагающими для всего, что мы делаем. Для сравнения, CC фокусируется на практических и прагматических вопросах того, как мы это делаем. Иными словами, если проект отстает от графика, а менеджер решает добавить в команду 100 человек, написание понятного кода на самом деле ничего не изменит.

CC на самом деле не решает значительных проблем, мешающих нашей отрасли; но это обеспечивает хорошую основу для достижения лучшего результата в зачастую невозможной ситуации.

Я бы, конечно, счел их обоих обязательными для прочтения всем, кто интересуется разработкой программного обеспечения; и я бы рекомендовал перечитывать ММ всякий раз, когда вам нужно освежиться. CC стоит перечитать, если вы возглавляете команду разработчиков, устанавливаете групповые стандарты или обучаете новых разработчиков; кроме того, я лично нахожу, что я давно усвоил материал в CC и практикую его ежедневно.

Надежды, которые помогают. Они, безусловно, два из моих любимых.

В целом книга все еще хороша. Тем не менее, у меня есть несколько небольших проблем:

• Глава 17 («Необычные структуры управления») упоминает защитные операторы как возвращающиеся из функции на раннем этапе, но примеры, приведенные в главе 15 относительно «если», дают советы против заявлений охраны. (Вызывается гвардейскими пунктами / досрочными возвратами в книге)
• Пример в разделе 14.2 противоречит сам себе. Сначала приводится пример «плохого» кода и как сделать его «хорошим». Затем утверждается, что при группировании связанных операторов вместе, либо по данным, либо по сходству задач, будет «хорошо». «Плохой» пример следует также считать «хорошим» - и, я думаю, его гораздо легче читать, чем «хороший» пример, поскольку все данные рассчитываются с одинаковой скоростью - в вашей голове меньше состояния ,
• Глава 23 «Отладка», где операторы печати вульгарно обозначаются маркером. Хотя я согласен с тем, что они не должны быть единственным инструментом, они чрезвычайно полезны для сокращения диапазона кода, в котором возникает ошибка. Посыпайте несколько штук повсюду, чтобы увидеть, где данные внезапно оказываются не такими, как вы ожидаете, что дает хорошую отправную точку для отладки в зависимости от кода, с которым вы работаете.

У меня есть смутная память о другом, включающем аргументы функции, но я не могу найти его в данный момент. Возможно, это была другая книга.