UR4QTP: записная книжка 

На главную

Статьи

История случайного новичка

Взято из книги Э.Реймонда «Искусство программирования для Unix» – Москва, 2005. Страница 410. [1]


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

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

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

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

Ньюби слегка озабочен датой завершения проекта. Ему может не хватать опыта, но он прочёл Dilbert [2] и слышал несколько «боевых» историй от опытных программистов. Ньюби знает, что менеджеры имеют склонность к тому, что можно иносказательно назвать «агрессивным» расписанием. Возможно, он прочёл «Death March» Эда Йордона (Ed Yourdon) [3], который в 1996 году отмечал, что большинство проектов слишком, по крайней мере, на 50% лимитированы в отношении времени выполнения и ресурсов, и что этот лимит усугубляется.

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

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

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

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

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

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

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

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

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

К сожалению, эгоцентричные рефлексы, которые приобретает Ньюби, – краткосрочная локальная оптимизация, вызывающая долгосрочные проблемы. Он может написать больше строк кода, но фактическая ценность того, что он создаёт, вероятно, в значительной степени снижается по сравнению с тем, что было бы, если бы Ньюби добился успеха в повторном использовании кода. Бо́льший код – отнюдь не лучший код. Код также не становится лучше, когда он написан на более низком уровне, где почти наверняка «изобретается колесо».

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

Ньюби вполне может найти свой инструментарий бесполезным, даже если сможет украдкой внести его в сборку на новой работе. Его новые работодатели могут использовать другой набор коммерческих инструментов, языков и библиотек. Вероятно, ему придётся изучать какую-либо новую группу методик и изобретать новый набор «колёс» при каждой смене проекта.

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

Профессиональная культура, происходящая из опыта Ньюби, ярко отражает этот опыт. Предприятия, разрабатывающие программное обеспечение, получают сильный NIH-комплекс (Not invented here – изобретено не здесь). Они будут упорно противостоять повторному использованию кода, навязывая своим программистам в целях соблюдения жёстких проектных рамок неадекватные, но интенсивно продаваемые поставщиками компоненты, отвергая при этом повторное использование своего же протестированного кода. Они будут создавать множество узкоспециальных, дублируемых программ. Программисты, создающие эти программы, будут знать, что результатом будет свалка программ, но покорно смирятся с невозможностью исправить что-либо, кроме отдельных частей, созданных самостоятельно.

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


[1] Реймонд Эрик С. Искусство программирования для UNIX.: Пер. с англ. – М.: Издательский дом «Вильямс», 2005. – 544 с.: ил. ISBN 5-8459-0791-8 (рус.)

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

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


Скачать книгу на русском языке: djvu (16МБ).

По-моему, это лучшая книга по философии программирования. Как написано в предисловии, книга не о том, как сделать что-либо, а о том, почему это следует сделать.


[2] По всей видимости, имеется в виду книга Скотта Адамса «Принцип Дилберта»:
The Dilbert Principle: A Cubicle's-Eye View of Bosses, Meetings, Management Fads & Other Workplace Afflictions by Scott Adams. N.Y: "HarperBusiness", 1996. ISBN 0-88730-858-9.

Книга издавалась на русском языке:

Адамс С. Принцип Дилберта: взгляд из офисной кабинки на начальство, совещания, причуды дирекции и прочие бедствия. ООО «Попурри», 1999. 336 страниц. ISBN 985-438-364-4.

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

При желании можно легко найти эту книгу поиском в тырьнете.

Как и обещает автор в предисловии, в книге действительно есть с десяток интересных мыслей :-).


[3] Yourdon E. Death March. The complete software developer's guide to surviving "Mission impossible" projects. Prentice-Hall, 1997. – страница 408.

Книга издавалась на русском языке. Первое издание:

Йордон Э. Путь камикадзе. Издательство «Лори», 2004. 290 страниц. ISBN 0-13-143635-Х, 5-85582-227-3.

Второе издание:

Йордон Э. Путь камикадзе. 2-е издание. Издательство «Лори», 2008. 290 страниц. ISBN 5-85582-227-3.

Книга Эдварда Йордона «Путь камикадзе» представляет собой полное руководство по выживанию в безнадёжных проектах, предназначенное для разработчиков программного обеспечения. Практически каждому разработчику ПО и менеджеру приходится сталкиваться с проектами, характеризующимися никуда не годными персоналом, планом и бюджетом, т. е. проектами, обречёнными на неудачу. В условиях реинжиниринга корпораций безнадёжные проекты становятся «стилем жизни» многих организаций. Книга Эдварда Йордона является руководством по решению следующих проблем: выживание в проектах, обречённых на неудачу; достижение оптимальных соглашений во время переговоров; управление персоналом и расстановка приоритетов; выбор средств и технологий; определение момента, когда уже пора выйти из проекта. Эдвард Йордон применяет свою уникальную технологию и интуицию менеджера к наихудшим вариантам софтверных проектов, показывая, как максимально повысить шансы на успех или, по крайней мере, вывести вашу карьеру из-под удара. Шаг за шагом Йордон проходит все стадии жизненного цикла проекта, учит менеджеров и разработчиков правильно вести себя с заказчиками и оптимально использовать доступные ресурсы, включая людей, средства, процессы и технологию. Учитесь проявлять необходимую гибкость при проведении переговоров, расставлять осмысленные приоритеты и… вовремя выходить из проекта. Если вам когда-либо требовалось совершить невозможное, «Путь камикадзе» – ваша книга.


Поиск в сети этой книги также результативен.

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


Статьи

На главную

 UR4QTP: записная книжка