Читаем Искусство программирования для Unix полностью

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

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

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

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

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

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

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

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

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

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

Перейти на страницу:

Похожие книги

Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

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

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT