Школа программирования ProgTips Книга Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы» — это книга обязательная к прочтению для каждого программиста. Она вышла еще в 1975 году, но совершенно не утратила своей актуальности.
Мне эта книга повстречалась очень вовремя. Я только что закончил ВУЗ и начал работать программистом. Вначале было очень трудно. Книг по IT тогда было мало. Эту книгу я читал в библиотеке, она была изрядно потрепана. И я поразился, сколько ценного она содержит. Советы Брукса очень помогли мне в начале карьеры. А особенно эта книга пригодилась, когда я сам стал руководить программистами.
Фредерикс Брукс работал в IBM и руководил созданием операционной системы System/360. На тот момент — это был самый крупный программный проект в мире. В процессе работы возникли неожиданные сложности. Брукс был наблюдательным человеком и сумел понять природу этих сложностей. Он сумел сформулировать основные принципы разработки ПО, которые отличают программирование от других отраслей производства.
Что же это за принципы?
Закон Брукса
Главный вывод, который он назвал законом Брукса гласит:
Если программистский проект не укладывается в сроки, то добавление рабочей силы только задержит его окончание.
Этот закон обычно иллюстрируют так: «Даже если собрать девять женщин, то они не смогут родить ребенка за месяц».
Отсюда и название книги. В других отраслях увеличение числа работников позволяет ускорить работу. Десять землекопов работают быстрее, чем пять. А вот десять программистов, как это ни странно, буду работать медленнее, чем пять.
Метод Вирта
Согласно Бруксу лучший метод разработки ПО — это метод Никлауса Вирта, автора языка Паскаль.
По Вирту проектирование рассматривается как последовательность шагов, уточняющих проект. Сначала грубо набрасывается постановка задачи и предлагается грубый метод ее решения, позволяющий получить принципиальный ответ. Далее описание составляется более детально, что позволяет увидеть, что результат отличается от желаемого. Большие этапы решения разбиваются на более мелкие.
Именно этот метод разработки программ я взял на вооружение и долгие годы он помогает мне писать программы более эффективно.
У этого метода есть еще одна полезная особенность. Можно быстро набросать макет работающей программы и разговаривать с заказчиком уже предметно. Потому что заказчики программы совершенно не представляют, что именно получится в конце. Минимальный пакет решает эту задачу.
ООП — это болезнь
В этой книге я впервые прочитал критическое мнение о модной в те времена объектно-ориентированной технологии разработки программ.
По моему мнению, у объектно-ориентированных методологий особенно тяжелый случай болезни, характерной для многих усовершенствований в методологии. Весьма существенны предварительные издержки — в основном, чтобы научить программистов мыслить совершенно по новому, а также на преобразование функций в обобщенные классы.
Назвать ООП тяжелой болезнью — это было тогда очень смело, но позже я неоднократно убедился в верности этого диагноза. Потому что издержки программирования в стиле ООП многократно превышают незначительные преимущества.
Исправления портят программу
Когда программист выпустил релиз программы, то благодарные пользователи сразу начинают просить новые функции. Казалось бы, это хорошо. Но не все так просто. У людей самые разные взгляды на то, как должна развиваться программа. Поэтому есть все шансы, что программа быстро превратится в неповоротливого монстра, напичканного ошибками.
Леман и Белади изучили историю последовательных выпусков большой операционной системы. Они считают, что общее количество модулей растет линейно с номером версии, но число модулей, затронутых изменениями, растет экспоненциально в зависимости от номера версии. Все исправления имеют тенденцию к разрушению структуры, увеличению энтропии и дезорганизации системы. Все меньше сил тратится на исправление ошибок исходного проекта и все больше — на ликвидацию последствий предыдущих исправлений.
Гораздо лучше четко сформулировать требования к программе и реализовать их. Чтобы программа делала что-то одно, но делала это хорошо.
Я далек от того, чтобы считать, будто все изменения целей и требований клиента можно или необходимо учитывать в проекте. Очевидно, должен быть установленный порог, который должен подниматься все выше и выше по ходу разработки, иначе ни один продукт никогда не будет создан.
Производительность программистов различается в разы
Первый раз о том, что программисты имеют существенно разную производительность, я узнал из книги Брукса. Тогда я не поверил. Но жизнь полностью подтвердила это положение.
В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов.
Особенно это было видно на примере студентов. Когда я стал преподавать программирование в ВУЗе, то видел на контрольных работах, что одни студенты читают задачу и быстро пишут готовый код, а другие могут целую пару копаться в отладке в простой программы.
Серебряной пули нет
Самый интересный прогноз Брукса о том, что в ближайшее время не будет технологий, способных на порядок увеличить скорость разработки. Прошло уже очень много лет, а прогноз Брукса полностью сбылся. Как и сорок лет назад программисты пишут программы вручную. Нет технологии, в которую засунешь ТЗ заказчика, а она выплюнет готовый код.
Конечно же, все идеи Брукса не перескажешь. Рекомендую к прочтению, чтобы не наступать на многие грабли.
Сегодня увидел в Продалите книгу:
Лакман Макдауэлл. Карьера программиста. 6-е издание. Бестселлер Амазон. в ней 189 тестов из собеседований в крупнейших Ай-ти компаниях (при приёме на работу). Питер, 2016г, > 1000 стр. Цена в Ангарске 1338 руб на 10.12.2018. Мощно, но не по карману и времени. Хотя интересно было бы сравнить свою карьеру времён СССР с его.
Я одногодок с Биллом Гейтсом (создателем уродской ОС Виндоус) и ушедшим в мир иной создателем фирмы Эппл. Оба правда программистами настоящими не были, но были гениями маркетинга, прозорливцами. Ушёл на днях из жизни друг одногодок, вот и решил чуть поделиться воспоминаниями. Начинал с перфокарт и ЭВМ М220, БЭСМ-6 (шедевр мировой на то время русского гения Лебедева. Ушёл из жизни раньше времени, как и другой гений — Келдыш. Помогли власти. Последствия объявления кибернетики лженаукой, а генетики продажной девкой империализма. Лебедев предлагал АСУ всей экономикой на базе сети ЭВМ. Такое чиновниками, а особо КПСС, не прощается и до сих пор, ибо это потеря власти и взяток. Вот его и затравили. Якобы самоубийство Келдыша тайна из великих). К нам в Новосибирский научный центр в 1975 г. приезжал учиться опытный программист из США (я был ещё студиком) . Работал в известной тогда компании. Зарплата его была 2000 $ в месяц. 50% уходило на налоги, ещё 500 баксов на ипотеку за дом с участком земли на 20 лет. В доме кроме комнат 2 ванны и 2 туалета. Женат, 2 детей. На жизнь оставалось 500 в месяц (о доходах жены и стоимости дома не сказал) и хватало в обрез, но цена денег не чета нынешним. В те времена авианосец стоил 1 млрд, а сейчас на эти деньги только 2 истребителя Ф-35.
А теперь главное — программирование это не более 20% реал-проектов за к-е платят серьёзные деньги и их делают коллективы годами, а потом ещё сопровождают пока не утонут в изменениях и переходе на новую технику. Довелось видеть закрытый программно-технический комплекс с огромным замком, к-й и был закрыт по такой причине, ведь программисты увольнялись и умирали и в те времена. Стоил он громадных денег. А сколько таких было. Вот и не выдержал СССР. А ещё потому, что гоняли на сельхозработы с весны до осени без уменьшения плана. Эпоха была жутчайшая, а обстановка мерзопакостная. И сейчас
не лучше, но в колхоз не гоняют и в магазинах что-то есть. Да и днём занимались разработками, а только ночью на ВЦ давали время 1 час возится с прогой. Сейчас компьютерный рай и ад одновременно. 11.12.2018 5ч.19м.
После окончания учебы в Киевском политехническом институте в 1975 году работал программистом и продолжаю заниматься разработкой ПО до сих пор. В 2016 году получил патент США на разработку системы диагностики заводского оборудования. Приходилось и учиться и обучать. Сейчас, например, начал немного практиковать обучением детей робототехнике.
В свое время был в восторге от книги Брукса, обсуждаемой здесь. Много идей, сформулированных в ней, актуальны по сей день. Даже более того, они истинны и вечны, по моему убеждению. Однако не все.
Быстро развивались языки программирования (описательные возможности), операционные системы (среды, в которых функционируют программы), в миллионы раз увеличились мощности компьютеров… Подходы к программированию поменялись радикально.
Если раньше программы реализовывали алгоритмы, для описания которых было достаточно возможностей блок-схем, то теперь нужен… ну, хотя бы, UML.
Теперь прогрммы — это модели какой-либо (строго ограниченной) части материального мира. Модели многопоточные, в которых, как и в реальном мире, одновременно «живет» множество различных объектов, взаимодействующих друг с другом, реагирующих на события и оповещающих других «актеров» о генерируемых ими событиях.
А слышали что-либо про нейронные системы? (Я пока не пробовал).
А потому, критика ООП выглядит сейчас не просто глупо. Это вообще невозможно объяснить. Это какой-то абсурд. Заблуждение Брукса можно понять и простить. Это было 50 лет назад. Да и книга его больше не о сути программирования, а об организации процесса программирования. Поражен, что люди, взявшиеся за обучение программированию, имеют на столько примитивное понимание темы. а
Или это провокация?
Вы пересказываете рекламные лозунги про ООП. Реальная практика программирования совсем другая. Как раньше, так и сейчас все крупные программные комплексы: операционные системы, базы данных, графические библиотеки пишутся на чистом Си.