Совершенный код

Стив Макконнелл

Если бы я прочитал эту книгу года 3-4 назад, мне бы она показалась гораздо интересней...

Автор очень подробно описывает организацию кода (занимает первую половину книги), поэтому для тех, у кого с этим проблемы - это просто кладезь знаний. Вторая часть книги, которая посвящена усовершенствованию кода и конструированию, для меня оказалась более интересной. Поражает такое количество источников, из которых автор черпал материал для своей книги. Во многих главах приводятся результаты различных исследований в области разработки ПО, и хотя некоторые из них устарели, они все равно очень интересны и порой удивляют.

Достойная книга, которая содержит много интересных, а иногда и забавных мыслей:

• Независимо от экономических подъемов и спадов хороших программистов всегда не хватает, а жизнь слишком коротка, чтобы тратить ее на работу в отсталом учреждении при наличии множества лучших вариантов.
• Исправление ошибки к началу конструирования обходится в 10–100 раз дешевле, чем ее устранение в конце работы над проектом, во время тестирования приложения или после его выпуска.
• Не имея хорошего определения проблемы, можно потратить усилия на решение не той проблемы.
• Явные требования помогают гарантировать, что функциональность системы определяется пользователем, а не программистом.
• Требования подобны воде. Опираться на них легче, если они заморожены.
• Не имея хорошей архитектуры, вы можете решать правильную проблему, но прийти к неправильному решению.
• Ошибки проектирования часто являются довольно тонкими и объясняются эволюцией, при которой по мере реализации новых функций и возможностей разработчики забывают о сделанных ранее предположениях.
• Существует различие между программированием на языке и программированием с использованием языка. Разработчики, программирующие «на» языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемых языком. Разработчики, программирующие «с использованием» языка, сначала решают, какие мысли они хотят выразить, после чего определяют, как выразить их при помощи конкретного языка.
• Проблему нужно «решить» один раз, чтобы получить ее ясное определение, а затем еще раз для создания работоспособного решения.
• С шаблонами связаны две ловушки. Первая — насильственная адаптация кода к какому-нибудь шаблону. Вторая — применение шаблона, продиктованное не целесообразностью, а желанием испытать шаблон в деле.
• Поймите задачу, составьте план решения, осуществите план и оглянитесь назад, чтобы лучше понять, что и как вы сделали.
• Самым важным отличием хорошо спроектированного модуля от плохо спроектированного является степень, в которой модуль скрывает свои внутренние данные и другие детали реализации от других модулей.
• Цените легкость чтения кода выше, чем удобство его написания.
• Если для понимания того, что происходит, нужно увидеть реализацию, это не абстракция.
• Проектируйте и документируйте классы с учетом возможности наследования или запретите его.
• Весь смысл защитного программирования в защите от ошибок, которых вы не ожидаете.
• Программы, использующие исключения как часть нормальной работы алгоритма, страдают от всех проблем с читабельностью и удобством сопровождения так же, как и классический спагетти-код.
• Не теряйте время на вылизывание отдельных методов, пока не выяснится, что это необходимо.
• Разница между философией «удобства» и философией «интеллектуальной управляемости» сводится к различию между ориентацией на написание программы и ориентацией на ее чтение.
• Лучше стремиться к хорошему решению и избегать неудач, чем пытаться найти наилучшее решение.
• Компетентный программист полностью осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью (Это предполагает, что вы можете никогда не связываться с чрезмерной сложностью и всегда должны предпринимать шаги для ее уменьшения).
• Если бы строители возводили здания так, как программисты пишут программы, первый же дятел уничтожил бы цивилизацию.
• Главный Закон Контроля Качества ПО: лучшим способом повышения производительности труда программистов и качества ПО является минимизация времени, затрачиваемого на исправление кода, чем бы оно ни объяснялось: изменениями требований, изменениями проекта или отладкой.
• Программы — не люди, а ошибки — не микробы: программа не может нахвататься ошибок, общаясь с другими дефектными программами. Ошибки всегда допускают программисты.
• Если вы хотите улучшить ПО, вы должны не тестировать больше, а программировать лучше.
• Написание тестов до написания кода требует примерно того же времени и тех же усилий, что и создание тестов после кода, но сокращает циклы регистрации — отладки — исправления дефектов.
• Отлаживать код вдвое сложнее, чем писать. Поэтому, если при написании программы вы используете весь свой интеллект, вы по определению недостаточно умны, чтобы ее отладить.
• Если вы полагаете, что ошибок в вашем коде нет, найти их еще труднее.
• Интерактивный отладчик — великолепный пример инструмента, который не нужен: он поощряет хакерство методом проб и ошибок, а не систематичное проектирование и позволяет непрофессионалам скрыть свою некомпетентность.
• Не бывает кода, настолько громоздкого, изощренного или сложного, чтобы его нельзя было ухудшить при сопровождении.
• Крупномасштабный рефакторинг - путь к катастрофе.
• Во имя эффективности — причем достигается она далеко не всегда — совершается больше компьютерных грехов, чем по любой другой причине, включая банальную глупость.
• Принцип Парето, известный также как «правило 80/20», гласит, что 80% результата можно получить, приложив 20% усилий.
• Методология меньше влияет на качество кода, а наибольшее влияние на систему часто оказывает мастерство индивидуума, разрабатывающего эту программу.
• Обычно лучше сначала создать небольшие методы, а затем промасштабировать их для большого проекта, чем начать с создания универсального метода, а затем урезать его для маленького проекта.
• Измерение проекта может быть не абсолютно верным, его может быть трудно сделать и, возможно, придется временами уточнять, но измерение даст вам такой рычаг управления процессом разработки ПО, который вы не сможете получить иным способом.
• Любой дурак может написать код, понятный компьютеру. Хорошие программисты пишут код, понятный людям.
• Метки goto должны быть выровнены влево, состоять из заглавных букв и содержать имя программиста, его домашний телефон и номер кредитной карты.
• Пишите код, исходя из того, что все программисты, которые будут сопровождать вашу программу — склонные к насилию психопаты, знающие, где вы живете.
• На первые 90% кода приходятся первые 90% времени разработки. На оставшиеся 10% кода приходятся другие 90% времени разработки.
• Опыт может иметь разное качество. Если вы работаете 10 лет, получаете ли вы 10 лет опыта или 1 год опыта 10 раз?
• В своей обычной форме программирование представляет собой «мастерство», занимающее промежуточное место между искусством и наукой.

P.S. Данный список - это исключительно мой топ-лист, который может не совпадать с Вашим.