совершенный код книга о чем
Субьективная выжимка из «Совершенный код:2 издание» Стива Макконнелла
Сегодня я дочитал очень интересный и многообразный труд по программированию «Совершенный код: 2 издание» Стива Макконнелла. Немного посидев, я решил составить небольшую выдержку из этой книги, дабы и свою память время от времени освежать, ну и может пригодится кому-то тоже. Фрагменты из книги копировать не буду, все-таки это чужой труд. Исключение составит лишь библиографический список, приведенный в конце книги. Итак:
Первая мысль, которая осталась после прочтения звучит: «Программируйте не на языке, а с помощью языка». Иными словами: не нужно зацикливаться на том языке, который Вы изучаете или знаете лучше всего. Используйте язык в зависимости от поставленной задачи. А для решения разных задач, как известно, разные языки могут быть более предпочтительными.
«Код пишут не для компьютера, а для человека» — тоже интересная мысль. Многие думают, что программировать, это значит давать команды компьютеру что-либо делать. По сути, это, конечно, так и есть. НО! Не стоит забывать, что текст программы должен быть понятен тому, кто его будет смотреть, править, изменять. Если рассуждать о том, что программировать — это командовать компьютером, тогда зачем нам высокоуровневые языки? Зачем нам различные фреймворки и тд? Давайте писать на ассемблере или вообще в двоичном виде, все равно же мы для компьютера пишем, а ему двоичное роднее. Тут не стоит вопрос об удобности или ускорения программирования, здесь стоит вопрос о формировании такой культуры программирования, в которой человеку в первую очередь должно быть понятно что и как делается в программе. Компьютер он и так поймет, но вот поймет ли человек, зависит от того, насколько мы будем придерживаться раскрываемого принципа.
Из этой мысли вытекают несколько других принципов: «Если это возможно, не используйте GOTO». Для понимания чего-либо человеку удобно видеть информацию в логичном, систематизированном виде. Каким бы Вы не были высокоразвитой или творческой личностью, информация легче усваивается, если она выкладывается, подчиняясь определенной логике. Программу легче понять, когда функция идет за функцией. Заканчивается одно, начинается другое. Оператор «GOTO» нарушает подобную конструкцию. Он позволяет произвольно перепрыгивать из одного места в другое. Программа выполняется, но плохо понимается. Точнее, долго понимается. Есть сторонники и противники «GOTO», ведутся дискуссии, но, думаю, для нас можно просто решить это не использовать.
Также в эту группу можно включить «Не используйте циклы, вложенность которых больше 3-х». Я сам не раз сталкивался с проблемой понимания многосложных циклов. Было ощущения, что это как-то неправильно, неудобно, хотя и работает. Для осознания этой мысли и формализации в словесную форму надо было почитать эту книгу.
«Комментируйте свой код». Думаю, это очень даже логично. Несмотря на всякие там «Хороший код не нуждается в комментировании, он самопонятен», или «Не нужно заполонять экран лишними символами», или «Хочешь объяснить код – пиши документацию отдельно» и все такое. Это все понятно. Но мне кажется, что хороший комментарий имеет право на жизнь. В книге, кстати, приводятся различные смысловые и визуальные реализации комментариев. Об этом как-то не задумываешься, но, прочитав, начинаешь это замечать и использовать.
«Начиная писать программу, составь для себя конвенцию стиля-форматирования». Думаю, эта мысль более актуальна для новичков-программистов. Несмотря на дискуссии о «правильности» того или иного форматирования (4 пробела или 2, открывающая скобка в конце строки или с начала следующей и тд.), важно избрать для себя какой-то один стиль и максимально, но без фанатизма придерживаться его. Даже если тот программист, который пишет в другом стиле, будет просматривать Ваш код, ему будет легко его читать, даже несмотря на различность стиля. Сначала Вы составите для себя правило форматирования, потом оно станет просто привычкой.
«Сначала подумай, потом пиши или семь раз отмерь, потом режь». Неплохо, прежде чем начинать писать интерфейс контроллера, подумать о программе глобально. Что она будет делать, что куда будет передаваться, что где будет храниться и кому что будет видно. Буквально недавно я начал писать для себя технические задания сам, для, так сказать, организации труда. До этого было как-то лень или я думал, что все и так понятно. Но, как оказалось, озвучивание того, что я собираюсь делать очень даже полезная вещь (Кто бы мог подумать?). Как в кувшин, сначала закидываем большие камни, потом поменьше, потом еще меньше, потом песочек и вуаля, кувшин – полон и все влезло как надо.
«Этапы формирования программы: планирование->разработка->тестирование->отладка». Думаю, логично, во время тестирования своего творения заниматься именно тестированием, а не продумывать как бы еще и чего бы добавить. Часто бывает, что во время разработки становится понятно, что что-то идет не так. Ну, неудобно как-то все. И вместо того, чтобы реализовывать приходиться опять планировать. Чтобы как можно реже это воспроизводить, предлагается доводить каждый этап до конца и в своем порядке.
«KISS, DRY, YAGNI, DIE». Всем известные принципы, которые, почему-то известны не всем. Все это американские аббревиатуры. По-русски звучат как: делай проще, не повторяйся, тебе это не понадобится и дублирование — зло.
«80% времени тратится на реализацию 20% функционала». Иными словами, большую часть времени реализации мы тратим на какие-то мелочи. Все бы ничего, но, возможно, в этих мелочах вовсе нет надобности. Нужно суметь правильно расставить приоритеты и уделять время на то, что действительно важно.
«Сначала неприятное». Думаю, что у всех разработчиков есть какие-то вещи, которые ну не очень хочется делать. Кто-то не любит базы данных, кто-то не любит возиться с AJAX или еще что-нибудь. Переносить на неопределенное время то, что неприятно неправильно. Когда, например, так делаю я, то процесс разработки несколько увеличивается. Я чувствую, что вот-вот, еще немного, и надо будет заниматься этим самым, «неприятным». И вдруг обнаруживается, что вот в этом месте можно покрасивее функцию сделать. Здесь отступов меньше, чем надо и в таком духе. Это лично у меня так.
«Образование и чтение, совершенствование и оттачивание». Ни для кого не секрет, что нужно в нашем современном мире образовываться практически без остановки. Читать, общаться с гуру, все такое. Особенно если Вы разработчик мобильных приложений (шутка). Так вот читать в неделю 35 страниц тематической литературы – это обязательно. Остановимся на этом.
«Разделения труда, разделение программ, разделяй и властвуй». Сегодня, слава богам, существуют различные методики разделения команд и труда для аккуратной, быстрой и адекватной работы(методики управления проектами). Различные SCRUM, AGILE, внутренние программы. Сегодня, слава богам, существуют различные методики разделения кода(системы контроля версий). Различные GIT, SVN, Mercurial. Так давайте все это использовать (когда удобно, конечно)!
«Говорящие фамилии». Чуть не забыл про названия. Это вытекает логичным образом из формирования своего, всем понятного стиля. Сюда относится: называние классов с большой буквы все слова, называние функций с маленькой буквы и остальные слова с большой, называние констант ВСЕ_БОЛЬШИЕ_БУКВЫ и так далее. Такие мелочи очень помогают и ускоряют понимание.
Думаю, можно закончить мою двухколесную выдержку. Общее ощущение от книги положительное. Хотя иногда возникало ощущение, что эта книга написана ни для кого. Т.е. вроде для профессионального (опытного) программиста это все и так должно быть понятно, а для начинающего много того, что, по сути, не совсем понятно. Даже самое первое «с языком, а не на языке» для начинающего, знающего только один язык, может быть не совсем ясно. Ну а для гуру многостраничные рассказы про комментарии и названия вообще могут вызвать недоумение. Если преодолеть некоторый дискомфорт, связанный с этими моментами (если он, конечно, возникнет), то читать можно. Как Чехова, не хуже.
ОЗОН прислал мне еще книги: «Мифический человеко-месяц», «Приемы объектно-ориентированного программирования: паттерны проектирования» и «Анализ алгоритмов». Если кому интересно что-то, могу прочитать и тезисно изложить. Или выделить какие-то особенно интересные для вас моменты. Также принимаю конструктивную критику и пожелания прекратить марать бумагу. Всем удачи!
Совершенный код.
Практическое руководство по разработке программного обеспечения
Автор: Стив Макконнелл
Издательство: Русская Редакция, Питер, 2005
896 страниц
Материал предоставили: Алексей Кирюшкин
Илья Рыженков
Аннотация
Отзывы
«Современное ПО должно быть надежным и гибким, а создание защищенного кода начинается с дисциплинированного конструирования программы. За десять лет так и не появилось лучшего руководства по этой теме, чем эта книга.»
Майкл Ховард, специалист по защите ПО, корпорация Microsoft; один из авторов книги «Writing Secure Code»
Содержание
14 Организация последовательного кода
Предисловие
Хотя передовые методики разработки ПО в последние годы быстро развивались, общепринятые практически стояли на месте. Многие программы все еще полны ошибок, поставляются с опозданием и не укладываются в бюджет, а многие не отвечают требованиям пользователей. Ученые обнаружили эффективные методики, устраняющие большинство проблем, которые отравляют нашу жизнь с 1970-х годов. Однако из-за того, что эти методики редко покидают страницы узкоспециализированных технических изданий, в большинстве компаний по разработке ПО они еще не используются. Установлено, что для широкого распространения исследовательских разработок обычно требуется от 5 до 15 и более лет (Raghavan and Chand, 1989; Rogers, 1995; Parnas, 1999). Данная книга призвана ускорить этот процесс и сделать важные открытия доступными средним программистам.
КОМУ СЛЕДУЕТ ПРОЧИТАТЬ ЭТУ КНИГУ?
Исследования и опыт программирования, отраженные в этой книге, помогут вам создавать высококачественное ПО и выполнять свою работу быстрее и эффективнее. Прочитав ее, вы поймете, почему вы сталкивались с проблемами в прошлом, и узнаете, как избегать их в будущем. Описанные мной методики программирования помогут вам сохранять контроль над крупными проектами, а также успешно сопровождать и изменять ПО при изменении требований.
Если вы не имеете специального образования, вы не одиноки. Ежегодно программистами становятся около 50000 человек (BLS, 2004, Hecker 2004), однако число дипломов, вручаемых ежегодно в нашей отрасли, составляет лишь около 35000 (NCES, 2002). Легко прийти к выводу, что многие программисты изучают разработку ПО самостоятельно. Программисты-самоучки встречаются среди инженеров, бухгалтеров, ученых, преподавателей, владельцев малого бизнеса и представителей других профессий, которые занимаются программированием в рамках своей работы, но не всегда считают себя программистами. Каким бы ни было ваше программистское образование, в этом руководстве вы найдете информацию об эффективных методиках программирования.
ГДЕ ЕЩЕ МОЖНО НАЙТИ ЭТУ ИНФОРМАЦИЮ?
В этой книге собраны методики конструирования из самых разнообразных источников. Многие знания о конструировании не только разрозненны, но и годами не попадают в печатные издания (Hildebrand, 1989; МсСоппеll, 1997а). В эффективных, мощных методиках программирования, используемых лучшими программистами, нет ничего мистического, однако в повседневной череде неотложных задач очень немногие эксперты выкраивают время на то, чтобы поделиться своим опытом. Таким образом, программистам трудно найти хороший источник информации о программировании.
Как показано ниже, информация, представленная в этой книге, выжата из многих источников. Единственным другим способом получения этой информации является изучение горы книг и нескольких сотен технических журналов, дополненное значительным реальным опытом. Если вы уже проделали все это, данная книга все равно окажется вам полезной как удобный справочник.
ГЛАВНЫЕ ДОСТОИНСТВА ЭТОЙ КНИГИ
Какой бы ни была ваша ситуация, эта книга поможет вам создавать более качественные программы за меньшее время с меньшей головной болью.
Полное руководство по конструированию ПО.
В этой книге обсуждаются такие общие аспекты конструирования, как качество ПО и подходы к размышлению о программировании. В то же время мы погрузимся в такие детали конструирования, как этапы создания классов, использование данных и управляющих структур, отладка, рефакторинг и методики и стратегии оптимизации кода. Чтобы изучить эти вопросы, вам не нужно читать книгу от корки до корки. Материал организован так, чтобы вы могли легко найти конкретную интересующую вас информацию.
Готовые к использованию контрольные списки
Эта книга включает десятки контрольных списков, позволяющих оценить архитектуру программы, подход к проектированию, качество классов и методов, имена переменных, управляющие структуры, форматирование, тесты и многое другое.
Самая актуальная информация
В этом руководстве вы найдете описания ряда самых современных методик, многие из которых еще не стали общепринятыми. Так как эта книга основана и на практике, и на исследованиях, рассмотренные в ней методики будут полезны еще многие годы.
Более общий взгляд на разработку ПО
Эта книга даст вам шанс подняться над суетой повседневной борьбы с проблемами и узнать, что работает, а что нет. Мало кто из практикующих программистов обладает временем, необходимым для прочтения сотен книг и журнальных статей, обобщенных в этом руководстве. Исследования и реальный опыт, на которых основана данная книга, помогут вам проанализировать ваши проекты и позволят принимать стратегические решения, чтобы не приходилось бороться с теми же врагами снова и снова.
Некоторые книги по программированию содержат 1 грамм информации на 10 граммов рекламы. Здесь вы найдете сбалансированные обсуждения достоинств и недостатков каждой методики. Вы знаете свой конкретный проект лучше всех, и эта книга предоставит вам объективную информацию, нужную для принятия грамотных решений в ваших обстоятельствах.
Независимость от языка
Описанные мной методики позволяют выжать максимум почти из любого языка, будь то С++, С#, Java, Microsoft Visual Basic или другой похожий язык.
Многочисленные примеры кода
Эта книга содержит почти 500 примеров хорошего и плохого кода. Их так много потому, что лично я лучше всего учусь на примерах. Думаю, это относится и к другим программистам.
Примеры написаны на нескольких языках, потому что освоение более одного языка часто является поворотным пунктом в карьере профессионального программиста. Как только программист понимает, что принципы программирования не зависят от синтаксиса конкретного языка, он начинает приобретать знания, позволяющие достичь новых высот качества и производительности труда.
Чтобы как можно более облегчить бремя применения нескольких языков, я избегал редких возможностей языков, кроме тех фрагментов, в которых именно они и обсуждаются. Вам не нужно понимать каждый нюанс фрагментов кода, чтобы понять их суть. Если вы сосредоточитесь на обсуждаемых моментах, вы сможете читать код на любом языке. Чтобы сделать вашу задачу еще легче, я пояснил важные части примеров.
Доступ к другим источникам информации
В данном руководстве приводятся подробные сведения о конструировании ПО, но едва ли это последнее слово. В разделах «Дополнительные ресурсы» я указал другие книги и статьи, которые вы можете прочитать, если заинтересуетесь той или иной темой.
Обновленные контрольные списки, списки книг и журнальных статей, Web-ссылки и другую информацию можно найти на Web-сайте http://сс2е.com для получения информации, связанной с «Code Complete, 2d ed.», введите в браузере сс2е.соm/ и четырехзначное число, пример которого показан слева. Читая книгу, вы много раз натолкнетесь на такие ссылки.
ЧТО ПОБУДИЛО МЕНЯ НАПИСАТЬ ЭТУ КНИГУ?
Необходимость руководств, отражающих знания об эффективных методиках разработки ПО, ясна всем членам сообщества разработчиков. Согласно отчету совета Computer Science and Technology Board максимальное повышение качества и продуктивности разработки ПО будет достигнуто благодаря систематизации, унификации и распространению существующих знаний об эффективных методиках разработки (CSTB, 1990; МсСоnnеll, 1997а). Совет пришел к выводу, что стратегия распространения этих знаний должна быть основана на концепции руководств по разработке ПО.
Тема конструирования игнорировалась
Одно время разработка ПО и кодирование рассматривались как одно и то же. Однако по мере идентификации разных процессов цикла разработки ПО лучшие умы отрасли стали посвящать время анализу и обсуждению методик управления проектами, выработки требований, проектирования и тестирования. Из-за пристального внимания к этим новым областям конструирование кода превратилось в бедного родственника разработки ПО.
Кроме того, обсуждению конструирования препятствовало предположение, согласно которому подход к конструированию как к отдельному процессу разработки ПО подразумевает, что конструирование нужно рассматривать при этом как отдельный этап. На самом деле процессы и этапы разработки не обязаны быть связаны какими-то отношениями, и обсуждение процесса конструирования полезно независимо от того, выполняются ли другие процессы разработки ПО как этапы, итерации или как-то иначе.
Другая причина того, что конструирование игнорируется учеными и авторами, заключается в ошибочной идее, что в сравнении с другими процессами разработки ПО конструирование является относительно механическим процессом, допускающим мало возможностей улучшения. Ничто не может быть дальше от истины.
На конструирование кода обычно приходятся около 65% работы в небольших и 50% в средних проектах. Во время конструирования допускаются около 75% ошибок в небольших проектах и от 50 до 75% в средних и крупных. Очевидно, что любой процесс, связанный с такой долей ошибок, можно значительно улучшить (подробнее эти статистические данные рассматриваются в главе 27).
Некоторые авторы указывают, что, хотя ошибки конструирования и составляют высокий процент от общего числа ошибок, их обычно дешевле исправлять, чем ошибки в требованиях или архитектуре, поэтому они менее важны. Утверждение, что ошибки конструирования дешевле исправлять, верно, но вводит в заблуждение, потому что стоимость неисправленной ошибки конструирования может быть крайней высокой. Ученые обнаружили, что одними из самых дорогих ошибок в истории, приведшими к убыткам в сотни миллионов долларов, были мелкие ошибки кодирования (Weinberg, 1983; SEN, 1990). Невысокая стоимость исправления ошибок не подразумевает, что их исправление можно считать низкоприоритетной задачей.
Отсутствие похожих книг
Когда я начал подумывать об этой книге, я был уверен, что кто-то другой уже написал об эффективных методиках конструирования. Необходимость такой книги казалась очевидной. Но я обнаружил лишь несколько книг о конструировании, описывающих лишь некоторые его аспекты. Одни были написаны 15 или более лет назад и были основаны на относительно редких языках, таких как ALGOL, PL/I, Ratfor и Smalltalk. Другие были написаны профессорами, не работавшими над реальным кодом. Профессора писали о методиках, работающих в студенческих проектах, но часто не имели представления о том, как эти методики проявят себя в полномасштабных средах разработки. В третьих книгах авторы рекламировали новейшие методологии, игнорируя многие зрелые методики, эффективность которых прошла проверку временем.
Короче говоря, я не смог найти ни одной книги, автор которой хотя бы попытался отразить в ней практические приемы программирования, возникшие благодаря накоплению профессионального опыта, отраслевым исследованиям и академическим изысканиям. Обсуждение конструирования нужно было привести в соответствие современным языкам программирования, объектно-ориентированному программированию и ведущим методикам разработки. Ясно, что книгу о программировании должен был написать человек, знакомый с последними достижениями в области теории и в то же время создавший достаточно реального кода, чтобы хорошо представлять состояние практической сферы. Я писал эту книгу как всестороннее обсуждение конструирования кода, имеющее целью передачу знаний от одного программиста другому.
Я буду рад получить от вас вопросы по темам, обсуждаемым в этой книге, сообщения об обнаруженных ошибках, комментарии и предложения. для связи со мной используйте адрес stevemcc@coпstrux.com или мой Web-сайт http://www.stevemcconnell.com
Комментарии
Прочтите Совершенный код и вы перестанете так вздрагивать при слове «грабли» 🙂
Что очень хорошо, так это структура книги. Всё прекрасно рассортировано, даны перекрестные ссылки и ссылки на сайты, список литературы, отличное подробное оглавление. Это позволяет действительно использовать книгу как настольную, как источник тем для размышлений над своим кодом, как руководство к улучшению кода. Я бы советовал читать эту книгу следующим образом:
Стив Макконнелл
В прошлый раз мы познакомились с выдающимся человеком Пол Грэмом, который написал одни из лучших статей о стартапах, программировании и бизнесе. Сегодня я хочу рассказать вам о такой выдающейся личности, как Стив Макконнелл.
Интересно, что в далеком 1998 году читатели журнала «Software Development» признали Стива одним из трех наиболее влиятельных людей в отрасли разработки ПО наряду с Биллом Гейтсом и Линусом Торвальдсом.
Если говорить коротко, то Steven C. McConnell — программист и автор книг по разработке ПО.
Он написал книги «Rapid Development» (1996), «Software Project Survival Guide» (1998), «Professional Software Development» (2004). Журнал «Software Development», кстати, дважды удостоил его книги премии Jolt Excellence как лучшие книги года о разработке ПО.
Кстати, вы наверняка слышали фразу «Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете». Так вот, эту фразу приписывают именно Стиву.
Совершенный код
Книга Стива Макконнелла, которую вам крайне желательно прочитать хотя бы раз в своей жизни. Чрезвычайно полезный для реальной практики материал, которая пропагандирует исключительно грамотные принципы при разработке ПО.
Вот описание данной книги, взятое с интернет-магазина OZON:
Более 10 лет первое издание этой книги считалось одним из лучших практических руководств по программированию. Сейчас эта книга полностью обновлена с учетом современных тенденций и технологий и дополнена сотнями новых примеров, иллюстрирующих искусство и науку программирования.
Опираясь на академические исследования, с одной стороны, и практический опыт коммерческих разработок ПО — с другой, автор синтезировал из самых эффективных методик и наиболее эффективных принципов ясное прагматичное руководство.
Каков бы ни был ваш профессиональный уровень, с какими бы средствами разработками вы ни работали, какова бы ни была сложность вашего проекта, в этой книге вы найдете нужную информацию, она заставит вас размышлять и поможет создать совершенный код.
Профессиональная разработка программного обеспечения
Данную книгу я уже рекомендовать к обязательному чтению не буду. По большей части она представляет из себя мемуары и много размышлений автора. (говорят, похожа на «Дизайн и эволюция С++» Страуструпа)
Интересная и легкочитаемая книга, если вы со страстью изучаете все вопросы, касающиеся разработки ПО. В противном случае, лучше уделить больше времени более практичным материалам.
Для удобства также привожу описание книги:
Стив Макконнелл, автор бестселлера «Совершенный код», других книг и многочисленных статей о разработке ПО, убедительно показывает, что разработка ПО может быть стабильно успешной, если сделать совершеннее саму профессию разработчика ПО.
Он не только показывает, почему и как отрасль пришла к своему современному состоянию, и описывает шаги, которые должен предпринять каждый, кто хочет подняться на новый уровень в создании ПО.
Он также говорит о корпоративных методиках, призванных увеличить количество профессионально выполненных проектов, и о лицензировании организаций и академических учебных программ как о средстве повышения профессионализма и отдельных разработчиков, и в индустрии ПО в целом.
10 смертных грехов в оценке трудоёмкости разработки ПО
На ХабраХабре относительно недавно появилась отличная статья, о которой я просто не могу не упомянуть. А именно короткий и ясный пересказ (и перевод) часового вебинара от Стива Макконелла, который проходил в июне 2009 года.
Настоятельно рекомендую к ознакомлению. Очень верно подметил один из комментаторов этой статьи:
Большинство (или даже все) из приведенных «смертных грехов» так или инчае понимает любой адекватный разработчик, но иметь такой вот список очень полезно — можно лишний раз просмотреть его перед началом нового проекта и уберечь себя от ненужных ошибок. В избранное!
P.S. Так получилось (я уже писал об этом в твиттере), что за свою жизнь я столкнулся с двумя Макконеллами: Стивом и Кэмпбеллом. Не путайте их. Это два совершенно разных профессионала. Один — в экономике, другой — в разработке ПО.
Стив Макконелл вообще крайне интересный человек. Посмотрите, к примеру, какой он сделал у себя домашний кинотеатр. Перечень всех его книг можно найти там же. Вообще рекомендую изучить его личный сайт.
Я уже упоминал потрясающую книгу Вы, конечно, шутите, мистер Фейнман! в одной из прошлых своих статей.
Так вот: оказывается, существует еще и продолжение этой замечательной книги: Какое тебе дело до того, что думают другие! Если у Вас есть свободное время и вы любите читать истории других людей (очень близкие нам, программистам) — однозначно рекомендую!