Делу время, потехе час! Тезисы «мифического человеко-месяца» Фредерика Брукса, в пословицах и поговорках

dd9d5b23d42d76be9c82862b25ccbea9.jpg

Время — судья


Книга «мифический человеко-месяц», заслуживает того, чтобы её читали и перечитывали, издавали и переиздавали. В 2025 году, а он не за горами, будет 50 лет первому изданию. Т.е. проверка временем пройдена. В 1995 году вышло юбилейное издание (ждём юбилейного издания 2К25), в предисловии к которому, автор, помимо прочего, сообщает:
Работая над обзором и обновлением книги «Мифический человеко-месяц», я поразился, как мало тезисы, заявленные в ней, были подвергнуты критике, доказаны или опровергнуты текущими исследованиями и опытом в инженерии ПО. Теперь для меня оказалось полезным каталогизировать эти тезисы в сырой форме, лишённой подтверждающих аргументов и данных. В надежде, что эти голые утверждения привлекут аргументы и факты для доказательства, опровержения, обновления или уточнения, я включил этот план в главу 18.

Кто празднику рад, тот накануне пьян


И я подумал, а почему бы и мне не составить свой список тезисов этой книги, в рамках подготовки к пятидесятилетнему юбилею. Но в форме не просто набора тезисов, а в форме пословиц, поговорок и т.д.

В споре рождается истина


А цель всё та же что у Брукса, ещё раз обратить внимание, и привлечь новые аргументы, доказательства, опровержения или уточнения.

А заодно расслабиться, и повеселиться. Не воспринимайте написанное слишком буквально — без смешного нельзя понять серьёзное.

Порядок дела не портит


В подзаголовках публикации повторяется последовательность глав книги, в каждой главе список поговорок-тезисов, подкреплённых цитатами. Для экономии места, оставляю за собой право немного перефразировать оригинал и использовать склейки. К главам я буду приводить аннотации, и иногда пояснять свои мысли по поводу некоторых пословиц.

❖ — Оглавление:

Вступление

«Хватит долго запрягать…» — основная часть


«Пора и честь знать» — заключение

Чем богаты, тем и рады


На всеобъемлющий охват, изложенных Бруксом мыслей, не претендую: из текста будут вырваны куски и проиллюстрированы какой-то пословицей, возможно что-то важное будет незаслуженно упущено. В общем, каждой сестре по серьге не обещаю.

Толкования поговорок и псевдо- «настоящих продолжений»/«полных версий», здесь не будет — упаси боже.

Хватит долго запрягать, — поехали


Предисловие научного редактора к русскому изданию 2020 года


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

Была сформирована группа из 25 человек, которая занялась разработкой плана.

Весь аппаратно-программный комплекс назвали System/360, а операционную систему — OS/360. Иронично, что проблемы обратной совместимости были решены за счёт отказа от совместимости с предыдущими системами.


▍Глава 1. Смоляные ямы


В главе описывается количество усилий, необходимых чтобы превратить программу в конечный продукт. И то, что сам процесс программирования обладает некоторым дуализмом, так как приносит и некоторые радости, и некоторые горести. Последние, в свою очередь, могут стать той самой смоляной ямой, которая стоит на пути превращения программы в «продукт системы программирования».
Век живи — век учись
Почему программирование приносит радость? Какие удовольствия в качестве награды ждут его практика? Это радость от постоянного усвоения нового — этого предостаточно в неповторяющейся работе. Так или иначе, проблема всегда нова, и решающий её чему-то учится: иногда практическому, иногда теоретическому, а иногда и тому и другому.
Необходимость постоянно изучать новое, Брукс считает особой радостью программирования. Возможно с годами, оно будет уже не в радость, а в тягость, но сейчас я с ним соглашусь, ведь ученье — свет.

Не Боги горшки обжигают
Человек должен действовать безупречно. Компьютер похож на магию и в этом отношении тоже. Если один символ, одна пауза заклинания не находится строго в правильной форме, то волшебство не сработает. Необходимость приспосабливаться к требованиям совершенства — это, я думаю, самая трудная часть овладения программированием.
Выбор пословицы должен приободрить читателя, ведь какими бы ни были трудности — человек с ними справится.

Плясать под чужую дудку
Конечные целевые критерии устанавливают другие люди, они предоставляют ресурсы и обеспечивают информацией. Редко кто-то контролирует условия своей работы или даже её цель. С точки зрения менеджмента, мы зависим от многих.

Зависимость от других имеет особенно неприятную системному программисту сторону.



Мал клоп, да вонюч
Заниматься дизайном великих концепций — это удовольствие; отыскивать мелкие ошибки — это просто работа на поиск последних ошибок приходится тратить больше времени, чем на поиск первых.


Ничто не вечно под луной
Продукт, над которым так долго трудились, устареет ещё до его завершения. Коллеги и конкуренты уже вовсю гоняются за новыми и более совершенными идеями. И уничтожение плода вашей мысли уже не только задумано, но и запланировано.

▍Глава 2. Мифический человеко-месяц


Глава которая дала название книге. Основная идея не нуждается в какой-то иллюстрации, так как сама по себе является пословицей: «девять женщин за месяц не родят», в книге она звучит так:
Вынашивание ребёнка занимает девять месяцев, независимо от того, сколько женщин поставлено выполнять задачу.

Волков бояться — в лес не ходить
Все программисты — оптимисты. Возможно, это современное колдовство в особенности привлекает тех, кто верит в счастливый конец и сказочных волшебниц. Возможно, сотни мелких разочарований отпугивают всех, кроме зацикленных по привычке на конечной цели.
Последнее предложение можно воспринимать как назидание тем кто хочет войти в IT. За себя могу сказать, что действительно люблю сказки, и волшебниц.

Поезжай на неделю, а хлеба бери на две
Наши методики оценивания развиты слабо. По сути, они отражают молчаливое допущение, что всё пойдёт как надо то есть каждая часть работы будет продолжаться столько, сколько она «должна» длиться.

Однако большие проекты в разработке состоят из многих задач, и вероятность того, что всё пойдёт хорошо, становится ничтожно малой.



И на старуху бывает проруха
Во многих творческих видах деятельности среда исполнения является неподатливой. Древесина раскалывается, краски размазываются, электрические цепи закольцовываются.

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

Хотел написать что не ошибается тот, кто ничего не делает. Но это было бы похоже на попытку оправдаться. Брукс же не ставит это нам в укор, поэтому оправдания и не нужны. А нужно просто помнить, что людям свойственны ошибки и планировать работу учитывая риски, конь, вот, о четырёх ногах, а тоже спотыкается.

Меряла бабка клюкой, да махнула рукой
Наши методики оценивания ошибочно путают усилия с прогрессом, допуская, что люди и месяцы взаимозаменяемы. Стоимость действительно варьируется в зависимости от числа людей и числа месяцев. Ход выполнения — нет.

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



Нашла коса на камень
Многие проекты укладывались в график на всех этапах, исключая тестирование.

Поскольку сбой происходит в конце графика, никто не подозревает о проблемах вплоть до даты поставки. Более того, задержка в этом месте имеет необычайно серьёзные финансовые и психологические последствия. Поэтому в исходном графике работ очень важно предусмотреть достаточное время на тестирование системы.

Следует сделать оговорку что речь про «каскад», т.е. тестирование идёт в конце или ближе к нему. Однако каким бы модным и молодёжным agile вы не пользовались, постарайтесь хотя бы о «камень» не спотыкаться. Уделять время на тестирование в достаточном количестве следует независимо от выбранной методологии.

На хотенье — есть терпенье
Поскольку мы не уверены в наших оценках, менеджерам часто не хватает вежливого упрямства.

Для программиста, как и для шеф-повара, нетерпеливость со стороны заказчика может привести к изменению запланированного срока завершения задачи. Впрочем, повар может предложить ещё вариант — добавить огня. В результате часто омлет уже ничем не спасёшь: подгорит с одной стороны и будет сырым с другой.

Оно же «поспешишь — людей насмешишь» и «наскоро делать — переделывать», но вариант со словом «терпенье» к проблеме нетерпеливости подходит лучше.

Ещё мне нравится аналогия с шеф-поваром.


Хотели как лучше, а получилось как всегда
Когда выявляется отставание от графика, естественным (и традиционным) ответом становится добавление рабочей силы. Это всё равно что подлить масла в огонь: будет только хуже, гораздо хуже.

Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.

Максимальное число человек зависит от числа независимых задач.


▍Глава 3. Хирургическая бригада


Глава о том, как сформировать команду так, чтобы дело спорилось.

ИМХО, но надо брать пример с армейцев в этом вопросе. Аналогия с армейским отделением будет выглядеть менее притянутой за уши:

  • численность подобна
  • как нигде более, все должны чётко знать свои обязанности,
  • с учётом повышенного риска bus factor, ещё и уметь заменять друг друга

Но, «хирургическая бригада» — это всего лишь метафора, поэтому не стоит заострять на ней внимание.
Не спрашивай старого, спрашивай бывалого
В одном из исследований измеряли производительность труда в группе опытных программистов. Соотношение между лучшими и худшими результатами составляло в среднем около 10:1 по производительности и, 5:1 по скорости и требуемой памяти программы! Данные не показали абсолютно никакой корреляции между опытом и производительностью.


Двое пашут, а семеро руками машут
Миллс предлагает, чтобы каждый сегмент крупной работы решался командой, но при этом она должна быть организована как хирургическая бригада. То есть вместо того, чтобы каждый член группы орудовал скальпелем на задаче, один делает надрез, а другие оказывают ему всяческую поддержку, которая будет повышать его эффективность и продуктивность.

Десять человек, семь из них профессионалы, работают над задачей, но система является продуктом одного-единственного ума — или, самое большее, двух, действующих как единое целое.

Эта моя любимая, ибо не в бровь, а в глаз. Конечно Брукс вкладывает немного другой смысл, чем тот, что подразумевается в пословице, но численность совпала идеально, т.к. в «хирургической бригаде Миллса» подразумевается 9–10 человек, из них всю разработку ведут два человека (хирург и второй пилот), +7 на подхвате, +1 (языковой консультант) который может состоять в нескольких «бригадах», и в пословице 2+7… Совпадение? Не думаю!

Предпочёл её пословице «царь без слуг, как без рук», хотя искушение было велико. Но можете выбрать на свой вкус, на который, как известно, нет товарища.


И швец, и жнец, и на дуде игрец
ХИРУРГ. Миллс называет его главным программистом. Он лично задаёт спецификации по функциональности и производительности, разрабатывает дизайн программы, кодирует её, тестирует и пишет документацию. Он имеет большой талант, десятилетний опыт и значительные системные и прикладные знания, будь то прикладная математика, обработка бизнес-данных или что-то ещё.


Одна голова хорошо, а две лучше
ВТОРОЙ ПИЛОТ. Он является альтер эго хирурга, способен выполнить любую часть работы. Его главная задача — участвовать в проектировании, где он должен думать, обсуждать, оценивать. Он досконально знает весь код. Он исследует альтернативные стратегии дизайна. Очевидно, он служит для хирурга страховкой от катастрофы.


На одном гвозде всего не повесишь
Хирург является начальником, и за ним последнее слово в вопросах персонала, надбавок, пространства и т. д., но он не должен тратить почти всё своё время на эти вопросы.


Мастер один, а подносчиков десять
АДМИНИСТРАТОР. Управляет деньгами, людьми, пространством и машинами и взаимодействует с административным аппаратом остальной организации.

РЕДАКТОР. Хирург отвечает за генерирование документации. Редактор, берёт черновик или продиктованную рукопись, подготовленную хирургом, и подвергает её критическому анализу, перерабатывает, снабжает ссылками и библиографией, пропускает её через несколько версий и контролирует механику производства.

ДВА СЕКРЕТАРЯ. Администратору и редактору, каждому в отдельности, понадобится секретарь.

ДЕЛОПРОИЗВОДИТЕЛЬ. Он отвечает за регистрацию всех технических данных бригады в библиотеке программного продукта.

ИНСТРУМЕНТАЛЬЩИК. Ответственный за обеспечение доступа к основным службам, а также за создание, поддержку и обновление специальных инструментов.



Не нужен учёный, а нужен смышлёный
ЯЗЫКОВОЙ КОНСУЛЬТАНТ. Их талант несколько отличается от таланта хирурга, который в первую очередь является системным дизайнером и мыслит представлениями. Языковой консультант может находить безупречный и эффективный способ использовать язык для того, чтобы делать трудные, смутные или каверзные вещи. Часто ему приходится проводить небольшие исследования (в течение двух-трёх дней) по отысканию хорошего технического решения.


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

▍Глава 4. Аристократия, демократия и системный дизайн


Всяк портной на свой покрой
Несмотря на то что для сборки большинства систем программирования не требовались столетия, они демонстрируют гораздо худшую концептуальную разобщенность, чем соборы. Обычно это происходит не из-за смены проектировщиков, а из-за разделения проекта на многочисленные задачи, выполняемые многими людьми.


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

Отделение архитектурных усилий от имплементации является мощным способом получения концептуальной целостности в крупных проектах.

Если система должна обладать концептуальной целостностью, то руководство концепциями должен взять кто-то один.

Здесь пословица описывает обратную ситуацию, которая произойдёт если руководить концепциями будут разные люди, даже стремясь к одной цели, их действия не будут согласованными.

▍Глава 5. Эффект второй системы


Главу открывает цитата Овидия: добавляй малое к малому, и ты получишь большую кучу.

Речь идёт о наваленных функциях и украшательствах, которые сами по себе ничего, но вместе превращают систему в «кучу». Вся глава, в основном, состоит из примеров, примеров того как создавались кучи, ну что ж, на ошибках учатся.

Но найдётся в главе место и ещё пары народных мудростей, тех, в которых содержится рецепт спасения.

Ну, а проблема — это ретивые архитекторы которые хотят применить то, чему научились.

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

По мере работы над дизайном первой системы, ему на ум приходят украшение за украшением, фишка за фишкой. Они будут сохранены для использования «в следующий раз». Эта вторая система — самая опасная для человека, который её проектирует. Общая тенденция — делать дизайн второй системы с большим запасом, используя все идеи и излишества, которые были осторожно отклонены в первой.

Как менеджеру проекта избегать эффекта второй системы? Настаивать на том, чтобы старший архитектор имел опыт разработки хотя бы двух систем.

Это получился скорее совет менеджеру, чем описание сути проблемы.

И крута гора, да миновать нельзя
Как архитектор избегает эффекта второй системы? Совершенно очевидно, что он не может пропустить свою вторую систему. Но он может осознавать, какие особые опасности его подстерегают, и проявлять дополнительную самодисциплину.


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

▍Глава 6. Доведение до сведения


Глава о том что нужно писать, совещаться, переписывать, и перечитывать. Хотя речь о документации ради документации не идёт, поэтому найдётся место и для других тезисов.
У семи нянек дитя без глазу
Единство «Принципов работы» системы System/360 проистекает из того, что принадлежит перу только двух человек. Идеи принадлежат примерно 10 людям, но воплощение этих решений в текстовые спецификации должно быть проделано только одним человеком или двумя, если нужно сохранить единообразие и согласованность описания и продукта. Ибо написание определения потребует целого ряда мини-решений, которые не имеют дискуссионной важности.


Много говорено, да мало сказано
Излишне говорить, что совещания необходимы. Сотни личных встреч должны быть дополнены более крупными и официальными собраниями. Мы нашли полезными два уровня из них. Первый — это еженедельная полудневная конференция всех архитекторов и официальных представителей имплементаторов аппаратного и программного обеспечения, а также представителей бизнеса.

В результате накапливается ряд мелких апелляций, открытых вопросов или недовольств. Чтобы закрыть этот ряд проблем, мы проводили ежегодные «заседания верховного суда», длящиеся обычно две недели.

Здесь, в выборе поговорки, прослеживается моя личная неприязнь к совещаниям, у Брукса как раз всё наоборот, там он совещания боготворит. Может он и прав, а мне надо пересмотреть своё отношение, в любом случае осознание проблемы — половина пути к исправлению.

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

В конечном счёте заказчик является независимым аудитором. В безжалостном свете реального использования проявится каждый изъян. Группа тестирования продукта является суррогатным клиентом, специализирующимся на выявлении недостатков.

Отдел тестирования здесь это то самое малое опасение, которое спасёт от пользовательского гнева. Ну или хотя бы попытается.

Кто ищет — тот всегда найдёт
Раз за разом дотошный тестировщик продукта будет находить места, где информация не была передана, где решения по дизайну не были правильно поняты или точно имплементированы.

▍Глава 7. Почему провалился вавилонский проект?


Что-то ещё добавить — избыточно.
Левая рука не знает, что делает правая
Катастрофа с графиком, функциональная несогласованность и системные ошибки возникают потому, что левая рука не знает, что делает правая.
Да, здесь я просто скопировал текст, дословно повторив идиому. Ну, а что, тварь я дрожащая или право имею?!

Гора с горой не сходится, а человек с человеком сойдётся
Как же тогда команды должны обмениваться информацией друг с другом? Всеми возможными способами: неофициально, совещания, рабочая книга.


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

Все документы проекта должны быть частью этой структуры.

Технологический документ практически вечен.



Не место красит человека, а человек место
Древовидная структура организаций отражает меньшую потребность в детальной коммуникации. Фактически древовидная организация возникает как структура полномочий и ответственности.

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


▍Глава 8. Попытки измерить


Приводятся различные исследования на тему того, как оценить продуктивность программистов. Ну допустим! Продуктивность мы измерим, и будем знать сколько кода можно написать за день.

Не совсем понимаю какое у этого должно быть практическое применение. Для оценки времени на разработку?! Но мы ведь заранее не можем знать сколько инструкций написать придётся, а знал бы прикуп, жил бы в Сочи.

Даже примерно оценить сложно, ибо тихо море, пока на берегу стоишь. Всегда появляются подводные камни, которые нужно обойти, а некоторые и не обойти, не объехать. А когда код будет написан, оценка уже и не нужна, ведь дорога ложка к обеду.

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


Чем дальше в лес, тем больше дров
Данные, относимые к разработке изолированных малых программ, неприменимы к продуктам систем программирования. Линейно экстраполировать показатели забега в спринте бессмысленно. Объём работы растёт как степенная функция размера.


На острую косу много покосу
Продуктивность программирования может быть увеличена в 5 раз при использовании подходящего языка высокого уровня.

▍Глава 9. Непосильный груз


В каком-то смысле глава потеряла свою актуальность, ибо написана во времена когда доступ к исполняющей машине был строго лимитирован, выдавался по заявке, и требовал ожидания в очереди таких же страждущих. И после всех ожиданий разрешалось прийти и подсчитать что-то на ЭВМ в течении пары часов. Ну и прочие прелести той эпохи. В том числе объём памяти.

Непосильный груз здесь — это размер программы, ну или, по крайней мере, место которое она занимает при выполнении. Хотя мы уж давно не обращаем на её размер внимания, как будто память резиновая.

Хотя… появление виртуальных серверов, доступных для аренды, к некоторым смысле возвращает нас к описанной Бруксом проблеме: выбранный нами тариф ограничит нас как по объёму оперативной памяти, так и по объёму диска. Да килобайтики считать уже не надо, теперь достаточно уложиться в 5 Гб. Ну, а если не получилось в 5, тогда арендуй 10.

Проблема та же, масштаб и причина другие.

Цены тоже стали другими, разница между 5 и 10 Гб незначительна, особенно для крупного бизнеса. Но копейка рубль бережёт, поэтому к главе стоит, как минимум присмотреться.

Не постой за волосок — бороды не станет
Поскольку размер является для пользователя крупной частью стоимости продукта, разработчик должен устанавливать целевые показатели размера, контролировать размер и разрабатывать методику сокращения размера


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

Программист, находящийся в тупике из-за нехватки пространства, часто может добиться лучшего, выпутавшись из своего кода, отступив назад и переосмыслив свои данные


▍Глава 10. Документарная гипотеза


Документируй всё. Документируй как мы, документируй вместе с нами, документируй лучше нас!…
Бумага всё стерпит
Каковы критически важные документы? Целевые критерии, спецификации, график работ, бюджет, организационная схема, распределение пространства, оценка, прогноз, цены.


Пиши, записывай, набело переписывай!
Важно записывать принимаемые решения. Только когда пишешь, становятся видны недочёты и проступают несогласованности.

Документы сообщают решения другим людям. Менеджер будет постоянно удивляться, что политика, которую он принимал за общеизвестную, совершенно неизвестна какому-то члену его команды.

Наконец, документы предоставляют менеджеру базу данных и контрольный список.


▍Глава 11. Планируй выбросить


Опять хочу напомнить что речь о каскаде, когда сделали, сдали, поэксплуатировали, а опосля пришла хорошая мысля, и надо бы переделать, и всё сначала.

Хотя я каскад и не применяю, но всё же мне кажется что в моих системах проще кое-что выкинуть и написать заново, чем пытаться исправить на живую нитку.

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

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



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

Я далёк от мысли, что все изменения в целевых критериях и требованиях заказчика должны быть включенными в проект. Должен быть установлен порог, и по мере развития он должен становиться всё выше и выше, иначе продукт никогда не появится.

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



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


Из собаки всех блох не выбьешь
С течением времени система становится всё менее упорядоченной. Рано или поздно исправление ошибок перестаёт приносить плоды. Каждый шаг вперёд сопровождается шагом назад.
Таким образом, думайте сами, решайте сами, менять или не менять, но Брукс предупреждает, а предупреждён — значит вооружён.

▍Глава 12. Заточенные инструменты


Если зрить в корень, то глава про то что много сложных (и не очень), инструментов создано программистами, и для программистов, и для тех кто участвует в разработке на всех этапах. И этими инструментами являются и IDE, и сами языки, и средства проектирования, и средства документирования, и отладки, и тестирования, и чего там только нет, — глаза разбегаются.

А теперь всем этим надо учиться пользоваться — часть ремесла, и вообще полезно для дела.

Без топора не плотник, без иглы не портной
Даже в наш высокотехнологичный век многие программные проекты по-прежнему работают как токарные мастерские, когда речь идёт об инструментах. Каждый мастер тщательно охраняет свой личный набор, собранный за всю жизнь, — видимые свидетельства личных навыков. Точно так же программист хранит маленькие редакторы, сортировщики, двоичные дампы, дисковые утилиты и т. д., припрятанные в его папке.
Интересно, а без чего не программист?

Где тонко, там и рвётся
Существенной проблемой является коммуникация, а индивидуализированные инструменты скорее препятствуют, чем помогают коммуникации.
То, что коммуникации главная проблема, постулировалось ещё в главе «почему провалился вавилонский проект», а раз это главная проблемы, именно она и будет тяготеть и нарастать по любой возможной причине и без причины.

Топор острее, так и дело спорее
Основными причинами использования языка высокого уровня являются продуктивность и скорость отладки. Мы уже говорили о продуктивности (глава 8). Существует не так много численных доказательств, но то, что есть, предполагает кратное улучшение, а не только на инкрементный процент.
Мы это уже видели выше, но там было про косу и покос. Здесь Брукс повторяет свой тезис про использование языков высокого уровня, ну хорошо, и я повторю, ведь повторенье — мать ученья.

▍Глава 13. Целое и части


Глава о том, что как писать работающую и даже надёжную программу требующую согласованной работы многих компонентов. В форме тезисов здесь приведены не все.
На словах ты Лев Толстой…
Среди современных волшебников, как и встарь, встречаются хвастуны: «Я могу писать программы, которые управляют воздушным движением, перехватывают баллистические ракеты, сверяют банковские счета, контролируют производственные линии». На что приходит ответ: «Я тоже могу, и любой человек может, но будут ли они работать, когда вы их напишете?»


Семь раз отмерь, один раз отрежь
Тщательное определение функций, тщательная спецификация и дисциплинированное изгнание излишеств функциональности и полётов технической мысли — всё это уменьшает число системных ошибок, которые должны быть найдены.


Доверяй, но проверяй
Задолго до того, как появится какой-либо код, спецификация должна быть передана группе внешнего тестирования. Сами разработчики не могут этого сделать: «Они не могут признаться, что не понимают её, они будут счастливо прокладывать свой путь через пропущённые и тёмные места».


Паршивая овца всё стадо портит
Задействовать отлаженные компоненты. Здравый смысл, если не обычная практика, говорит нам, что отладку системы следует начинать только после того, как её части, работают. Использование чистых, отлаженных компонентов экономит гораздо больше времени при тестировании системы


Кабы знал, где упасть, так бы соломки подостлал
Возводить строительные леса. Под строительными лесами я подразумеваю все программы и данные, построенные для отладочных целей, но никогда не использующиеся в конечном продукте. Утверждение, что строительные леса имеют объём вплоть до половины кода отлаживаемого продукта, недалеки от истины.


Тише едешь — дальше будешь
Добавлять по одному компоненту за раз. Эта заповедь тоже очевидна, но оптимизм и лень вынуждают нас её нарушать. И в конце концов, не окажется ли, что вся эта работа не понадобится? Может быть, нет никаких ошибок?

Нет! Не поддавайтесь этому искушению! Именно в этом состоит систематичность системного тестирования. Нужно исходить из того, что ошибок будет много, и планировать упорядоченную процедуру их вылавливания.


▍Глава 14. И грянул гром


Название главы просто провоцирует сказать: «гром не грянет, мужик не перекрестится». К чему это? Неважно! А глава о том как происходит отставание от графика.
По капельке море, по зёрнышку ворох
Катастрофа обычно происходит из-за термитов, а не из-за торнадо; отставание происходило незаметно, но неумолимо.

Снегопад, работа в суде присяжных, семейные проблемы, экстренные встречи с клиентами, проверки начальства — список можно продолжать и продолжать. Каждое из этих событий задерживает работу лишь на полдня или на день. И растёт отставание от графика, каждый раз ещё на один день.



Не уговорясь на берегу, не пускайся за реку!
Как контролировать крупный проект по жесткому графику? Первый шаг — иметь график. Каждое событие из списка событий, именуемых контрольными точками, имеет дату.

Для подбора контрольных точек есть только одно релевантное правило. Контрольные точки должны быть конкретными, специфичными, измеримыми событиями, точно определён

© Habrahabr.ru