О разработке программного обеспечения. Взгляд руководителя/архитектора
Invite pending
Уважаемые коллеги! В настоящее время рассматриваю предложение от нескольких компаний сформировать/возглавить отдел/группу по разработке ПО. В связи с этим, чтобы каждый раз не повторяться, составил небольшой FAQ по теме. Надеюсь, он будет полезен руководителям компаний/проектов/рабочих групп; инженерам-архитекторам и разработчикам ПО.
Каждая компания должна иметь подобные должностные инструкции. Если буду составлять их для компании, куда трудоустроюсь, продолжение последует.
ЧАСТЬ I. Подходы к складыванию группы разработчиков ПО
1. (главнейшая) задача архитектора (особенно на Java): выбраковка технологий; следует отбросить мусорные технологии (junk technologies); свести количество пользуемых технологий к минимуму;
2. свести заказ клиента к решению, комбинируемому из набора пользуемых компанией внутренних технологий;
3. скомбинировать/накопить простые/высокоскоростные внутренние технологии;
4. формировать технологический коридор (со сброшенным уровнем сложности пользования), которым будут пользоваться алгоритмисты («программисты») в оконцовках.
При невыполнении п.1 и п.2, из списка указанных задач архитектора, невозможно отмасштабировать компанию быстро/качественно. Неумение свести проект к небольшому, эффективному, пользуемому вами набору технологий (что составляют часть корпоративной культуры компании), ведёт к постоянному «переучиванию» программистов, «прыганию» между практиками, текучке кадров, вместо членения/распределения задачи среди «заточенных» под специфичную работу групп/специалистов.
«Новые» технологии и спецификации плодятся постоянно; это не проверенные временем, не устоявшиеся предметы. Большинство их: в очередной раз изобретённый «велосипед», с новым тюнингом и под новым названием. Заставлять алгоритмистов «зубрить» их – бессмысленно.
«Новые» технологии, платформы, языки – часто порождение маркетинга/моды. «Клиент» требует выполнения работы на них (втч. реинжиниринга/развития уже написанного проекта).
Эффективной разработки из мешанины технологий достичь невозможно, ибо разум/память человека весьма ограничены.
Большие компании от того и «большие», что масштабируются, пользуясь сведением разрабатываемых решений к пользуемому набору внутренних технологий, сложить которые – задача архитекторов.
Технологический коридор (в части непосредственной работы над программным продуктом): включает набор технологий, и правила, водимые архитектором.
Технологии/правила должны быть отобраны/составлены так, чтобы любого среднестатистического алгоритмиста (втч. студента) можно было в период 2-4 недели обучить пользованию, и полноценно подключить к работе над проектом. В технологический коридор (в части корпоративной культуры) входят втч. организация рабочего места персонала (втч. OS, IDE, environment); социальные («корпоративные») технологии/культуры.
Задача составления группы: выбор/обучение единиц, каждая из которых будет двигаться в специфичном для неё направлении.
=
Группа: коллектив, каждая единица которого ориентирована на работу со специфическими технологиями.
Группа составляется из узких специалистов. Нельзя требовать от них досконального знания технологий из смежных направлений (областей) в разработке ПО (в силу ограниченности разума человека это невыполнимо).
1. алгоритмист (базы данных)
2. алгоритмист (распределённые, системные, сетевые решения; потоки, очереди, синхронизация, файлы, протоколы, TCP/IP/сеть)
3. алгоритмист (GUI)
4. математик (составление/членение математических моделей/алгоритмов)
Добавляются при работе с графикой:
5. 2D алгоритмист
6. 3D алгоритмист (работа в паре с математиком)
Дополнительно (общий для нескольких групп персонал):
7. тюнинговщики (владеют «новыми», «последними», «модными» технологиями; их задача безболезненно для продукта внести те бесполезные технологические «нововведения», что добавляются из соображений маркетинга, или которые обязательно требует заказчик)
8. оптимизатор (работа с профайлингом и техниками оптимизации)
9. секретарь (с функцией надзора)
10. технологический помощник («системный администратор») (функции: вспомогательная работа, редко пользуемые операции; настройка рабочих мест; слежение за контролем версий, организация сборок, установка/обновление ПО итд.)
11. тестеры (для большой компании)
При небольшом штате задачи тюнинговщиков/технологического помощника/секретаря/тестеров на «размазываются» по штату, а членятся и «точечно» возлагаются на наиболее подходящих по навыкам/психоскладу членам группы. Оптимизацию выполняет архитектор с привлечением нужных ему алгоритмистов.
Конвейерный метод применяется при постоянном потоке новых проектов и годится для большой компании. Здесь, как при сборке на конвейере, алгоритмисты быстро «надевают» требуемые конструкции на уже имеющийся у компании «скелет», составленный из внутренних технологий. Схему «рост с проектом» выбирают на начальном этапе развития компании, когда штат её ограничен, либо при работе над большим/долгосрочным/защищённым проектом (например, компьютерная игра, банковское решение), когда группу «привязывают» к проекту и она «растёт» вместе с ним, чтобы максимально полно/точно учитывать все детали/специфику проекта.
В схеме «рост с проектом» людской ресурс ограничен, поэтому нагружать алгоритмистов знанием нюансов редко пользуемых и мусорных технологий – неразумно. Здесь применяют метод «создал и забыл»: редко пользуемые участки программы – низкоуровневая обработка (GUI/сеть/DB), API движков, корявые системные и иные API, – оборачиваются обёртками и о них «забывают».
Задача алгоритмиста: взять изложенный в доступной форме алгоритм и переложить его на язык программирования. Алгоритмист должен получить на руки распечатанный перечень технологий/классов/правил, которые он должен выучить/пользовать.
Алгоритмист не должен решать, что следует членить/распараллеливать/оптимизировать, что нет. Это должно быть задано архитектурой и правилами написания продукта. Распараллеливание/членение/оптимизация чего-либо: уровень и задача архитектора.
Организация модульности продукта/кода, распределенные/многопоточные конструкции, разбивка кода по уровням (слои realtime/runtime/threadsafe/readonly в программе) – примеры членения. Разбивка задачи между исполнителями – так же пример членения; алгоритмист не обучен заниматься членением.
Однако алгоритмист, в процессе своей работы, обязан сообщать архитектору, что по его мнению следует членить/распараллеливать/оптимизировать.
IT-индустрией накоплено огромное количество спецификаций/ технологий/API/платформ не удобных ни пользователю, ни разработчику, появление и распространение которых обязано исключительно вливанию денег IT-гигантами в их рекламу/насаждение.
«Наблюдай за тем, что скапливается, чтобы узнать, что придет: счастье или беда» (трактат Ян Чжу, V в. до нашей эры).
Когда крупные корпорации начинают вливать хорошие деньги в пиар «новой технологии» или что-нибудь входит в моду, это значит, к разработчикам вскоре потянутся ручейки клиентов, с заказами по данной тематике. Поэтому пора набирать соответствующих специалистов. Переучивать своих специалистов обычно никто не торопится, ибо мода может пройти, технология может оказаться невостребованной или провальной, но, пользуясь конъюнктурой, деньги на волне её популярности, снять с рынка, конечно, следует.
Задача маркетолога: придать продукту/технологии тот вид, чтобы «клиент был доволен». Тюнинговщики владеют «новыми», «последними», «модными» технологиями. Их задача: безболезненно для продукта внести те бесполезные «нововведения», что добавляются из соображений маркетинга, или которые обязательно требует заказчик. Бывает, в процессе своей работы тюнинговщики натыкаются на действительно полезные (технологические) нововведения, о чём сообщают архитектору. Тюнинговщиков обычно набирают из любознательных студентов, самостоятельно изучивших «последние», «новые» а, значит, не проверенные временем, не устоявшиеся технологии.
Архитектор работает одновременно со всеми перечисленными специалистами:
1. выбирает/складывает внутренние технологии
2. управляет сложностью проекта
3. складывает кастомные языки; полно/точно подгоняет проект под нужды заказчика. Не просите архитектора писать «пузырьковую сортировку», перечислять аббревиатуры «EJB-компонент» или мусорных технологий; его голова должна быть занята другим.
У алгоритмиста можно спросить «какие библиотеки ты пользуешь?» (и здесь правильный ответ: «какие укажут»), знакомство же с архитектором начинается с вопросов, касающихся архитектуры проекта (узлы/субсистемы/уровни/обёртки) и junk технологий/кода («какие библиотеки/технологии/стандарты не следует пользовать? если они есть, как их локализовать? как бороться с избыточностью технологий/кода?»).
Так же вопрос «какие языки/инструменты ты пользуешь?» на уровне архитектора – некорректен; задача архитектора разрабатывать (кастомные) языки/инструменты в связи с поставленной задачей.
Если мы пишем ПО для управления механикой станка, аркадную игру, соцсеть, то очевидно, что не может быть «универсальной платформы для всех случаев». Не может быть «универсальной платформы» даже в пределах решений WEB-сегмента.
Чтобы полно/точно охватить решаемую задачу, требуются написание полно/точно охватывающих его схем (алгоритмов).
На определённом этапе роста/сложности проекта, чтобы избежать дублирования кода и упростить процесс разработки/поддержки/масштабирования приложения, алгоритмы следует оборачивать оболочкой кастомных языков, выполняющихся на программных скриптовых процессорах.
Каждая компания должна иметь подобные должностные инструкции. Если буду составлять их для компании, куда трудоустроюсь, продолжение последует.
Оглавление
ЧАСТЬ I. Подходы к складыванию группы разработчиков ПО
- Задачи архитектора, в порядке приоритета
- От чего большие компании «большие»?
- Технологический коридор
- Схемы составления группы разработчиков («команды»)
- Штат (состав) группы на уровне алгоритмистов
- Дополнительно (общий для нескольких групп персонал)
- Конвейерный метод и метод «роста с проектом»
- Уровень алгоритмиста
- Членение и распараллеливание
- Мусорные технологии (junk technologies)
- Уровень маркетолога и тюнинговщиков
- Уровень архитектора
- Универсальная платформа для всех случаев. Кастомные языки. Скриптовые процессоры
Задачи архитектора, в порядке приоритета
1. (главнейшая) задача архитектора (особенно на Java): выбраковка технологий; следует отбросить мусорные технологии (junk technologies); свести количество пользуемых технологий к минимуму;
2. свести заказ клиента к решению, комбинируемому из набора пользуемых компанией внутренних технологий;
3. скомбинировать/накопить простые/высокоскоростные внутренние технологии;
4. формировать технологический коридор (со сброшенным уровнем сложности пользования), которым будут пользоваться алгоритмисты («программисты») в оконцовках.
От чего большие компании «большие»?
При невыполнении п.1 и п.2, из списка указанных задач архитектора, невозможно отмасштабировать компанию быстро/качественно. Неумение свести проект к небольшому, эффективному, пользуемому вами набору технологий (что составляют часть корпоративной культуры компании), ведёт к постоянному «переучиванию» программистов, «прыганию» между практиками, текучке кадров, вместо членения/распределения задачи среди «заточенных» под специфичную работу групп/специалистов.
«Новые» технологии и спецификации плодятся постоянно; это не проверенные временем, не устоявшиеся предметы. Большинство их: в очередной раз изобретённый «велосипед», с новым тюнингом и под новым названием. Заставлять алгоритмистов «зубрить» их – бессмысленно.
«Новые» технологии, платформы, языки – часто порождение маркетинга/моды. «Клиент» требует выполнения работы на них (втч. реинжиниринга/развития уже написанного проекта).
Эффективной разработки из мешанины технологий достичь невозможно, ибо разум/память человека весьма ограничены.
Большие компании от того и «большие», что масштабируются, пользуясь сведением разрабатываемых решений к пользуемому набору внутренних технологий, сложить которые – задача архитекторов.
Технологический коридор
Технологический коридор (в части непосредственной работы над программным продуктом): включает набор технологий, и правила, водимые архитектором.
Технологии/правила должны быть отобраны/составлены так, чтобы любого среднестатистического алгоритмиста (втч. студента) можно было в период 2-4 недели обучить пользованию, и полноценно подключить к работе над проектом. В технологический коридор (в части корпоративной культуры) входят втч. организация рабочего места персонала (втч. OS, IDE, environment); социальные («корпоративные») технологии/культуры.
Схемы составления группы разработчиков («команды»)
Задача составления группы: выбор/обучение единиц, каждая из которых будет двигаться в специфичном для неё направлении.
=
Группа: коллектив, каждая единица которого ориентирована на работу со специфическими технологиями.
Группа составляется из узких специалистов. Нельзя требовать от них досконального знания технологий из смежных направлений (областей) в разработке ПО (в силу ограниченности разума человека это невыполнимо).
Штат (состав) группы на уровне алгоритмистов
1. алгоритмист (базы данных)
2. алгоритмист (распределённые, системные, сетевые решения; потоки, очереди, синхронизация, файлы, протоколы, TCP/IP/сеть)
3. алгоритмист (GUI)
4. математик (составление/членение математических моделей/алгоритмов)
Добавляются при работе с графикой:
5. 2D алгоритмист
6. 3D алгоритмист (работа в паре с математиком)
Дополнительно (общий для нескольких групп персонал):
7. тюнинговщики (владеют «новыми», «последними», «модными» технологиями; их задача безболезненно для продукта внести те бесполезные технологические «нововведения», что добавляются из соображений маркетинга, или которые обязательно требует заказчик)
8. оптимизатор (работа с профайлингом и техниками оптимизации)
9. секретарь (с функцией надзора)
10. технологический помощник («системный администратор») (функции: вспомогательная работа, редко пользуемые операции; настройка рабочих мест; слежение за контролем версий, организация сборок, установка/обновление ПО итд.)
11. тестеры (для большой компании)
При небольшом штате задачи тюнинговщиков/технологического помощника/секретаря/тестеров на «размазываются» по штату, а членятся и «точечно» возлагаются на наиболее подходящих по навыкам/психоскладу членам группы. Оптимизацию выполняет архитектор с привлечением нужных ему алгоритмистов.
Конвейерный метод и метод «роста с проектом»
Конвейерный метод применяется при постоянном потоке новых проектов и годится для большой компании. Здесь, как при сборке на конвейере, алгоритмисты быстро «надевают» требуемые конструкции на уже имеющийся у компании «скелет», составленный из внутренних технологий. Схему «рост с проектом» выбирают на начальном этапе развития компании, когда штат её ограничен, либо при работе над большим/долгосрочным/защищённым проектом (например, компьютерная игра, банковское решение), когда группу «привязывают» к проекту и она «растёт» вместе с ним, чтобы максимально полно/точно учитывать все детали/специфику проекта.
В схеме «рост с проектом» людской ресурс ограничен, поэтому нагружать алгоритмистов знанием нюансов редко пользуемых и мусорных технологий – неразумно. Здесь применяют метод «создал и забыл»: редко пользуемые участки программы – низкоуровневая обработка (GUI/сеть/DB), API движков, корявые системные и иные API, – оборачиваются обёртками и о них «забывают».
Уровень алгоритмиста
Задача алгоритмиста: взять изложенный в доступной форме алгоритм и переложить его на язык программирования. Алгоритмист должен получить на руки распечатанный перечень технологий/классов/правил, которые он должен выучить/пользовать.
Членение и распараллеливание
Алгоритмист не должен решать, что следует членить/распараллеливать/оптимизировать, что нет. Это должно быть задано архитектурой и правилами написания продукта. Распараллеливание/членение/оптимизация чего-либо: уровень и задача архитектора.
Организация модульности продукта/кода, распределенные/многопоточные конструкции, разбивка кода по уровням (слои realtime/runtime/threadsafe/readonly в программе) – примеры членения. Разбивка задачи между исполнителями – так же пример членения; алгоритмист не обучен заниматься членением.
Однако алгоритмист, в процессе своей работы, обязан сообщать архитектору, что по его мнению следует членить/распараллеливать/оптимизировать.
Мусорные технологии (junk technologies)
IT-индустрией накоплено огромное количество спецификаций/ технологий/API/платформ не удобных ни пользователю, ни разработчику, появление и распространение которых обязано исключительно вливанию денег IT-гигантами в их рекламу/насаждение.
«Наблюдай за тем, что скапливается, чтобы узнать, что придет: счастье или беда» (трактат Ян Чжу, V в. до нашей эры).
Когда крупные корпорации начинают вливать хорошие деньги в пиар «новой технологии» или что-нибудь входит в моду, это значит, к разработчикам вскоре потянутся ручейки клиентов, с заказами по данной тематике. Поэтому пора набирать соответствующих специалистов. Переучивать своих специалистов обычно никто не торопится, ибо мода может пройти, технология может оказаться невостребованной или провальной, но, пользуясь конъюнктурой, деньги на волне её популярности, снять с рынка, конечно, следует.
Уровень маркетолога и тюнинговщиков
Задача маркетолога: придать продукту/технологии тот вид, чтобы «клиент был доволен». Тюнинговщики владеют «новыми», «последними», «модными» технологиями. Их задача: безболезненно для продукта внести те бесполезные «нововведения», что добавляются из соображений маркетинга, или которые обязательно требует заказчик. Бывает, в процессе своей работы тюнинговщики натыкаются на действительно полезные (технологические) нововведения, о чём сообщают архитектору. Тюнинговщиков обычно набирают из любознательных студентов, самостоятельно изучивших «последние», «новые» а, значит, не проверенные временем, не устоявшиеся технологии.
Уровень архитектора
Архитектор работает одновременно со всеми перечисленными специалистами:
1. выбирает/складывает внутренние технологии
2. управляет сложностью проекта
- (выбор технологий;
- членение/сопряжение частей программы;
- развёртка структур;
- развёртка и увязка GUI/logic/server/hardware движков между собой;
- декларация API;
- локализация сложности созданием обёрток над API/технологиями/кодом;
- разнесение тела программы по уровням (слои realtime/runtime/threadsafe/readonly в программе);
- оптимизация, разнесение/балансировка нагрузки (втч. клиент/сервер);
- итд.)
3. складывает кастомные языки; полно/точно подгоняет проект под нужды заказчика. Не просите архитектора писать «пузырьковую сортировку», перечислять аббревиатуры «EJB-компонент» или мусорных технологий; его голова должна быть занята другим.
У алгоритмиста можно спросить «какие библиотеки ты пользуешь?» (и здесь правильный ответ: «какие укажут»), знакомство же с архитектором начинается с вопросов, касающихся архитектуры проекта (узлы/субсистемы/уровни/обёртки) и junk технологий/кода («какие библиотеки/технологии/стандарты не следует пользовать? если они есть, как их локализовать? как бороться с избыточностью технологий/кода?»).
Так же вопрос «какие языки/инструменты ты пользуешь?» на уровне архитектора – некорректен; задача архитектора разрабатывать (кастомные) языки/инструменты в связи с поставленной задачей.
Универсальная платформа для всех случаев. Кастомные языки. Скриптовые процессоры
Если мы пишем ПО для управления механикой станка, аркадную игру, соцсеть, то очевидно, что не может быть «универсальной платформы для всех случаев». Не может быть «универсальной платформы» даже в пределах решений WEB-сегмента.
Чтобы полно/точно охватить решаемую задачу, требуются написание полно/точно охватывающих его схем (алгоритмов).
На определённом этапе роста/сложности проекта, чтобы избежать дублирования кода и упростить процесс разработки/поддержки/масштабирования приложения, алгоритмы следует оборачивать оболочкой кастомных языков, выполняющихся на программных скриптовых процессорах.