Книга: Программист-фанатик

Совет 7 Будь универсалом

Совет 7

Будь универсалом

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

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

Все сотрудники так называемой фабрики по производству программ являются специалистами. Они занимают свои места в конвейерной цепочке, при помощи своих инструментов соединяя друг с другом Java-компоненты или шлифуя шероховатости приложений, написанных на языке Visual Basic. Инспектор № 12 работает тестировщиком. К нему стекаются компоненты программ, и он каждый день единообразно проверяет их и ставит штамп. J2EE-проектировщики создают J2EE-приложения. C-кодеры пишут код на языке C. Это крайне простой и поделенный на четкие категории мир.

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

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

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

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

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

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

Обычный кодер, тестировщик, дизайнер или проектировщик в моменты, когда работа над проектом приостанавливается, будет бить баклуши или заниматься имитацией деятельности. Обычный программист, работающий с J2EE, NET или UNIX, не сможет ничего внести в проект на стадиях, не имеющих отношения к его непосредственной области деятельности. И дело тут не в том, каким из звеньев производственной цепочки ты себя ощущаешь (а высшим звеном тут всегда будет разработчик архитектуры). Дело в том, насколько полезным ты можешь стать.

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

Чтобы стать универсалом, нужно не связывать себя с определенной ролью или технологией. Определить свое место можно разными способами. Чтобы лучше представить себе возможности универсала, имеет смысл разбить перспективы карьеры в IT на набор независимых аспектов. Я выделил пять, но на самом деле их может быть бесконечное количество (все зависит от того, как лично вы делите темы):

? ступенька карьерной лестницы;

? платформа/ОС;

? код в сравнении с данными;

? системы в сравнении с приложениями;

? бизнес в сравнении с IT.

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

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

Еще одна искусственная (и непозволительная) граница разделяет платформы и операционные системы. Все более непрактично становится быть специалистом по UNIX, отказывающимся работать с Windows. То же самое касается .NET и J2EE и любых других инфраструктурных платформ. Долгосрочные перспективы на рабочем месте требуют независимости от платформы. У каждого из нас есть свои предпочтения, но их лучше оставить дома. Стань экспертом в одном и как следует разберись во всем остальном. Платформа — только инструмент. Специалиста по Windows можно нанять и на Филиппинах. А вот того, кто реально разбирается в разработке для Windows и UNIX и может помочь с интеграцией в обеих системах, лучше поискать в собственной стране. От подобных навыков не стоит отказываться, так как они относятся к умению работать в команде.

Также сложно провести водораздел между администратором баз данных (должность, которая в прошедшее десятилетие появилась буквально из ниоткуда) и разработчиком программного обеспечения. Во многих организациях администраторы баз данных (DataBase Administrator, DBA) знают, как использовать кое-какие инструменты администрирования и как установить конкретный программный продукт. От них не требуют умения использовать базы данных. Разработчики программного обеспечения со своей стороны ленятся работать с базами, а порой и плохо представляют, как это делается. В итоге одно цепляется за другое.

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

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

Оглавление книги