Які частини Code Complete не витримали випробування часом? [зачинено]

Я дивився на Code Complete на полиці, думаючи: "Поза міфічним місяцем людини, це може бути однією з небагатьох книг масової інженерії програмного забезпечення, яка витримає випробування часом". З цієї причини я думаю застрибнути, щоб перечитати його.

Мені цікаво - хто-небудь ще недавно поглянув на це? Я так, ти бачив щось, що він дуже помилявся?

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

І будь ласка - жодних коментарів щодо: "Demarco / Spewak / Zachman витримав перевірку часом ..." Я спеціально зацікавлений у "Кодексі повного" через широту землі, яку він охоплює, та широту впливу, який він мав на полі.

Code Complete охоплює безліч позачасових понять, таких як:

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

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

Деякі з концепцій, що входять до складу CC, тепер синтаксично застосовуються новішими мовами, наприклад, C # не дозволяє визначати змінну в під-діапазоні таким чином, що приховує визначення супер-масштабу.

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

Все сказане, з того, що я можу пригадати (і швидкий погляд у мою поважну копію CC), я б сказав, що це, безумовно, варто переглянути.

Я не думаю, що це піднімається до справді вічної природи Міфічного місяця людини. MMM вирішує питання того, хто виконує роботу, як і навіщо це виконує; а також витрати та складність (людських) комунікацій. MMM вирішує проблеми, які є основними для всього, що ми робимо. CC, порівняно, зосереджується на практичних та прагматичних питаннях того, як ми це робимо. По-іншому, якщо проект не відповідає графіку, і менеджер вирішує додати до команди 100 осіб, написання зрозумілого коду насправді не змінить значення.

КК насправді не вирішує значних питань, що заважають нашій галузі але це дає хороший фундамент для прагнення до найкращого результату у часто неможливій ситуації.

Я б, звичайно, вважав їх обома необхідними для читання для всіх, хто дбає про розробку програмного забезпечення; і я рекомендую перечитати MM, коли вам потрібно оновити. CC варто перечитати, якщо ви очолюєте команду розробників, встановлюєте групові стандарти або навчаєте нових розробників; поза цим я особисто знаходжу, що я давно інтерналізував матеріал у ЦК та практикую його щодня.

Сподіваємось, що це допомагає. Вони, безумовно, два мої улюблені.

Загалом книга все ще гарна. Однак у мене є кілька невеликих проблем з цим:

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

У мене розпливчаста пам'ять про інший, що включає аргументи функції, але наразі не можу його знайти. Можливо, це була інша книга.