- @rb2 вычитка
- @rb2 коррекция перевода
- @SergAtGitHub вычитка, коррекция
- @akalyaev вычитка, коррекция
Перевод не мой. Один хабраюзер опубликовал его, но из-за проблем с авторским правом решил спрятать в черновик. С его разрешения оставляю текст здесь.
(Примечание от переводчика: Уже были опубликованы переводы нескольких глав замечательной книги Чеда Фаулера «Страсть к программированию». Так как предыдущий перевод уже не обновлялся месяц, попробую продолжить, ибо книжка действительно заслуживает внимания.)
Предыдущая часть:
По крайней, мере пару десятилетий менеджеры и владельцы бизнеса считали, что разработка программного обеспечения – по сути, конвейерный процесс. Создаются технические требования, архитекторы претворяют эти спецификации в высокоуровневое техническое видение. Дизайнеры заполняют архитектуру детализированной дизайн-документацией, которая передаётся роботоподобным кодерам, которые, держа научно-фантастические новеллы в одной руке, другой вслепую печатают реализацию дизайна. В итоге, Инспектор 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 карьеру на несколько независимых аспектов. Я разбил на пять, но их число бесконечно (в зависимости от того, как лично вы распределяете темы):
- Ступеньки карьерной лестницы
- Платформа/Операционная система
- Код или данные
- Системы или приложения (Systems vs. applications)
- Бизнес или IT
Это разные уровни, на которых вы можете подойти к проблеме превращения в универсала. Это просто способ окинуть взором всю вашу карьеру, поэтому вполне вероятно, что конкретно вам будет удобен другой список. А сейчас мы обсудим этот.
Во-первых, вы можете быть либо лидером, либо управленцем, либо техническим исполнителем. Или вы можете отнести себя к архитектору в противовес программисту или тестеру. Умение быть гибким в ролях, на которых вы сможете находиться – свойство, значение которого многие люди не понимают. Например, когда сильный лидер должен избегать замещения как можно чаще, новый состав команд с минимально необходимым числом сотрудников (onshore skeleton crews) может получить выгоду от человека, который не только знает, как руководить людьми и проектами, но может ещё, закатав рукава, исправить в последнюю минуту некоторые критические ошибки, пока удалённые (offshore) работники спят. То же справедливо для создателя ПО, который может резко увеличить прогресс, если он или она всего лишь напишет немного кода, чтобы сдвинуть проект с мертвой точки. Очень часто, когда наступает время пересечь границу иерархии, желанию человека может помешать отсутствие навыков. Программисты-гики не могут быть лидерами, а лидеры не могут программировать (to hack). Сложно найти кого-то, кто хорош в обеих ролях.
Другая искусственная (и непростительная) граница пролегает в районе платформ и операционных систем. Быть UNIX-Парнем, который отказывается даже слышать о Windows, становится все более и более непрактичным. То же самое происходит, когда .NET сравнивают с J2EE и другими такими же платформами. Перспектива будет требовать нейтральность к платформе. У нас у всех есть предпочтения, но вы должны будете оставить ваши идеалы дома. Мастерски владейте одним и будьте хороши в остальных. Ваши навыки должны превосходить технологическую платформу. Это всего лишь инструмент. Если нам нужен человек, разбирающийся в Windows, мы можем нанять его на Филиппинах. Если нам нужен кто-то, кто действительно хорошо понимает тонкости разработки под Windows и UNIX, и может нам помочь связать их вместе, мы будем искать человека в костяк команды.
Разделительная черта между администратором баз данных и разработчиком ПО также должна быть размыта. Быть администратором БД (DBA) во многих организациях означает, что вы знаете, как использовать некоторые графические инструменты администратора, и вы можете настроить специфическое приложение БД. Вам необязательно разбираться в том, как использовать базу данных. С другой стороны, разработчики ПО больше ленятся и становятся все более невежественными в вопросах работы с базой данных. Каждая сторона кормит друг друга.
Когда я вступил в поле информационных технологий, первое, что меня поразило больше всего, было то, что много хорошо образованных программистов (может быть даже большинство) не знают простых вещей о настройке системы, которую они используют для разработки и развёртывания. Я работал с разработчиками, которые не могут даже установить операционную систему на PC, если вы их попросите, и немногие смогут настроить сервер приложений, на которых они развёртывают свои программы. Редко удаётся найти разработчика, который действительно разбирается в платформе, которую он или она используют. Как результат -- приложения у них получаются лучше и работа выполняется быстрее.
В конце концов, как мы уже обсуждали в главе «Кодинг ещё не всё», стена между бизнесом и IT должна быть снесена. Начинайте изучать, как работает ваш бизнес.
-
On a piece of paper or a whiteb oard,list the dimensions on which you may or may not be generalizing your knowledge and abilities. For each dimension, write your specialty. For example, if Platform and Operating System is one of your dimensions, you might write Windows/.NET next to it. Now, to the right of your specialty, write one or more topics you should put into your “To Learn” list. Contin- uing with the same example, you might write Linux and Java (or even Ruby or Perl).
-
Выпишите на листке бумаги или офисной доске направления, по которым вы можете или не можете обобщить свои знания и способности. Для каждого из направлений напишите свою специализацию. Например, если один из пунктов вашего списка -- "Платформа / Операционная система", рядом можно написать "Windows/.NET". Теперь, ещё правее от специализации, напишите одну или более тем, которые стоило бы поместить в список "Изучить". Продолжая этот же пример, вы можете написать дальше Linux и Java (а может даже Ruby или Perl).
As soon as possible (some time this week at the latest!), find thirty minutes of time to start addressing at least one of the “To Learn” items on your list. Don’t just read about it. If possible, get some hands-on experience. If it’s web technology, then download a web server package and set it up yourself. If it’s a business topic, find one of your customers at work and ask them to go out for lunch for a chat.
Как можно скорее (на этой неделе!) найдите 30 минут для того, чтобы начать заниматься хотя бы одним из пунктов списка "Изучить". Не достаточно будет просто прочитать про него. Попробуйте что-то сделать с его помощью, если это возможно. Если это веб-технология, то самостоятельно скачайте и установите веб-сервер. Если это из области бизнеса, найдите одного из ваших клиентов (заказчика, покупателя) и пригласите его поговорить во время обеда.