«Ясно, что на некотором уровне комментарии должны быть полезны. Думать иначе означало бы полагать, что понятность программы не зависит от того, сколько информации о ней уже известно читающему программу человеку. Б. Шейл.»
Действующие лица:
ФРАСИМАХ Неопытный пурист теории, который верит всему, что читает.
КАЛЛИКЛ Закаленный в боях представитель старой школы — «настоящий»
программист.
ГЛАВКОН Молодой, самоуверенный, энергичный программист.
ИСМЕНА Опытная разработчица, уставшая от громких обещаний и просто
желающая найти несколько работающих методик.
СОКРАТ Мудрый опытный программист.

Мизансцена:
Завершение ежедневного собрания группы
— Желает ли кто-то обсудить еще что-нибудь, прежде чем мы вернемся к работе? — спрашивает Сократ.
— Я хочу предложить стандарт комментирования для наших проектов, — говорит расимах. — Некоторые наши программисты почти не комментируют свой код, а всем известно, что код без комментариев нечитаем.
— Ты, должно быть, еще менее опытен, чем я думал, — отвечает Калликл. — Комментарии — это академическая панацея, и любому, кто писал реальные программы, известно, что комментарии затрудняют чтение кода, а не облегчают. Естественный язык менее точен, чем Java или Visual Basic, и страдает от избыточности, тогда как операторы языков программирования лаконичны и попадают в самое яблочко. Если кто-то не может написать ясный код, разве ему удастся написать ясные комментарии? Кроме того, комментарии устаревают при изменениях кода.
Доверяя устаревшим комментариям, ты сам себе роешь яму.

Пробный топик, представляет собой нарезку основных абзацев из книги из первой главы. Объем ужат в 4 раза, последовательность изложения и смысл по возможности сохранены. Очень приветствуется фидбэк.

Почему именно абзацы из книги, а не своими словами? Потому что во многих случаях сказать лучше очень сложно. И потом, чистые тезисы читать скучно — надоедает на второй странице.
Если топик понравится — готов стараться описать в статьях всю книгу, с каждым разом все уменьшая объем и увеличивая плотность информации.

Конструирование ПО

Что такое конструирование ПО?

Разработка ПО — непростой процесс, который может включать множество компонентов. Вот какие составляющие разработки ПО определили ученые за последние 25 лет:
— определение проблемы;
— выработка требований;
— создание плана конструирования;
— разработка архитектуры ПО, или высокоуровневое проектирование;
— детальное проектирование;
— кодирование и отладка;
— блочное тестирование;
— интеграционное тестирование;
— интеграция;
— тестирование системы;
— корректирующее сопровождение.

Иногда конструирование называют «кодированием» или «программированием».
«Кодирование» кажется мне в данном случае не лучшим термином, так как он
подразумевает механическую трансляцию разработанного плана в команды языка программирования, тогда как конструирование вовсе не механический процесс и часто связано с творчеством и анализом. Смысл слов «программирование» и «конструирование» кажется мне похожим, и я буду использовать их как равноправные.

Создал блог после опроса, готовлю статьи-конспекты «Совершенного кода» Макконнелла.

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

Присоединяйтесь, читайте, пишите!