(Примечание от переводчика: Уже были опубликованы переводы нескольких глав замечательной книги Чеда Фаулера «Страсть к программированию». Так как предыдущий перевод уже не обновлялся месяц, попробую продолжить, ибо книжка действительно заслуживает внимания.)
Предыдущая часть:
Как я отказался от $300.000, предложенных мне компанией Microsoft, взамен на полный рабочий день на GitHub’е.
По крайней мере пару десятилетий, менеджеры и владельцы бизнеса считали, что разработка программного обеспечения – по сути конвейерный процесс. Технические требования создаются, архитекторы претворяют эти спецификации в высокоуровневое техническое видение. Дизайнеры заполняют архитектуру детализированной дизайн-документацией, которая передается роботоподобным кодерам, которые держа научно-фантастические новеллы в одной руке, другой в слепую печатают реализацию дизайна. В итоге, Инспектор 12 (прим. пер. — судя по всему отсылка на старую рекламу) получает законченный код, на который она не поставит свой подтверждающий штамп, до тех пор, пока не увидит оригинальные спецификации.
Не удивительно, что менеджеры хотят видеть разработку ПО, как конвейер. Менеджеры понимают, как организовать такое производство. У нас за плечами десятилетия опыта, в построении физических объектов эффективно и правильно. Поэтому перенося опыт с производства, мы должны иметь возможность преобразовать процесс разработки софта в хорошо настроенный механизм, функционирующий аналогично производственным предприятиям.
В так называемой «фабрике софта», сотрудники – специалисты. Они сидят на своих местах на конвейере, скрепляя Java-компоненты вместе, или стачивая острые углы Visual Basic –приложения, на своих станках. Инспектор 12 – тестер по профессии. Компоненты программы двигаются по линии, и она тестирует и ставит на них печать одним и тем же образом каждый день. Разработчики J2EE разрабатывают J2EE приложения. Программисты С++, программируют в С++. Мир чист и разделен на ячейки.
К сожалению аналогия с производством не работает. Программное обеспечение такое же изменчивое, как требования к нему. Времена изменились и бизнесмены осознали, что ПО податливое (прим. пер. — игра слов software is soft) и может измениться в угоду новым требованиям. Это значит, что архитектура, дизайн, код и тесты должны создаваться гибкими и легко исправляться, чего не может предложить сухой производственный процесс.
В рамках быстро изменяемого окружения, гибкость будет доминировать. Когда сроки сжаты, опытный предприниматель обратится к профессиональному разработчику, который может решить нависшую проблему. Так как же стать этим человеком, чье имя произносится когда ищут супергероя, который спасет положение? Суть в том, чтобы быть способным решать проблемы, которые еще не возникли.
Что это за проблемы? Правильно: вы не знаете. Я тоже. Все что я знаю – это то, что эти проблемы такие же разнообразные, как вопросы развертывания, критические недостатки дизайна, которые должны быть решены и быстро переделаны, разнородная системная интеграции и специальная генерация отчетов. Столкнувшись с проблемой такой же нестандартной, как эти, бедный Инспектор 12 будет выбит из колеи довольно быстро.
Ярлык «и швец и жнец и на дуде игрец» (jack-of-all-trades but master of none) обычно подразумевает, что его носителю не хватает внимания, чтобы глубоко погрузиться в тему и освоить её. Но когда ваша программа для онлайн магазина ломается, и вы теряете заказы сотнями в час, то «швец и жнец» (the jack-of-all-trades) – тот человек, который не только знает, как работает код приложения, но еще и может провести низкоуровневый UNIX дебаг вашего веб сервера, проанализировать вашу RDBMS конфигурацию на предмет потенциальных «бутылочных горлышек» и проверить настройку вашего сетевого роутера с целью найти сложно-отлавливаемые проблемы. И, что более важно, после нахождения проблемы, этот человек сможет быстро принять архитектурные и дизайнерские решения, исправить код, и выпустить новую, работающую систему в продакшн. В этом случае, производственный сценарий выглядит причудливым в лучшем и полностью испорченным в худшем случае.
Другая проблема с которой сталкивается «фабрика ПО», заключается в том, что в противовес конвейеру, где работа стабильно однообразная, разработка программного обеспечения обычно носит циклический характер. Не только фактическое течение проектов циклично, но и работа внутри проекта тоже циклична. Программист валяет дурака, пока требования разрабатываются, строятся и устанавливаются, или же программист выполняет задачи сразу по нескольким проектам. Проблема с многозадачными программистами в том, что в отличие от идеи «фабрики ПО», в реальной жизни программисты очень сильно полагаются на ситуацию и свой опыт, чтобы сделать свою работу. Требования, архитектура и дизайн документы могут быть хорошим началом, но в сущности, если программисты не понимают, что должна делать система, они не смогут создать её качественную реализацию.
Конечно, здесь я говорю не только о программистах. Все то же самое справедливо в каждой точке программного конвейера. Важно владеть конкретным контекстом задачи и поэтому многозадачность работает плохо. В результате мы имеем неэффективную систему производства. Предпринимались различные попытки решить эту проблему, не уходя от конвейерно-ориентированной системы, но мы все еще не знаем, как оптимизировать наши «фабрики ПО» до приемлемого уровня.
Если вы только кодер или тестер, или дизайнер, или архитектор, в конце концов вы можете обнаружить себя сидящим без дела или делающим бесполезную работу. Если вы только J2EE программист, или .NET программист или программист UNIX систем, вы не внесете большой вклад, когда направление проекта или компании выходит за рамки, даже временно, вашей профессиональной области. Речь не о том, какое место вы занимаете в пищевой цепи вашего проекта (где архитекторы занимают высшую позицию). Речь о том, насколько универсальным вы можете себя сделать.
Если ваша цель остаться на ногах посреди волн увольнений, вам лучше стать универсалом. Когда в вашем некогда переполненном офисе останется только внутренний костяк команды, то вы осознаете, что в такой команде всего несколько мест и «только-тестер» или «только-кодер» не будут пользоваться спросом.
Универсалы редки… и, следовательно, драгоценны.
Путь к универсальности в том, чтобы не загонять себя в рамки специфической роли или технологии. Чтобы представить себе, что значит быть универсалом, полезно будет разбить IT карьеру на несколько независимых аспектов. Я разбил на пять, но их число бесконечно (в зависимости от того, как лично вы распределяете темы):
• Ступеньки карьерной лестницы
• Платформа/Операционная система
• Код vs. Данные
• Системы vs. Приложения (Systems vs. applications)
• Бизнес vs. IT
Это разные уровни, на которых вы можете подойти к проблеме превращения в универсала. Это просто способ окинуть взором всю вашу карьеру, поэтому вполне вероятно, что конкретно вам будет удобен другой список. А сейчас мы обсудим этот.
Во-первых, вы можете быть либо лидером, либо управленцем, либо техническим исполнителем. Или вы можете отнести себя к архитектору в противовес программисту или тестеру. Умение быть гибким в ролях, на которых вы можете и будете находиться – свойство, значение которого многие люди не понимают. Например, когда сильный лидер должен избегать замещения как можно чаще, новый мир команд с минимально необходимым числом сотрудников (onshore skeleton crews) может получить выгоду от человека, который не только знает, как руководить людьми и проектами, но может еще и закатав рукава исправить в последнюю минуту некоторые критические багги, пока удаленные (offshore) работники спят. Тоже справедливо для архитектора ПО, который может резко увеличить прогресс если он или она всего лишь напишет немного кода, чтобы сдвинуть проект с мертвой точки. Когда наступает время пересечь границу иерархии, очень часто не нежелание останавливает людей, а отсутствие возможности. Программисты-гики не могут быть лидерами, а лидеры не могут программировать (to hack). Сложно найти кого-то, кто хорош в обеих ролях.
Другая искусственная (и непростительная) граница пролегает в районе платформ и операционных систем. Быть UNIX-Парнем, который отказывается даже слышать о Windows, становится все более и более не практичным. То же самое происходит с .NET vs. J2EE и другими такими же платформами. Перспектива будет требовать нейтральность к платформе. У нас у всех есть предпочтения, но вы должны будете оставить ваши идеалы дома. Мастерски владейте одним, и будьте хороши в остальных. Ваши навыки должны превосходить технологическую платформу. Это всего лишь инструмент. Если нам нужен человек разбирающийся в Windows, мы можем нанять его на Филиппинах. Если нам нужен кто-то, кто действительно хорошо понимает тонкости разработки под Windows и UNIX, и может нам помочь связать их вместе, мы будем искать человека в костяк команды.
Разделительная черта между администратором баз данных и разработчиком ПО, так же должна быть размыта. Быть администратором БД, или DBA, во многих организациях означает, что вы знаете как использовать некоторые GUI tools для администратора, и вы можете настроить специфическое приложение БД. Вам не обязательно разбираться в том, как использовать базу данных. С другой стороны, разработчики ПО больше ленятся и становятся все более невежественными в вопросах работы с базой данных. Каждая сторона кормит другую.
Когда я вступил в поле информационных технологий, первое что меня поразило больше всего было то, что много хорошо образованных программистов (может быть даже большинство), не знают простых вещей о настройке системы, которую они используют для разработки и развертывания. Я работал с разработчиками, которые не могут даже установить операционную систему на PC, если вы их попросите, и немногие смогут настроить сервер приложений, на которых они развертывают свои программы. Редко удается найти разработчика, который действительно разбирается в платформе, которую он или она используют. А ведь у них приложения создаются лучше и быстрее.
В конце концов, как мы уже обсуждали в главе «Кодинг еще не всё», стена между бизнесом и IT должна быть снесена. Начинайте изучать, как работает ваш бизнес.
Автор: Vad118
