Подходы к разработке нового функционала

В этой записи я скорее всего не скажу чего-то нового. Это будут довольно простые и очевидные вещи. Но я уже упоминал тот факт, что порой самые простые вещи иногда упускаются из виду. И то, что довольно очевидно, иногда не получает должного внимания именно из-за того, что оно считается само собой разумеющимся.

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

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

Теперь, наконец-то, перейдём к описанию этих самых подходов.

  1. Новый код пишется на основе уже готового функционала. Разработчик не меняет архитектуру и взаимодействие внутри уже готового проекта, а лишь «внедряет» свой код и связывает его работу с текущим, внося минимум необходимых изменений и доработок. Возьмём, к примеру, интеграцию нового способа оплаты в систему, в которой уже есть несколько таких работающих методов. Новый функционал внедряется на основе уже работающих платёжных методов, используется тот же самый подход (или максимально приближенный) и не изменяется взаимодействие уже существующих механизмов. Т.е. проще говоря «делается как уже было сделано».
  2. Новый код пишется с упором на улучшение и изменение архитектуры, если это видится необходимым, но без добавления новых подразделов и глобальных объектов (классов). Допускается изменение взаимодействия внутри системы, но без затрагивания чего-то глобального. Если опять взять в пример интеграцию нового способа оплаты, то можно дорабатывать что-то под текущую разработку, но не менять общий подход. Т.е. что-то среднее между первым и третьим вариантом.
  3. Новый код пишется без оглядки на существующую архитектуру. У разработчика полная свобода действий, но его решения должны только улучшать общую концепцию и упрощать разработку в будущем. Если текущая реализация плоха, то можно делать полный рефакторинг и вносить любые разумные изменения. Снова возьмём в пример интеграцию нового способа оплаты. В этом случае можно переделать всё так, что добавление в будущем ещё одного способа оплаты будет уже довольно простым и очевидным.

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

Второй подход хорош тогда, когда программист может сделать хорошие изменения, но важно понимать, что сейчас разумно это делать. Потому что часто инициатива наказуема. В этом случае важно узнать заранее, насколько глубоко нужно погрузиться в разработку.

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