Примечание. Все номера страниц ниже предназначены для версии книги Kindle.
Эта книга была абсолютно болезненный на старте. 20 -летие издания (1995) не обновляло ни одного из ссылок (очевидно), потому что это ретроспектива о том, что автор узнал при разработке крупного программного проекта. К сожалению для тех из нас, кто живет в 21 -м веке, этот программный проект был разработкой IBM’s ОС/360 . Приготовьтесь к захватывающим обсуждениям микрофиши, «огнями карты» в автомобилях и многое другое. «Структурированное программирование» представлено как «еще один важный набор новых идей» (146). Я делал заметки во время чтения этой книги, и в какой -то момент я написал:
в основном нечитаемо из -за плохого старения
Вот несколько цитат, чтобы проиллюстрировать мою точку зрения.
«Если нужна отдельная машина, это довольно своеобразно-это не должно быть быстро, но ей нужно по крайней мере миллион байт основного хранения, сто миллионов байтов онлайн-диска и терминалов. Нужны только буквенно -цифровые терминалы, но они должны идти намного быстрее, чем 15 символов в секунду, которые характеризуют машинщики ». (132)
«Какой язык высокого уровня следует использовать для системного программирования? Единственный разумный кандидат сегодня — Pl/i . « (138)
«Я убежден, что интерактивные системы никогда не будут вытеснять пакетные системы для многих приложений». (139)
Одним из особенно вопиющих примеров является то, где автор рекомендует добавлять комментарии к исходному коду программы, но не слишком много, потому что он может значительно увеличить размер программы на диске (177). (Что я думаю, технически верно, но больше не является проблемой на современных компьютерах.) Автор также рекомендует использовать стрелки вместо слов для иллюстрации потока программы:
Я вряд ли могу представить себе один совет, который сделает программу менее читаемой и более загроможденной. Так что не все в этой книге хорошо выдержано.
… При этом, как только вы пережили первые несколько глав, в книге действительно есть несколько хороших советов. Я выложу самые полезные темы, которые я нашел здесь.
Создание понятного кода сложно, но необходимо
«Основной принцип обработки данных учит глупости пытаться поддерживать независимые файлы в синхронизме» (171). Автор рекомендует не разделять документацию и код, вместо этого продвигать идею о том, что сам файл исходного кода должен содержать прозу объяснения этого кода. То, что он называет «программами самоокументирования», мы сегодня называем «хорошо настроенным кодом». Убедитесь, что вы объясните любой код, который не является самоэкспланирующей.
«В качестве основной цели мы должны попытаться свести к минимуму бремя документации, Бердер ни мы, ни наши предшественники не смогли успешно перенести». (172)
С этой целью автор рекомендует, чтобы мы «использовали части программы, которые все равно должны быть там»: используйте пробелы и скобки, чтобы форматировать код, прояснить объем и так далее. Дайте ваши переменные, методы и классы разумные, самоэкспланирующие названия. «Покажите, не говори» делает чтение — и пишет — гораздо менее болезненный процесс.
Не изобретайте колесо. «См. Стандартную литературу, чтобы документировать основные алгоритмы, когда это возможно» (176), а не «катание на своем». Если вам нужно извлечь один алгоритм из большого пакета, чтобы избежать импорта всего пакета, сделайте это. Просто обратитесь к исходному источнику, чтобы вы могли найти его позже, если это необходимо.
Не бойтесь быть слишком многословным. Если немного кода неясно, напишите однострочный комментарий. Если раздел или алгоритм нуждаются в объяснении, напишите абзац: «Используйте линейные комментарии или замечайте что -нибудь, что не очевидно» (176). Гораздо лучше быть слишком явным, чем быть слишком расплывчатым. Ваше будущее, возвращение к этим комментариям, будет благодарным.
Программирование — это интеллектуальная проблема
Одним из центральных тезисов этой книги является то, что после того, как все случайные проблемы программирования были преодолены или абстрагированы с автоматической памятью и управлением файлами, выразительными языками высокого уровня, широко доступными алгоритмами и структурами данных, и т. Д. Какие проблемы остаются для программиста? Осталось просто выражать проблему, которая должна быть решена таким образом, что ее можно интерпретировать машиной. Другими словами:
«Представление — это суть программирования». (110)
В 2019 году наиболее сложной частью программирования не является синтаксис обучения, управляющие ресурсы или что-либо, на самом деле низкоуровневое. Он способен полностью и однозначно выражать проблему, которую вы хотите решить, так что машина может помочь вам прийти к решению. Конечно, коллекции и классы и лямбдас могут Помощь Вы выражаете проблему, возможно, менее подверженным ошибкам или более полным образом, но они не сделает вашу работу за вас . Это только инструменты. Как и программист, это все еще зависит от вас, чтобы использовать эти инструменты для создания.
«Мы можем написать хорошие или плохие программы с любым инструментом. Если мы не научим людей проектировать, языки имеют очень мало значения ». (221)
Программное обеспечение (разработка) является сложным
У меня был учитель в старшей школе, который всегда говорил: «Повторение — это ваш друг». Она имела в виду, что люди должны видеть концепции и идеи, повторяющиеся, иногда по -разному, чтобы полностью понять и поглощать их. Машины не нужны. Если вы пишете функцию или определение класса один раз, вам не нужно писать ее снова.
«Программные предприятия более сложны для их размера, чем, возможно, любая другая человеческая конструкция, потому что нет двух одинаковых частей (по крайней мере выше уровня заявления). Если они есть, мы превращаем две похожие части в одну, подпрограмму … « (183)
Сухой (не повторяйся) Мантра, поддерживаемая многими разработчиками программного обеспечения, способствует идее, что регулярно используемые куски кода следует инкапсулировать в методах, которые легко называются, отлаживаются и документируются, а не копирование и вставка этих строк снова и снова на протяжении всего вашего кода. Код, организованный таким образом, никогда не будет повторять ничего большего, чем утверждение, или одну строку. Теория информации гласит, что этот вид кода максимально энтропий. Повторяя как можно меньше кода, мы максимизируем «плотность информации» этого кода.
Это означает, что «хороший» код, по определению, Настолько сложный, насколько это может быть Анкет Я использую слово «комплекс» здесь не означает «путаницу» или «запутанный», или означаю, что код имеет сложный для понимания синтаксис. Я имею в виду, что ни один кусок кода не повторяется, все уникально, все несет новую и другую информацию, которую представляли ранее. Создание хорошего программного обеспечения обязательно означает создание сложного программного обеспечения:
«… масштабирование программного предприятия-это не просто повторение одних и тех же элементов в большем размере; это обязательно увеличение количества различных элементов. В большинстве случаев элементы взаимодействуют друг с другом каким -то нелинейным способом, и сложность целого увеличивается гораздо больше, чем линейно ». (184)
Таким образом, достижение значительного повышения эффективности программиста является вопросом для облегчения выражения сложных отношений и объектов в меньшем количестве строк кода (272). Не лучше или быстрее редакторы, а не новый синтаксис, фреймворки или языки сам по себе , но способность выражать концепции более высокого уровня в этих структурах и языках более легким, менее подверженным ошибкам. Это это то, что повысит эффективность программиста в будущем.
Поддержание концептуальной целостности
Проекты программного обеспечения, такие как команды людей, увеличивают супралинеарно в сложности, поскольку они увеличиваются в размере. Удваивание размера программы увеличивается на фактор, намного больше, чем 2, количество способов, которыми этот API может использоваться, злоупотреблять и подключаться к другим пакетам. Точно так же команда из 4 человек имеет 9 возможных каналов коммуникации среди своих членов (уникальные подразделения 2 или более человек). Команда из 8 имеет 49. Команда из 16, 225. Сложность увеличивается квадратично.
Когда проект построен одним человеком, поддержание концептуальной целостности относительно просто. Только один человек должен убедиться, что код отформатирован равномерно, в документации используется тот же словес, что пользовательский интерфейс является согласованным и т. Д. Когда команда проекта такая же мала, как два человека, общение необходимо для поддержания этой последовательности по всему проекту. Таким образом, общение между командами необходимо для поддержания концептуальной целостности.
В начале книги автор рекомендует радикальный переосмысление команды разработчиков, для проектов только с горсткой людей- Команда хирурга Анкет В этой структуре проекта только один человек отвечает за концептуальное видение проекта. Этот человек, «хирург», выполняет структурные и дизайнерские работы, в то время как другой квалифицированный программист помогает, создавая вторичные биты кода: подпрограммы более низкого уровня, бэкэнд-структуры управления данными и так далее. Хирург свободно сосредоточиться на своем «видении» для проекта, в то время как другие поддерживают и помогают хирургу.
Конечно, это не сработает для большинства команд (несмотря на рекомендацию автора), особенно крупные, где один «провидца» не сможет справиться со всей необходимой от них работой. Таким образом, насколько это возможно, проектные решения должны быть задокументированы и объяснены, чтобы все участвующие в проекте могли ссылаться на них. Как я уже говорил ранее, всегда лучше быть слишком явным, чем слишком расплывчатым.
«Подготовка каждого документа этого небольшого набора фокусируется на размышлении и кристаллизует обсуждение. Закон письма требует сотни мини-определений, и именно существование их отличило четкую, точную политику от нечетких ». (240)
Но это не обязательно для все знать Все о проекте. На самом деле, это предпочтительнее, если Закон Деметера (или «Принцип наименьшего знания») следуют как можно ближе:
«… Цель всех, кто видит все, — это совершенно неверно; « (236)
Другими словами, вам не нужно знать Как Подпрограмма работает, просто это делает. Вы должны сосредоточиться на входах и выходе из функции, а не на том, что он делает внутри. Это увеличивает повторное использование и модульность кода.
Расти, Не строить
Хотя традиционный метод разработки программного обеспечения «водопад» предполагается на протяжении всей книги, автор признает это в 20 -летии издания и более или менее извиняется за нее (265). Временами изменения и разработка программного обеспечения развивались, вероятно, более радикально, чем любая другая отрасль в истории цивилизации, все менее чем за 80 лет.
Благодаря задним числу, автор теперь рекомендует более гибкую структуру: создать сквозную систему, которая выполняет ничего Во -первых, это делает только правильные подпрограммы в правильном порядке. Затем создайте подпрограммы по одному, тестируйте, промойте, повторите. Таким образом, вы будете Всегда Иметь рабочую систему (хотя и с ограниченной функциональностью), которая может постоянно тестироваться пользователями (202).
«Эффекты морального духа поразительны. Энтузиазм прыгает, когда есть работающая система, даже простая ». (202)
В дополнение к «растущему» программному обеспечению, мы также должны выращивать отличных разработчиков программного обеспечения. Немногие компании в настоящее время имеют привычку прилагать усилия, чтобы начать с совершенно новых разработчиков и превращать их в великих, опытных. Мифический человек-месяц предлагает несколько советов для этого процесса:
«Систематически идентифицируйте лучших дизайнеров как можно раньше. Лучшие часто не самые опытные. Назначьте наставника карьеры, чтобы нести ответственность за развитие перспективы и сохранить тщательный файл карьеры. Разработать и поддерживать план развития карьеры … в том числе тщательно отобранное ученичество с ведущими дизайнерами, эпизоды передового формального образования и короткие курсы, все они перемежаются с сольным дизайном и техническими заданиями руководства ». (204)
Как менеджер, это не столько ваш долг перед Разработать Лучший талант, поскольку это ваш долг на Позвольте ему разрабатывать самостоятельно (276). Обеспечить пространство, облегчить командную еду и встречи, позаботьтесь обо всех мирских аспектах работы, чтобы ваши звездные разработчики могли продолжить работу по развитию. Но самое главное, избегайте микроуправления. Позвольте сотрудникам взять под контроль свои собственные проекты, установить свои сроки и максимально управлять своим собственным временем и ресурсами — Вы будете удивлены результатами:
«Я не могу подчеркнуть важность расширения прав и возможностей». (279)
Резюме
Сначала я был чрезвычайно скептичен, но после первых 20% или около того остальная часть этой книги была полна отличных советов. Я не рекомендую его для разработчиков ранней карьеры, так как, похоже, это предназначено главным образом для лидеров команд. Советы по управлению командами людей, поддержание проектов развития в этих командах и предоставление сотрудникам выполнять их на пике, можно найти почти на каждой странице этой книги. Но, возможно, пропустите первые несколько глав.
Оригинал: «https://dev.to/awwsmm/book-review-the-mythical-man-month-1995-1hpn»