Цитаты из книги "Совершенный код" С. Макконнелла

1. Разрыв между самыми лучшими и средними методиками разработки ПО очень широк — вероятно, шире, чем в любой другой инженерной дисциплине. Средство распространения информации о хороших методиках сыграло бы весьма важную роль.
   Фред Брукс

2. Установлено, что для широкого распространения исследовательских разработок обычно требуется от 5 до 15 и более лет.
3. Наибольшую пользу приносят те методики, которые можно использовать независимо от среды или языка.
4. Лично я лучше всего учусь на примерах. Думаю, это относится и к другим программистам.

5. Освоение более одного языка часто является поворотным пунктом в карьере профессионального программиста. Как только программист понимает, что принципы программирования не зависят от синтаксиса конкретного языка, он начинает приобретать знания, позволяющие достичь новых высот качества и производительности труда.

6. Проведение аналогий часто приводит к важным открытиям. Сравнив не совсем понятное явление с чем-то похожим, но более понятным, вы можете догадаться, как справиться с проблемой. Такое использование метафор называется «моделированием».

7. Фред Брукс пишет: «Планируйте выбросить первый экземпляр программы: вам в любом случае придется это сделать».

8. При инкрементной разработке вы сначала создаете самую простую версию системы, которую можно было бы запустить. Она может не принимать реальных данных, может не выполнять над ними реальных действий, может не генерировать реальные результаты — она должна быть просто скелетом, достаточно крепким, чтобы поддерживать реальную систему по мере ее разработки.

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

10. Поработав над несколькими крупными программами, вы прекрасно поймете пользу заблаговременного планирования.

11. Независимо от экономических подъемов и спадов хороших программистов всегда не хватает
12. Общий принцип прост: исправлять ошибки нужно как можно раньше.
13. Первое предварительное условие, которое нужно выполнить перед конструированием, - ясное формулирование проблемы, которую система должна решать.
14. Архитектура должна четко определять ответственность каждого компонента. Компонент должен иметь одну область ответственности и как можно меньше знать об областях ответственности других компонентов. Сведя к минимуму объем сведений, известных компонентам о других компонентах, вы сможете локализовать информацию о проекте приложения в отдельных компонентах.
15. Язык программирования, на котором будет реализована система, заслуживает большого внимания, так как вы будете погружены в него с начала конструирования программы до самого конца.
16. Программисты, использующие язык, с которым они работали три года или более, примерно на 30% более продуктивны, чем программисты, обладающие аналогичным опытом, но для которых язык является новым.
17. Подход к программированию не должен определяться используемыми инструментами. В связи с этим он проводит различие между программированием на языке (programming in language) и программированием с использованием языка (programming into language). Разработчики, программирующие «на» языке, ограничивают свое мышление конструкциями, непосредственно поддерживаемых языком. Если предоставляемые языком средства примитивны, мысли программистов будут столь же примитивными.
18. Большинство важных принципов программирования зависит не от конкретных языков, а от способа их использования. Если язык не поддерживает нужные конструкции или имеет другие недостатки, попробуйте их компенсировать. Создайте свои конвенции кодирования, стандарты, библиотеки классов и другие средства.
19. Проекты приложений не возникают в умах разработчиков сразу в готовом виде. Они развиваются и улучшаются в ходе обзоров, неформальных обсуждений, написания кода и выполнения его ревизии.
20. Дейкстра пишет, что ни один человек не обладает интеллектом, способным вместить все детали современной компьютерной программы, поэтому нам - разработчикам ПО — не следует пытаться охватить всю программу сразу Вместо этого мы должны попытаться организовать программы так, чтобы можно было безопасно работать с их отдельными фрагментами по очереди. Целью этого является минимизация объема программы, о котором нужно думать в конкретный момент времени.
21. Работая над проблемой, я никогда не думаю о красоте. Я думаю только о решении проблемы. Но если полученное решение некрасиво, я знаю, что оно неверно. Р. Бакминстер Фуллер
22. Избегайте создания «хитроумных» проектов: как правило, их трудно понять. Вместо этого создавайте «простые» и «понятные» проекты. Если при работе над отдельным фрагментом программы проект не позволяет безопасно игнорировать большинство остальных фрагментов, он неудачен.
23. Расширяемостью системы называют свойство, позволяющее улучшать систему, не нарушая ее основной структуры. Изменение одного фрагмента системы не должно влиять на ее другие фрагменты. Внесение наиболее вероятных изменений должно требовать наименьших усилий.
24. Проектируйте систему так, чтобы ее фрагменты можно было повторно использовать в других системах.
25. Дорога в ад программирования вымощена глобальными переменными
26. В число популярных шаблонов проектирования входят Адаптер, Мост, Декоратор, Фасад, Фабричный метод, Наблюдатель, Одиночка, Стратегия и Шаблонный метод. Старайтесь использовать популярные шаблоны проектирования.
27. Одним из самых ценных советов, которые можно дать по поводу проектирования ПО, является использование разных подходов. Если проект, разработанный с помощью UML, неудачен, выразите его на обычном языке. Напишите небольшую тестовую программу. Попробуйте совершенно другой подход. Подумайте об использовании грубой силы. Продолжайте рисовать эскизы и наброски карандашом, и мозг последует за рукой. Если ничего не выходит, отложите решение проблемы. Прежде чем возвращаться к работе над ней, прогуляйтесь, подумайте о чем- то другом. Довольно часто это приводит к более быстрому получению нужного  результата, чем простое упорство.
28. Никто не заставляет вас разработать весь проект за раз. Если натолкнетесь на препятствие, подумайте, обладаете ли вы информацией, достаточной для решения всех специфических проблем? Зачем через силу разрабатывать оставшиеся 20% проекта, если впоследствии они прекрасно станут на свое место? Зачем принимать неудачные решения, основанные на недостаточной информации, если позже можно будет принять более подходящие решения?
29. Если первая попытка создания проекта кажется вполне удачной - не останавливайтесь! Вторая попытка почти всегда варианты кода предоставляет оказывается лучше первой, и при каждой попытке вы будете узнавать что-то такое, что поможет вам улучшить общий проект. Говорят, что, когда Томаса Эдисона, который пытался создать нить лампочки и испробовал на тот момент уже тысячу разных материалов, спросили, не жалеет ли он о том, что зря потратил время, так ничего и не обнаружив, Эдисон ответил: «Ни в коей мере. Я обнаружил тысячу вариантов, которые не работают». Во многих случаях, решив проблему при помощи одного подхода, вы получите знания, которые позволят решить проблему иным, более эффективным способом.
30. "Механические действия начинают вытеснять творчество"
31. «Чем догматичнее вы будете в отношении методики проектирования, тем меньше реальных проблем решите» Ф. Дж. Плоджер
32. Соблюдайте принцип подстановки Лисков (Liskov Substitution Principle, ISP) Барбара Лисков как-то заявила, что наследование стоит использовать, только если  производный класс действительно «является» более специализированной версией базового класса. Энди Хант и Дэйв Томас сформулировали LSP так: «Клиенты должны иметь возможность использования подклассов через интерфейс базового класса, не замечая никаких различий». Иначе говоря, все методы базового класса должны иметь в каждом производном классе то же значение.
33. «Правило Деметры (Law of Demeter)», которое гласит, что Объект А может вызывать любые из собственных методов. Если он создает Объект В, он может вызывать любые методы Объекта В, но ему не следует вызывать методы объектов, возвращаемых Объектом В.
34. Одним из признаков того, что метод следует разделить, является глубокая вложенность внутренних циклов или условных операторов. Упростите такой метод, выделив вложенную часть в отдельный метод.
35. Наша цель в том, чтобы каждый метод эффективно решал одну задачу и больше ничего не делал. Вознаграждением будет более высокая надежность кода. В одном исследовании 450 методов было обнаружено, что дефекты отсутствовали в 50% методов, обладающих высокой связностью, и только в 18% методов с низкой связностью.
36. В защитном программировании главная идея в том, что если методу передаются некорректные данные, то его работа не нарушится, даже если эти данные испорчены по вине другой программы. Обобщая, можно сказать, что в программах всегда будут проблемы, программы будут модифицироваться и разумный программист будет учитывать это при разработке кода.
37. Если вы оставляете в программе внутренние сообщения об ошибках, проверьте, что они дружественны к пользователю. Пользователь одной из моих первых программ сообщила мне, что получила сообщение, гласившее: «У тебя неправильно выделена память для указателя, черт возьми!» К счастью для меня, у нее было чувство юмора.