Принципы SRP и IoC в мире менеджмента разработки ПО

Одна из основных задач в разработке программного обеспечения — это управление сложностью. Зачастую технические специалисты помнят про техническую сложность, но забывают о сложности в процессах. В этой статье я хотел поговорить про SRP или Принцип Единственной Ответственности (Single Responsibility Principle) и IoC или Инверсия Управления (Inversion of Control) в приложении к менеджерским вопросам. Для упрощения я буду приводить примеры из программирования, которые близки и понятны всем прошедшим огонь, воду и медные трубы современной разработки ПО.

Картинка с главным вопросом

Скучное вступление закончено, а теперь перейдем к простым примерам:) Пожалуй, начнем с того, что попроще, а именно с SRP.

Принцип единственной ответственности

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

Рассмотрим на пальцах что это значит. Представим, что у нас есть класс Developer, который судя по названию умеет программировать и если повезет писать unit-тесты. Этот класс инстанцирован в контесте системы Startup (дальше по тексту просто стартап). В этом стартапе данному инстансу программиста навешивают дополнительные обязанности в виде сбора требований, поддержки инфраструктуры, починки принтера и даже чайника, аргументируя это тем, что “Ты ж программист”:) В итоге, получим такую диаграмму классов

Схема 1: Многрукий Шива

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

Какие проблемы в этой схеме:

  • низкая эффективность сотрудника в каждой из областей деятельности — крайне сложно прокачаться в каждой из сфер ответственности и переключения контекстов понижают производительность еще больше
  • низкая эффективность процессов в компании в общем — во многих процессах участвует наш Developer, что приводит к задержкам, если он занят побочной деятельностью в другом процессе
  • сложно искать новых сотрудников — не каждый согласится быть многоруким шивой, которому приходится делать так много

В программировании в таком случае пытаются декомпозировать обязанности класса по связанным областям и вынести их отдельно. Давайте и мы попробуем помочь нашему Developer’у:

  • задачи по замене бумаги и починке чайников отдадим специалисту из административно-хозяйственного отдела
  • задачи по поддержке инфраструктуры отдадим системным инженерам
  • задачи по написанию кода и тестов оставим у разработчика, плюс добавим метод forwardTask, чтобы Developer мог указывать направление куда идти с задачами по починке чайников:)
Схема 2: Отдельные специалисты

В этой схеме мы решаем те проблемы, которые мы выделили в Cхеме 1. Теперь стоит перейти ко второй части, а именно к IoC.

Инверсия управления

Inversion of Control — это важный принцип объектно-ориентированного программирования, используемый для уменьшения coupling между составными частями ПО. Также IoC является архитектурным решением, упрощающим расширение возможностей системы, при котором поток управления программы контролируется фреймворком.

Рассмотрим на пальцах что это значит. Для этого рассмотрим тот же стартап и того же Developer’а. Но так как в этот раз у нас речь про управление, то в эту схему добавится его руководитель, который стоял у основ компании и занял в свое время должность CTO. Так как компания маленькая, то задачи разработчикам ставит напрямую CTO. Если рассматривать подробнее их взаимодействие, то:

  • CTO ставит задачи Developer’у
  • CTO добавляет к задаче инструкции как именно ее стоит делать
  • Developer отправляет готовые задачи на приемку CTO
Схема 3: стиль управления “микроменеджмент”

В данной схеме есть несколько проблем:

  • с точки зрения CTO — повышенные требования к CTO, т.к. он должен не просто сказать что надо сделать, но и объяснить как
  • с точки зрения Developer’а — отсутствие возможности роста, решая задачи самостоятельно + скука, а дальше потенциальное увольнение
  • с точки зрения эффективности системы — 1) эффективность системы ограничена бутылочным горлышком в виде CTO; 2) система не улучшается, т.к. все точки роста закрыты топ-менеджером; 3) сложность системы ограничена размером головы руководителя:)

Как с этим всем нам поможет IoC? Легко. CTO должен транслировать не инструкции к задачам, а некоторые руководящие принципы, я назову их архитектурными. Эти принципы и подходы должны быть согласованы с командой. В итоге, когда CTO будет ставить задачи, то его подчиненные будут их выполнять с учетом принципов, о которых они договорились заранее. Итоговая диаграмма выглядит следующим образом

Схема 4: стиль управления «менеджмент “здорового человека”»

Здесь:

  • CTO договаривается с разработчиком о некоторых архитектурных принципах
  • ставит задачи Developer’у
  • разработчик берет задачи и делает их в соответствии с архитектурными договоренностями
  • а дальше он передает их на проверку CTO

Из этой схемы видно, что мы инвертировали направление управления. Теперь CTO вместо того, чтобы заниматься микроменеджментом может задать общие правила решения задач и дальше позволить своей команде самостоятельно наступать на грабли и расти над собой:)

Итог

В этой статье я рассказал о совсем очевидных вещах в управлении людьми и том, как эти принципы отображаются на основные 2 принципа из SOLID (SRP и DI), если рассматривать Dependency Inversion как некоторый механизм IoC. Продолжение доступно в статье Подходы оркестровки и хореографии в мире менеджмента разработки ПО.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.

Director of digital ecosystem development department at Tinkoff. Bachelor at applied math, Master at system analysis, Postgraduate studies at economics.