О разработке программного обеспечения. Взгляд архитектора

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

Задачи архитектора (в порядке приоритета)

1. Выбраковка технологий; следует отбросить мусорные технологии (junk technologies); свести количество используемых технологий к минимуму;

2. Свести заказ клиента к решению, комбинируемому из набора используемых компанией внутренних технологий;

3. Скомбинировать / накопить простые / высокоскоростные внутренние технологии;

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

От чего большие "большие"?

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

"Новые" технологии и спецификации плодятся постоянно; это не проверенные временем, не устоявшиеся предметы. Большинство их: в очередной раз изобретённый "велосипед", с новым тюнингом и под новым названием. Заставлять программистов "зубрить" их – бессмысленно.

"Новые" технологии, платформы, языки – часто порождение маркетинга / моды. "Клиент" требует выполнения работы на них (в том числе реинжиниринга / развития уже написанного проекта).

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

Большие от того и "большие", что масштабируются, пользуясь сведением разрабатываемых решений к используемому набору внутренних технологий, сложить которые – задача архитекторов.

Технологический коридор

Технологический коридор, в части непосредственной работы над программным продуктом, включает набор технологий, и правила, водимые архитектором.

Технологии/правила должны быть отобраны/составлены так, чтобы любого среднестатистического программиста (в том числе студента) можно было в период 2-4 недели обучить пользованию, и полноценно подключить к работе над проектом. В технологический коридор, в части корпоративной культуры, входят в том числе организация рабочего места персонала (OS, IDE, environment); социальные / "корпоративные" технологии / культуры.

Схемы составления группы разработчиков ("команды")

Задача составления группы - выбор / обучение единиц, каждая из которых будет двигаться в специфичном для неё направлении.

Группа - коллектив, каждая единица которого ориентирована на работу со специфическими технологиями.

Группа составляется из узких специалистов. Нельзя требовать от них досконального знания технологий из смежных направлений (областей) в разработке ПО (в силу ограниченности разума человека это невыполнимо).

Штат (состав) группы на уровне программистов

1. Программист баз данных

2. Программист (распределённые, системные, сетевые решения; потоки, очереди, синхронизация, файлы, протоколы, TCP/IP м прочее)

3. Программист GUI

4. Математик (составление / членение математических моделей / алгоритмов)

Добавляются при работе с графикой:

1. 2D программист

2. 3D программист (работа в паре с математиком)

Дополнительно (общий для нескольких групп персонал):

1. Тюнинговщики (владеют "новыми", "последними", "модными" технологиями; их задача безболезненно для продукта внести те бесполезные технологические «нововведения», что добавляются из соображений маркетинга, или которые обязательно требует заказчик)

2. Оптимизатор (работа с профайлингом и техниками оптимизации)

3. Технологический помощник / системный администратор (функции: вспомогательная работа, редко используемые операции; настройка рабочих мест; слежение за контролем версий, организация сборок, установка/обновление ПО и т. д.)

4. Тестеры (для большой компании)

При небольшом штате задачи тюнинговщиков / технологического помощника / тестеров не "размазываются" по штату, а членятся и "точечно" возлагаются на наиболее подходящих по навыкам / психоскладу членам группы.

Оптимизацию системы / подсистемы / компоненты / модуля выполняет архитектор с привлечением нужных ему программистов.

Конвейерный метод и метод "роста с проектом"

Конвейерный метод применяется при постоянном потоке новых проектов и годится для большой компании. Здесь, как при сборке на конвейере, программисты быстро "надевают" требуемые конструкции на уже имеющийся у компании «скелет», составленный из внутренних технологий. Схему "рост с проектом" выбирают на начальном этапе развития компании, когда штат её ограничен, либо при работе над большим / долгосрочным / защищённым проектом (например, компьютерная игра, банковское решение), когда группу "привязывают" к проекту и она "растёт" вместе с ним, чтобы максимально полно / точно учитывать все детали / специфику проекта.

В схеме "рост с проектом" людской ресурс ограничен, поэтому нагружать программистов знанием нюансов редко используемых и мусорных технологий – неразумно. Здесь применяют метод "создал и забыл": редко используемые участки программы – низкоуровневая обработка GUI / сеть / DB), API движков, корявые системные и иные API, – оборачиваются обёртками и о них "забывают".

Уровень программиста

Задача программиста: взять изложенный в доступной форме алгоритм и переложить его на язык программирования. Программист должен получить на руки перечень технологий / классов / правил, которые он должен выучить / использовать.

Членение и распараллеливание

Программист не должен решать, что следует членить / распараллеливать / оптимизировать, что нет. Это должно быть задано архитектурой и правилами написания продукта. Распараллеливание / членение / оптимизация чего-либо: уровень и задача архитектора. Организация модульности продукта / кода, распределенные / многопоточные конструкции, разбивка кода по уровням (слои realtime / runtime / threadsafe / readonly в программе) – примеры членения. Разбивка задачи между исполнителями – так же пример членения; программист не обучен заниматься членением.

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

Мусорные технологии (junk technologies)

IT-индустрией накоплено огромное количество спецификаций / технологий / API / платформ не удобных ни пользователю, ни разработчику, появление и распространение которых обязано исключительно вливанию денег IT-гигантами в их рекламу / насаждение.

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

Когда крупные корпорации начинают вливать хорошие деньги в пиар "новой технологии" или что-нибудь входит в моду, это значит, к разработчикам вскоре потянутся ручейки клиентов, с заказами по данной тематике. Поэтому пора набирать соответствующих специалистов. Переучивать своих специалистов обычно никто не торопится, ибо мода может пройти, технология может оказаться невостребованной или провальной, но, пользуясь конъюнктурой, деньги на волне её популярности, снять с рынка, конечно, следует.

Уровень маркетолога и тюнинговщиков

Задача маркетолога: придать продукту / технологии тот вид, чтобы "клиент был доволен". Тюнинговщики владеют "новыми", "последними", "модными" технологиями. Их задача: безболезненно для продукта внести те бесполезные "нововведения", что добавляются из соображений маркетинга, или которые обязательно требует заказчик. Бывает, в процессе своей работы тюнинговщики натыкаются на действительно полезные (технологические) нововведения, о чём сообщают архитектору. Тюнинговщиков обычно набирают из любознательных студентов, самостоятельно изучивших "последние", "новые" а, значит, не проверенные временем, не устоявшиеся технологии.

Уровень архитектора

Архитектор работает одновременно со всеми перечисленными специалистами:

1. Выбирает / складывает внутренние технологии;

2. Управляет сложностью проекта;

3. Выбирает технологии;

4. Разрабатывает членение / сопряжение частей программы;

5. Развёртывает структуры;

6. Развёртывает и увязывает GUI /logic / server / hardware -движков между собой;

7. Декларирует API;

8. Локализует "сложности" созданием обёрток над API / технологиями / кодом;

9. Разносит тела программы по уровням (слои realtime / runtime / threadsafe / readonly в программе);

10. Оптимизирует, разносит / балансирует нагрузки (в том числе клиент / сервер);

11. Складывает кастомные языки; полно / точно подгоняет проект под нужды заказчика.

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

У программиста можно спросить "какие библиотеки ты используешь?" и здесь правильный ответ: "какие укажут", знакомство же с архитектором начинается с вопросов, касающихся архитектуры проекта (узлы / подсистемы / уровни / обёртки) и junk-технологий / кода ("какие библиотеки / технологии / стандарты не следует использовать? если они есть, как их локализовать? как бороться с избыточностью технологий / кода?").

Так же вопрос "какие языки / инструменты ты пользуешь?" на уровне архитектора – некорректен; задача архитектора разрабатывать кастомные языки / инструменты в связи с поставленной задачей.

Универсальная платформа для всех случаев. Кастомные языки. Скриптовые процессоры

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

Чтобы полно / точно охватить решаемую задачу, требуются написание полно / точно охватывающих его схем (алгоритмов).

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