Разработчик, Инженер, Архитектор

Разработчик, Инженер, Архитектор

Титулы в сфере программирования

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

Значение терминов

Программист/разработчик программного обеспечения Тот, кто пишет код на языке программирования, может также участвовать в проектировании и тестировании. Обычно человек младшего и среднего уровня.

Инженер-программист Человек, который разрабатывает, пишет и тестирует программное обеспечение. Обычно человек среднего и старшего уровня.

Архитектор программного обеспечения Кто-то, кто принимает решения на высоком уровне проектирования и диктует технические стандарты, включая стандарты кодирования программного обеспечения, инструменты и платформы. Обычно человек старшего уровня.

Разработчик, а не программист

Итак, давайте начнем с того, что я использую термин «разработчик», а не «программист». Я предпочитаю термин «разработчик», поскольку по моему опыту программирование (процесс написания кода) составляет довольно небольшую часть моей работы. Разработка программного обеспечения — это проектирование, решение проблем и поиск первопричин дефектов. (Я открыт для лучшего слова, чем поиск основной причины дефекта.) Однажды меня спросили, хочу ли я быть кодером до конца своей жизни? Это заставило меня задуматься об этом термине. Я считаю, что программист больше похож на кодера, и я не верю, что любой разработчик может долго оставаться кодером. На самом деле, писать код никогда не входит в ваши обязанности. Не уверены, что согласны? Вы когда-нибудь удаляли код? Я знаю, что у меня был опыт удаления большого количества кода, и я считал этот день продуктивным. Вы когда-нибудь тратили день на поиск первопричины дефекта? Вы считали этот день продуктивным? Вот почему KLOC — не такая хорошая метрика, как кажется, потому что наша работа — не писать код, а разрабатывать надежную функциональность, доступную пользователю. Если вы можете улучшить функциональность для пользователя, написав меньше кода, то вы работаете продуктивно. Поэтому я называю себя разработчиком.

Отложите свой опыт

Статьи, которые я читал об отсутствии необходимости в этих различиях, часто сосредоточены вокруг людей, которые какое-то время разрабатывают программное обеспечение и обнаруживают, что им не нужны люди, занимающие эти разные роли. По сути, аргумент звучит так: я уже некоторое время занимаюсь разработкой программного обеспечения, я часто работаю над полным стеком (от бэкенда до внешнего интерфейса). Я принимаю все решения (инструменты, платформа, дизайн, реализация), поэтому между этими ролями нет различий. Тем не менее, этот же человек, вероятно, также занимается управлением проектами, обеспечением качества и контролем качества. Очевидно, что это не то же самое, что обязанности разработчика. Ошибка здесь заключается в том, что для разных ролей требуются разные люди. Если вы достаточно опытны, а проект достаточно мал, вы, скорее всего, сами справитесь со всем шоу. Это означает, что вы носите много шляп, а не то, что шляп не существует. Причина, по которой мы говорим об этих разных ролях, состоит в том, чтобы выразить как обязанности, так и навыки, необходимые для ролей. Если вы покрываете роли качества и разработки для своего проекта, это нормально. Если вы просто игнорируете роль качества, вам, вероятно, это сойдет с рук на какое-то время, но в конечном итоге это вас укусит. Архитектура похожа. Вы можете закодировать решение проблемы (если оно достаточно прямолинейно), но поскольку эту кодовую базу со временем просят изменить, в конечном итоге отсутствие архитектуры станет дорогостоящим. Итак, вы видите, что тот факт, что вы выполняете каждую роль, не отменяет того факта, что существуют отдельные роли.

Предполагаемый прогресс

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

Архитектор программного обеспечения

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

Разработчик программного обеспечения

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

Разница в фокусе

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

Вы можете сделать оба

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

Программист

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

Почему бы не спроектировать все?

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

Забрать

Программное обеспечение — относительно новая дисциплина, как с точки зрения инженерии, так и с точки зрения ремесла. Мы все еще пытаемся разобраться в этом. Так что мы все должны быть открытыми. Мы должны оставаться открытыми для корректировки наших методов и словарного запаса. Тонкая настройка того, как мы подходим к проблемам. Программное обеспечение будет двигаться в сторону специализации, как и другие отрасли. Уже невозможно быть «хорошим» во всех аспектах разработки программного обеспечения. Разработчик, DevOps, архитектор и инженер — это лишь некоторые из многих титулов, которые, как мне кажется, мы будем использовать в этой области.