В принципе, эта книга для "ветеранов программирования" в комментариях не нуждается --- в свое время ее первое издание было очень популярно. Было это в 1974 году...

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

Это, в общем-то, неправда. В том смысле, что, наверное, если считать слово "программист" как обозначение, к примеру, самой низшей должности в иерархии какой-нибудь фирмы, то, может быть это и верно (т.е. в 30 лет надо быть уже "старшим программистом" ;) ). Но если понимать под "программистом" примерно тоже самое, что и "художник", то неверно в принципе.

Попытаюсь объяснить. �так, какие новые технологии программирования появились за последние десять лет (точнее, какие технологии стали популярными). Можно вспомнить CORBA, COM, DCOM; но что это, по сравнению с появлением принципов модульности программного обеспечения? Прямо скажем, тот факт, что программу можно разбить на модули, общающиеся между собой посредством заданных интерфейсов, был значительно более революционен, чем конкретная реализация этого свойства. Появление Java? Опять же, если вспомнить, то это никакое не новшество; очень давно была реализация Berkley Pascal, где как раз применялось понятие машинно-независимого байткода, который можно было запускать на машинах с архитектурой отличной от той, на которой была произведена компиляция. � все равно, если считать Java за "новое", то это не идет ни в какое сравнение с появлением языков программирования "высокого уровня". Для этого достаточно вспомнить рост производительности при переходе от программирования в машинных кодах к использованию языков выского уровня и сравнить это с переходом на Java. UML? Тоже нет, потому что UML только лишь стандартизирует подход к проектированию, т.е. формализует то, до чего каждый проектировщик раньше "доходил" самостоятельно. Учитывая то, что проектировщик обычно имеет опыт реального программирования и на собственном примере понимает, почему, что и как надо делать, то UML не особенно большое подспорье по сравнению, например, все с той же модульностью программного обеспечения.

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

В принципе, второе издание "Мифического человека-месяца" тоже можно привести в качестве примера того, что за последние двадцать-тридцать лет ничего революционного не произошло (в частности, в книге есть статья на эту тему). Потому что ценность "человека-месяца", пожалуй, только возросла вместе с ростом потребности качественного подхода к построению больших программных систем.

Эта книга не о программировании на конкретном языке. В ней очень ясным, живым языком рассказывается о тех выводах, к которым пришел автор в процессе руководства работы над операционной системой OS/360. Некоторые моменты, конечно же, устарели; например, проблема машинного времени уже не стоит в таком остром ракурсе перед программистами (во всяком случае, в большинстве проектов). Тем не менее, общие рекомендации по обеспечению работы большой группы программистов очень сложно переоценить. Например, вы можете сразу же ответить, что лучше: тысяча посредственных программистов, сто хорошиих или десять гениев? �меется в виду, для реализации очень крупного проекта в разумное время. Я не говорю о том, что в книге есть ответ на этот вопрос ;) в книге есть очень полезные мысли на эту тему, которые пригодятся вам при начале работы и наборе сотрудников

"Мифический человеко-месяц" --- это, судя по тому что это выражение вынесено в название, для Брукса самый важный момент в книге. Брукс пишет о том, что нельзя мерять время выполнения проекта просто линейно считая, что если один человек сделает его за сто лет, то сто человек сделают его за один год. Это очень логично, но я не буду доказывать здесь это утверждение, все равно Брукс это сделал много лучше, чем мог бы написать я.

От первого издания второе отличается тем, что в него добавлена статья "Серебряной пули нет", в которой Брукс двадцать лет назад предупреждал о том, что в течение этих лет в программировании ничего революционного не произойдет и статьей, которая была написана специально для второго издания. Эта статья посвящена актуальным аспектам проектирования и ответу на вопрос о том, почему же "Мифический человеко-месяц" до сих пор остался современным.

Резюме

Пожалуй, РѕРґРЅР° РёР· самых лучших РєРЅРёРі, которую выпустили наши издательства РІ последние несколько лет. Несомненно, каждый уважающий себя программист должен иметь представление Рѕ том, что РІ ней написано. Мало того, СЏ считаю что это --- достойная РєРЅРёРіР° для книжной полки программиста любого профессионального СѓСЂРѕРІРЅСЏ. РљРЅРёРіР° читается очень легко; мало того, чтение просто-таки захватывает --- РІ общем, настоятельно рекомендую.