Как называют разработчиков
В своём блоге я взаимозаменяемо использую термины «программист», «кодер», «разработчик» и «инженер», чтобы избежать тавтологии. Тем не менее я считаю, что между этими словами и другими аналогичными есть некоторые различия.
В этой статье обсудим набор типичных существительных для обозначения человека, который пишет код. Я дам свою интерпретацию, как эти термины соотносятся с уровнем мастерства.
Толкование значений
Представленные здесь определения не являются официальными. Я не знаю каких-то формальных определений или принятого стандарта. Тем не менее, у многих людей есть твёрдое мнение по этому вопросу. Мое понимание каждого термина основано на 30 годах опыта в индустрии программного обеспечения, но я абсолютно готов к тому, что другие не согласятся с моей интерпретацией.
Не хочу спорить или убеждать людей с иным мнением. Вообще, вряд ли тут можно говорить о правильном или неправильном мнении. Тем не менее, если вы ещё не сформировали позицию по данному вопросу, надеюсь, что это руководство внесёт некоторую ясность.
Трёхсторонний подход
Для ясности каждый термин получит три характеристики:
1. Уровень мастерства
Описание уровня квалификации для этого термина, в моей интерпретации.
2. Параллель с рангами боевых искусств
Аналогия с рангами боевых искусств. В частности, сравним технический уровень навыков с цветами поясов у мастеров боевых искусств.
3. Пример кода
Пример того, как человек этого уровня должен подойти к простой программистской задаче. Определение тут тривиальное и не задумывалось как реалистичный пример. Цель — сравнить и обсудить уровень квалификации. Простотой пример подобран так, чтобы подойти специалисту любого уровня. Вот какую проблему мы рассмотрим:
Вычислить сумму целых чисел
Пожалуйста, подыграйте мне и представьте эту задачу как промежуточную для гораздо более сложной. В нашей вымышленной Вселенной задача требует серьёзных размышлений и имеет много потенциальных решений и подходов. Представьте, что это центральный модуль системы, которую нужно масштабировать.
Я буду использовать Ruby для тривиальных примеров реализации. Код достаточно прост: он понятен, даже если вы не знаете Ruby.
3. Список
Обсуждаемые существительные:
- Новичок
- Кодер
- (Хакер)
- Программист
- Исследователь (computer scientist)
- Разработчик программного обеспечения
- Инженер программного обеспечения
- Архитектор программного обеспечения
Итак, начнём.
Пояса боевых искусств
![](https://habrastorage.org/getpro/habr/post_images/058/c08/e65/058c08e65dc560018838662a3a1d0baf.jpg)
Когда я жил в Италии в юности — около 20 килограммов назад — то несколько лет практиковал дзюдо и кунг-фу. Тогда я узнал, что во многих боевых искусствах уровню мастерства соответствует цвет пояса. Обычно цвет изменяется от белого к чёрному, где уровень опыта соответствует темноте пояса.
Новичок носит белый пояс, потому что у него нет опыта. Белый цвет означает «новый и чистый». По мере тренировки пояс темнеет, демонстрируя прогресс. Цвет олицетворяет грязь, накопленную с тяжёлой работой и потом. Мастер боевых искусств с многолетним опытом в конечном итоге достигает чёрного пояса, который означает высокий уровень знаний и навыков.
Традиционно пояса были только чёрные или белые. В последние десятилетия появилось больше цветов. Сегодня в разных школах боевых искусств используются разные цвета. Схема зависит от стиля, школы и страны.
Почему мы говорим о боевых искусствах?
Цвета поясов используются, чтобы провести параллель между навыками создания программного обеспечения и навыками мастера боевых искусств. Для этого возьмём цветовую схему, обычно используемую в Европе: белый, жёлтый, оранжевый, зелёный, синий, коричневый и чёрный.
В следующей таблице показаны уровни разработчика, о которых я говорил. Для каждого показан цвет пояса и должность, которую обычно дают специалисту этого уровня:
Уровень профессионала | Уровень боевых искусств (цвет пояса) | Пример должности |
---|---|---|
Новичок | Белый | |
Хакер | Уличный боец (без пояса) | |
Кодер | Жёлтый | Джуниор-разработчик (Jr.Dev) |
Программист | Оранжевый | Разработчик ПО |
Исследователь (Computer Scientist) | Зелёный | Разработчик ПО (Software Developer) |
Разработчик ПО | Синий | Старший разработчик ПО (Sr. Software Dev) |
Инженер-программист (Software Engineer) | Коричневый | Ведущий разработчик (Principal Dev) |
Архитектор ПО (Software Architect) | Чёрный | Архитектор ПО |
Уровень инженерных навыков связан с техническими способностями и навыками командной работы. Название должности — пример, как человека на этом уровне называют в отрасли (это сильно зависит от компании и региона).
Новичок: белый пояс
![](https://habrastorage.org/getpro/habr/post_images/030/640/cda/030640cda8f1edc8f5b5a9f5ecc24c89.png)
С чего-то нужно начинать, и обычно это уровень «вообще нет опыта». Новичок в разработке программного обеспечения — это тот, кто только что познакомился с программированием и находится на ранних этапах обучения. Новички ещё не могут уверенно программировать и не понимают простых программ, не сверившись с книгами, учебниками или не спросив совета у опытного товарища.
Новички способны писать рабочий код, но часто не понимают деталей, почему этот код работает. Они тратят много времени на поиск фрагментов кода на StackOverflow или подобных сайтах и совмещение этих фрагментов, пока что-нибудь не заработает.
Мощные инструменты — это не то, что надёжные навыки
Чтобы ещё больше всё запутать, многие «современные» языки и фреймворки позволяют кому угодно генерировать структуру и некоторые реализации сложных программ без понимания, что происходит за кулисами. Например, запуск простого приложения Ruby on Rails и приём HTTP-запросов можно организовать с помощью нескольких команд из командной строки.
Вот как это делается под *nix:
$ gem install rails
…
$ rails new website
…
$ cd website
$ bin/rails server
...
Готово! Этого достаточно, чтобы сервер отвечал на HTTP-запросы от браузера. Если сравнить с боевыми искусствами, то это как появиться на татами в доспехах и с оружием. Броня позволит вам чуть дольше прожить, а с оружием можно выиграть схватку. Но такая победа не делает вас квалифицированным мастером боевых искусств. Эти инструменты просто позволяют сделать что-то сложное без традиционного обучения и усилий.
Не поймите меня неправильно. Инструменты вроде Ruby on Rails позволяют быстро выполнить работу, и они великолепны. На самом деле я считаю фантастикой возможность сократить время на написание начального стандартного кода. Это отличное начало проекта, но здесь достаточно лишь белого пояса.
Настоящая схватка начинается там, где учебник заканчивается, где инструменты не могут автоматически сгенерировать нужное вам приложение. Чтобы двигаться дальше, нужно стать кодером.
Пример
Если новичок захочет написать программу, которая суммирует набор чисел с помощью Ruby, то может загуглить вопрос и найти такую страницу. Это первый результат в выдаче Google на момент написания этой статьи. На странице StackOverflow самый заплюсованный ответ с 524 голосами:
array.inject(0){|sum,x| sum + x }
Конечно, это работает. Вот пример:
$ irb
2.4.2 :001 > array=[1,2,3]
=> [1, 2, 3]
2.4.2 :002 > array.inject (0){|sum, x| sum + x }
=> 6
Это может работать у новичка, но он не понимает особенностей этого кода. Насколько он читаем? Насколько быстро выполняется по сравнению с другими вариантами? Легко ли его поддерживать? Почему он работает? Что именно произойдёт при выполнении этой строки? Сколько используется процессорного времени? Определены ли переменные sum и x после выполнения этой строки?
Начинающий разработчик на Ruby не знает ответов на большинство из этих вопросов.
Кодер: жёлтый пояс
![](https://habrastorage.org/getpro/habr/post_images/fad/3bb/253/fad3bb253631eda0cbe2777ef9238188.png)
Кодер может без посторонней помощи собрать много строк компьютерного кода для решения простых проблем. Результат будет не очень красивым, но кодер понимает, почему программа работает, и он успешно выполняет задание.
Первый необходимый шаг
Я назвал свой блог CoderHood, потому что каждый, кто зарабатывает на жизнь программированием, в какой-то момент достиг уровня кодера. Слово Coderhood отражает жизнь разработчика в мире технологий, начиная с первого жёлтого пояса.
Основное различие между новичком и кодером в том, что кодер способен писать код и понимать его. Они может не понимать в деталях, что происходит за кулисами, но он знает, почему написал именно такой код.
В отрасли кодеру обычно присваивают должность вроде «младшего разработчика» (jr. developer) или стажёра (developer in training).
Пример
Я думаю, что «Ruby-кодер» сможет придумать большинство нижеперечисленных методов вычисления суммы массива целых чисел и понять разницу между ними:
$ irb
2.4.2 :001 > array=[1,2,3]
=> [1,2,3]
2.4.2 :002 > array.inject (0){|sum, x| sum + x }
=> 6
2.4.2 :003 > sum=0;array.each { |x| sum+= x }
=> 6
2.4.2 :004 > array. sum
=> 6
2.4.2 :005 > array.inject(0, :+)
=> 6
2.4.2 :006 > array.reduce(0, :+)
=> 6
2.4.2 :007 > eval array.join '+'
=> 6
Если вам интересно, некоторые из этих методов ужасны, но они работают.
Хакер: джинсы без пояса
![](https://habrastorage.org/getpro/habr/post_images/ffa/8f7/972/ffa8f797260594c01d72e1e3443240f9.jpg)
Я включил в список «хакера», потому что меня попросили об этом. Но он не слишком хорошо подходит для нашей дискуссии.
Не главный навык
Я не считаю, что «хакерство» является необходимым навыком на пути развития разработчика программного обеспечения. Такой опыт полезен, чтобы научиться тестировать и защищать программные приложения и системы, но я не вижу здесь описания общего «уровня навыков». Я бы классифицировал это как некую область дейстельности, а не уровень технического мастерства. На самом деле уровень квалификации хакера может быть любой. Некоторые из них удивительны, а другие не очень.
Поскольку хакерство не является необходимым шагом в развитии разработчика, по моей аналогии, у хакера нет традиционного пояса. Они больше похожи на уличных бойцов, носящих джинсы.
Некоторые из них злые головорезы, другие пытаются выжить, третьи — хорошие ребята, которые защищают остальных, но большинство где-то посередине.
Много видов «хакеров»
Есть много типов хакеров. Некоторые умеют программировать, другие нет. Значение слова зависит от контекста и от того, кто его использует. Некоторые общие определения:
- Компьютерный эксперт, который придерживается субкультуры технологий и программирования.
- Человек, который может поставить под угрозу компьютерную безопасность из вредоносных (black-hat) или исследовательских (white-hat) целей.
- Разработчик, который выполняет работу самым быстрым и грязным способом.
- Человек, который изучает, экспериментирует или исследует телекоммуникационные системы, оборудование и системы, подключенные к телефонным сетям. Таких хакеров также называют фрикерами (phreaker).
- Квалифицированный инженер, работающий очень близко к железу, чтобы получить лучший контроль над системой ради хорошего дела (т.е. чтобы выжать больше производительности из оборудования) или для вредоносных целей (т.е. чтобы использовать дыры в безопасности и найти способ обойти защиту операционной системы).
Некоторые примеры
Тип 3
Хакер типа 3 может выбрать такой вариант суммирования массива целых чисел:
$ irb
2.4.2 :001 > 'echo «1 2 3» / bc'.to_i
=> 6
Способ работает, по крайней мере, на некоторых системах, но это… «полный хак». Так делают неквалифицированные хакеры, умеющие программировать. Они решают вопросы сомнительными способами, обычно выполняя нечитаемые команды командной строки, пока каким-то образом не получат желаемый результат.
Тип 5
Хакеры типа 5 работают на очень низком уровне. Такие навыки нелегко приобрести и они могут быть очень ценными, если вы пытаетесь настроить защиту программного обеспечения или создать чрезвычайно высокопроизводительные приложения. Я никогда не был «хакером», но я программировал на низком уровне (C и ассемблер) и по-прежнему в глубине души считаю себя специалистом по низкоуровневому программированию.
Хакеры 5-го типа могут быть фантастическими уличными бойцами, с безумными навыками, которые утрут нос многим профессиональным программистам на некоторых специализированных задачах. Такие «хакеры» могли бы суммировать массив целых чисел с помощью ассемблера примерно так.
Программист: оранжевый пояс
![](https://habrastorage.org/getpro/habr/post_images/e58/99a/5a4/e5899a5a4c4b66114d4a7e090235cbdb.png)
Программист может писать функционирующие приложения, понимает основные алгоритмы и знает основы информатики. Он может заставить программу работать, даже если она будет не очень масштабируемой и поддерживаемой в долгосрочной перспективе. Как правило, программист хорошо работает в одиночку. Не факт, что он будет хорошим командным игроком.
Большинство разработчиков останавливаются на этом уровне, особенно если не планируют изучать теорию информатики. Программисты могут написать приличный код и работать в индустрии программного обеспечения на этом уровне в течение всей карьеры.
С точки зрения должности, программистов часто именуют «разработчиками программного обеспечения» (Software Developer) или «инженерами-программистами» (Software Engineer).
В простом примере суммы массива целых чисел программист может написать код таким образом:
#!/usr/bin/env ruby
if ARGV.size==0
puts "Usage: "
puts " sum [список целых чисел, разделённых пробелами]"
else
puts ARGV.sum{|x| x.to_i}
end
Этот код реализует полезную команду командной строки для суммирования списка чисел. Если вызвать её без параметров, она отображает полезное сообщение об использовании. В противном случае печатает стандартную выдачу. Вот пример использования:
$./sum
Usage:
sum [список целых чисел, разделённых пробелами]
$ sum 1 2 3
6
Это «комплексное решение», самодокументируемое и несколько абстрактное, поскольку программу можно вызвать из командной строки.
Исследователь: зелёный пояс
![](https://habrastorage.org/getpro/habr/post_images/aa3/961/019/aa39610195289bcd9e953bf101712e6c.png)
Исследователь (computer scientist) изучал информатику или в школе, или на работе. Он имеет хорошее понимание таких понятий:
- Основание Base-N (N = 2, 10, 16)
- Бинарные операции
- Булева логика
- Алгоритмическая сложность и нотация big-O
- Структуры данных (массивы, связанные списки, B-деревья, красно-чёрные деревья, очереди, стеки, хэш-таблицы, кучи, наборы, графы)
- Алгоритмы сортировки и когда их использовать
- Базовое понимание NP-полноты
- Основные многопоточные алгоритмы
- Управление памятью и сборка мусора (только то, что ваш язык программирования сам заботится об управлении памятью, не значит, что можно пропустить эту тему)
- Указатели (нужно хотя бы понять концепцию, даже если вы не кодируете на C) и разницу между передачей параметров по значению или ссылке.
- Концепции ООП (интерфейсы, наследование, конструкторы, деструкторы, классы, объекты, абстракции, инкапсуляция, полиморфизм и т.д…)
- Объектно-ориентированный дизайн и шаблоны
- Рекурсия
- Некоторые основные понятия о динамическом программировании, жадных алгоритмах и амортизационном анализе, алгоритмах сравнения строк и аппроксимации
У исследователя степень по Computer Science или он много лет работал разработчиком, изучая прикладную информатику на работе. Как вы знаете, я не считаю, что для успешной карьеры разработчика необходима степень CS.
Один только статус «компьютерного учёного» не делает вас отличным программистом. Здесь как будто нарушается аналогия с цветами поясов. Но это не так. Подумайте с такой стороны: даже в мире боевых искусств есть специализации. Некоторые зелёные пояса лучше других делают некоторые вещи. Прогрессия нелинейная. Цвет пояса часто представляет собой уровень опыта и количество труда, затраченного на овладение боевым искусством, а не обязательный уровень мастерства в каждом аспекте.
Учёный, вероятно, напишет такой же код для суммы чисел, как и программист. Разница в том, что учёный может сразу сказать, что сложность этого алгоритма O(n) времени. Как уже упоминалось, это элементарный пример, но вы уловили мысль.
Разработчик программного обеспечения: синий пояс
![](https://habrastorage.org/getpro/habr/post_images/872/e58/b4a/872e58b4a3f7712ffd09e35aaddbd100.png)
Разработчик программного обеспечения способен осилить более крупные и сложные проекты. По сравнению с программистом и исследователем он:
- Пишет более чистый, структурированный, поддерживаемый, документированный и читаемый код.
- Допускает меньше ошибок.
- Работает быстрее.
- Лучше работает в команде и понимает ценность процессов разработки.
- Лучше находит и оптимизирует узкие места кода и программных систем.
- Имеет больше опыта.
Пример
В простом примере суммы целых чисел разработчик программного обеспечения может решить проблему путём создания службы, предоставляющей Web API. Интерфейс принимает набор целых чисел и возвращает сумму.
Я полагаю, что приложение будет хорошо документировано и поддерживать настройки, сопровождаться тестами, иметь правильную структуру кода и легко обслуживаться другими разработчиками.
На Ruby основное приложение с использованием Sinatra может выглядеть примерно так:
require 'sinatra'
require "sinatra/config_file"
# Load the server configuration from config.yml:
config_file 'config.yml'
#
# EndPoints:
#
# /sum/n1 n2 n3 n4 ...
# Return:
# {result: [sum of n1,n2,n3,n4,...]}
#
# Example:
# $ curl http://localhost:8080/sum/1 2 3 4
# {"result":"10"}
#
get '/sum/:numbers' do |numbers|
{result: numbers.split(" ").collect{ |x| x.to_i}.sum}.to_json
end
Хороший разработчик программного обеспечения хорошо осведомлён о многих ограничениях этого решения по сравнению с другими. Например, оно ограничено суммой набора чисел, которая помещается в URI; здесь нет явной проверки на ошибки, строки должны начинаться с числа и т. д.
Инженер-программист: коричневый пояс
![](https://habrastorage.org/getpro/habr/post_images/dd2/f9e/fb1/dd2f9efb1d33659c9658747d1d31e2d4.png)
Разница между разработчиком (software developer) и инженером-программистом (software engineer) тонкая; я это полностью признаю. Эти термины обычно используются как синонимы. Тем не менее, я предполагают, что инженер-программист — специалист, имеющий знания в области информатики и большой опыт в качестве разработчика программного обеспечения. Основные отличия:
- Возможность создания более масштабируемых систем.
- Долговечность. Они работают дольше и с меньшим количеством проблем.
- Меньше ошибок и лучшее качество кода.
- Умение выступать в роли технического руководителя проекта и команды.
- Отличные навыки сотрудничества и общения.
- Достаточное знание архитектуры программного обеспечения для выполнения работы.
В компаниях у таких разработчиков могут быть должности «старший разработчик» (senior developer) или «ведущий разработчик» (principal developer).
Пример
Инженер-программист может написать приложение как разработчик, создав службу и предоставив API, чтобы взять набор целых чисел. Но я считаю, что решение инженера будет включать в себя некоторые улучшения:
- Кэширование результатов.
- Абстрагирование концепции от суммы к любому математическому выражению в запросе.
- Ведение журнала, аутентификация, отслеживание хуков и т. д.
Пример становится глупым
Как видите, слишком простой пример на этом этапе становится немного глупым. Он сводится к обсуждению, как улучшить и так избыточное решение тривиальной проблемы.
Например, управление кэшем с результатами простых операций над небольшим набором чисел, скорее всего, тяжелее и медленнее, чем простые вычисления. Кэш имел бы смысл в случае огромного массива чисел для передачи в API, но тогда список не поместится в URI запроса.
Вы можете переместить список чисел в тело запроса, но тогда он больше не будет RESTFUL API, и запрос больше не будет кэшироваться. В этот момент возникнет соблазн изменить запрос на POST, но так он никогда не станет кэшируемым. В любом случае, обсуждение может продолжаться и продолжаться.
Критическая часть
Видите, что происходит? По мере совершенствования навыков разработчика и усложнения проектов происходит забавная вещь. Проблемы всё больше отдаляются от «основного кода». Вместо этого они всё больше уходят на обработку контекста, в котором работает основной код.
В результате высококвалифицированные разработчики тратят большую часть времени на совершенствование таких аспектов системы, как масштабируемость, производительность, проверка ошибок, надёжность, сопровождаемость, абстракция, переносимость, обработка граничных условий и т. д.
Кроме того, они узнают, как работать более эффективно или улучшить взаимодействие с другими разработчиками и как подойти к работе, чтобы минимизировать риски и т. д. Разработка программного обеспечения уходит от кодирования в сторону инженерных систем и решения проблем.
Архитектор программного обеспечения: чёрный пояс
![](https://habrastorage.org/getpro/habr/post_images/87e/39d/7cb/87e39d7cb821a077b80483dba71164b8.png)
Все разработчики и инженеры должны быть в состоянии проектировать части систем и продуктов, которые собираются построить. «Архитектор программного обеспечения» выводит этот навык на более высокий уровень и делает выбор при проектировании высокоуровневых взаимодействий более крупных программных систем, разработанных другими инженерами.
Пример
В нашем примере, среди прочего, архитектор может нарисовать такую диаграмму, чтобы направить разработку сервиса для суммирования целых чисел:
![](https://habrastorage.org/getpro/habr/post_images/bdf/961/496/bdf961496573a6bfea74ff502a5d3449.png)
Чтобы эффективно решать такие задачи, архитектору программного обеспечения требуются годы опыта работы на всех уровнях. Этот практический опыт входит в мышечную память. Он позволяет архитектору принимать правильные решения высокого уровня, не зацикливаясь на деталях.
Тем не менее, я не верю в чистых архитекторов, то есть инженеров, которые полный рабочий день принимают решения на высоком уровне. Думаю, что надёжный архитектор должен спускаться на уровень отдельных деталей и выходить оттуда, когда это необходимо. Он готов регулярно и эффективно погружаться в код.
В боевых искусствах чёрный пояс — учитель и наставник. Думаю, что обучение и наставничество также являются задачами архитектора программного обеспечения. Преподавание, о котором я говорю, не прямое (лекции), но больше делается на примере, показывая путь и направляя людей к принятию своих решений.
Выводы
Серьёзные бойцы изучают боевое искусство всю жизнь; серьёзные разработчики программного обеспечения делают то же самое. Надеюсь, вы нашли полезным это обсуждение. Хочу надеяться, что оно обеспечит контекст некоторым плохо определённым терминам, а в идеале поможет объяснить, как более точно их использовать.