Рассмотрим две крайности - полное отсутствие формализованного жизненного цикла разработки и очень жесткие, строго соблюдаемые правила разработки. В первом случае мы имеем анархию. (...) Во втором случае мы имеем диктатуру, в которой инициативы наказуемы, экспериментирование, которое могло бы привнести больше элегантности в архитектуру, не поощряется, и действительные требования заказчика никогда корректно не доходят до разработчиков нижнего уровня, скрытых за настоящей бумажной стеной, воздвигнутой бюрократией.
Встречавшиеся нам удачные объектно-ориентированные проекты не следовали ни анархическому, ни драконовскому жизненному циклу. Зато мы заметили, что удачная объектно-ориентированная архитектура создается в итеративно развивающемся процессе. Стр.225.
Любая человеческая деятельность, которая требует творчества и инноваций, идет путем проб и ошибок, итеративно развивающегося процесса, который опирается на опыт, компетентность и талант каждого члена коллектива. Стр. 226.
Очень плохая практика - нанимать архитектора со стороны, который, образно выражаясь, въезжает на белом коне, провозглашает архитектурные принципы, а потом уматывает куда-то, в то время как другие пытаются справиться с последствиями его решений. Стр.262.
Остерегайтесь аналитиков и архитекторов, если они не хотят или не могут выразить конкретную семантику своих абстракций; это признак надменности или беспомощности. Стр.234.
К сожалению, некоторые менеджеры больше заинтересованы в развитии своей империи, чем в развитии программного продукта. Стр.240.
Возможно, самое важное для организации - создать структуру, которая обеспечивала бы достаточные ресурсы для возникновения и исследования новых идей. Если организация не сделает это сама, то отдельные разработчики все равно сделают это, не спрашиваясь у компании, в которой они работают. Так и возникают новые программистские фирмы. Их появление хорошо для индустрии в целом, но не для самой осиротевшей компании. Стр.242.
... даже большие системы имеют тенденцию к эволюции в процессе их использования: следовательно, встает задача о том, что часто неправильно называют сопровождением программного обеспечения. ... под сопровождением понимается устранение ошибок; под эволюцией - внесение изменений в систему в ответ на изменившиеся требования к ней; под сохранением - использование всех возможных и невозможных способов для поддержания жизни в дряхлой и распадающейся на части системе. Стр.23.
Леман и
Белади:
Эксплуатируемая
программа должна непрерывно
изменяться; в противном случае она
будет становиться все менее и менее
полезной (закон непрерывного
изменения).
Когда
эволюционирующая программа
изменяется, ее структура
становится более сложной, если не
прилагаются активные усилия, чтобы
этого избежать (закон возрастающей
сложности). Стр.254.
Если цена владения программным продуктом выше, чем цена разработки новой системы, то наиболее гуманный образ действий - оставить старую систему в покое или покончить с ней. Стр.254.
Какая декомпозиция сложной системы правильнее - по алгоритмам или по объектам? ... правильный ответ на него: важны оба аспекта. Разделение по алгоритмам концентрируют внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Однако мы не можем сконструировать сложную систему одновременно двумя способами, тем более что эти способы, по сути, ортогональны. Мы должны начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения. Опыт показывает, что полезнее начинать с объектной декомпозиции. Стр.34.
Проектирование сложной программной системы отнюдь не сводится к слепому следованию некоему набору рецептов. Стр.39.
Объектно-ориентированный анализ и проектирование отражают эволюционное, а не революционное развитие проектирования; новая методология не порывает с прежними методами, а строится с учетом предшествующего опыта. Стр.49.
В частности, программирование, не основанное на иерархических отношениях, не относится к OOP, а называется программированием на основе абстрактных типов данных. Стр.52.
Невозможно признать какой-либо стиль программирования наилучшим во всех областях применения. Стр.54.
Благодаря своему происхождению, гибридные языки, такие как C++, Object Pascal и CLOS, позволяют разработчику применять как процедурный, так и объектно-ориентированный стиль программирования.
Свободные подпрограммы часто возникают во время анализа и проектирования на границе объектно-ориентированной системы и ее процедурного интерфейса с внешним миром. Стр.184.
Как правило, хорошая архитектура тяготеет к объектной ориентированности. Это не означает, что любая объектно-ориентированная архитектура оказывается хорошей, или что хороша только объектно-ориентированная архитектура. Стр.224.
Признак добротности архитектуры - ее концептуальное единство и целостность. Стр.224.
На самом деле, объектно-ориентированная технология не порождает качества автоматически: можно написать сколь угодно плохие программы на любом объектно-ориентированном языке программирования. Стр.267.
Для сложных систем наибольший риск состоит в том, будет или нет система завершена, а не в том, будет ли она удовлетворять требованиям эффективности. Стр.274.
Микаллеф: "Если правила образования типов основаны на наследовании, и мы переделываем какой-нибудь класс так, что меняется его положение в иерархии наследования, клиенты этого класса могут оказаться вне закона с точки зрения типов, несмотря на то, что внешний интерфейс класса остается прежним". Стр.126.
Классы, составляющие лес, независимы друг от друга, но, вероятно, не лучшим образом используют возможности специализации и обобществления кода. В случае дерева классов эта "коммунальность" используется максимально, поэтому каждый из классов имеет меньший размер. Однако в последнем случае классы невозможно понять без контекста всех их предков. Стр.142.
Нет абсолютного критерия классификации, одна и та же структура классов может подходить для одной задачи и не годиться для другой. Стр.153.
Джеймс: "Нельзя утверждать, что некоторая схема классификации лучше других отражает структуру и порядок вещей в природе. Природе безразличны наши попытки в ней разобраться. Некоторые классификации действительно важнее других, но только в связи с нашими интересами, а не потому, что они вернее или полнее отражают реальность". Стр.153.
Определяющей характеристикой идиомы является то, что ее игнорирование или нарушение влечет немедленные социальные последствия: вы превращаетесь в йеху или, еще хуже, в чужака, не заслуживающего уважения.
Изучая язык, приходится учить его идиомы, которые обычно передаются в форме фольклора.Стр.165.
Плохой разработчик, имея систему автоматического проектирования, сможет создать своего программного монстра за более короткий срок, чем раньше. Великие проекты создаются великими проектировщиками, а не инструментами.
Никакая автоматическая система не сможет выявить новый класс, чтобы упростить систему классов. Стр.175-176.
Программисты-любители все время ищут какой-то волшебный инструмент, который мог бы делать процесс разработки программ тривиальным. Признак профессионализма - понимание того, что такой панацеи не существует. Любители стремятся действовать по "поваренной книге"; профессионалы же знают, что безупречно грамотный подход ведет к нелепым проектным решениям. Стр.223.
Построение удобного интуитивного и дружественного пользователю интерфейса - скорее искусство, чем наука. В приложениях, построенных в рамках архитектуры клиент/сервер, именно качество интерфейса определяет (в большинстве случаев) популярность тех или иных программ. Стр.394.
Самые элегантные решения никогда не будут использованы, если сроки их освоения превысят время, необходимое программисту для решения проблемы своими силами. Сказать, что эффект достигнут, можно будет только когда станет видно, что ваши абстракции используются повторно много раз. То есть, когда разработчик ощутил преимущества их использования и не изобретает велосипед, а сосредоточивает внимание на тех особенностях задачи, которые еще никем не были решены. Стр.363.