Я сейчас работаю во фронтенд команде одного проекта, где в одном нашем фронтовом репозитории каждый день пишут код больше 25 человек, каждый день собираются и катаются релизы. И этот проект живет уже не один год. И у нас есть архитектура, методологии, абстракции, юнит тесты, функциональные тесты, статическая типизация и т.д.
Вы знаете, как в таких условиях без этого всего годами поддерживать код на таком уровне, чтобы я мог легко поправить что-нибудь в той части, где код писался полтора года назад неизвестно кем, и быть абсолютно уверенным, что я нигде ничего не сломал при этом?
Опытные команды отличаются тем, что они вполне бывает, что пишут говнокод, но держат этот говнокод под контролем.
Практически всегда некий огромный проект можно разбить на много маленьких кусков, у каждого из которых своя зона ответственности. Каждый из маленьких кусков в свою очередь делится на еще несколько маленьких кусков, и так далее. И опытные разработчики, когда видят задачу, не ломятся сразу херачить код, а сначала внимательно подумывают, как можно эту задачу декомпозировать на части, так чтобы каждая из частей получилась небольшой, а взаимодействие между ними было максимально простым.
И вот у нас получается побитый на модули проект, и модули как-то между собой взаимодействуют (и это не обязательно микросервисы, в монолите код тоже можно побить на модули). И тут стоит уделить внимание именно формату взаимодействия, сделать его максимально продуманным и удобным с учетом возможных хотелок в будущем.
Дальше начинаем писать эти модули, и вот тут бизнесу может потребоваться выпустить продукт побыстрее, чем мы это сделаем, если будем писать весь код максимально качественно. Что делать? Бывают ситуации, когда некоторые не самые важные модули можно сделать из говна и палок на основе готовых решений очень быстро — делаем так. Иногда бывает такое, что мы не уверены, а нужен ли нам какой-то конкретный функционал, и если нужен, то в каком виде, нет определенности, или мы просто хотим провести какой-то эксперимент. Тут нет смысла писать максимально качественно, можно не покрывать тестами. В будущем требования могут измениться, или вообще мы поймем что этим никто не пользуется и выкинем. Какие-то критически важные модули всегда пишутся максимально качественно, покрываются тестами, на них не экономим.
Ну и конечно эти все решения принимаются в обсуждении с бизнесом. Мы рассказываем бизнесу, что вот тут мы сейчас идем на компромисс ради скорости, но у нас копится техдолг, сейчас мы сделаем по-простому, но если мы захотим в дальнейшем развивать эту часть, то нам нужно будет дополнительное время, чтобы этот техдолг разгрести.
И если вот так гибко лавировать между качеством и скоростью, то у нас получается, что где-то код написан качественно, где-то нет, но мы это все держим под контролем и не скатываемся в ситуацию, когда у нас весь сервис — куча говна, в которой никто уже не может нормально ориентироваться.
Вы знаете, как в таких условиях без этого всего годами поддерживать код на таком уровне, чтобы я мог легко поправить что-нибудь в той части, где код писался полтора года назад неизвестно кем, и быть абсолютно уверенным, что я нигде ничего не сломал при этом?
Практически всегда некий огромный проект можно разбить на много маленьких кусков, у каждого из которых своя зона ответственности. Каждый из маленьких кусков в свою очередь делится на еще несколько маленьких кусков, и так далее. И опытные разработчики, когда видят задачу, не ломятся сразу херачить код, а сначала внимательно подумывают, как можно эту задачу декомпозировать на части, так чтобы каждая из частей получилась небольшой, а взаимодействие между ними было максимально простым.
И вот у нас получается побитый на модули проект, и модули как-то между собой взаимодействуют (и это не обязательно микросервисы, в монолите код тоже можно побить на модули). И тут стоит уделить внимание именно формату взаимодействия, сделать его максимально продуманным и удобным с учетом возможных хотелок в будущем.
Дальше начинаем писать эти модули, и вот тут бизнесу может потребоваться выпустить продукт побыстрее, чем мы это сделаем, если будем писать весь код максимально качественно. Что делать? Бывают ситуации, когда некоторые не самые важные модули можно сделать из говна и палок на основе готовых решений очень быстро — делаем так. Иногда бывает такое, что мы не уверены, а нужен ли нам какой-то конкретный функционал, и если нужен, то в каком виде, нет определенности, или мы просто хотим провести какой-то эксперимент. Тут нет смысла писать максимально качественно, можно не покрывать тестами. В будущем требования могут измениться, или вообще мы поймем что этим никто не пользуется и выкинем. Какие-то критически важные модули всегда пишутся максимально качественно, покрываются тестами, на них не экономим.
Ну и конечно эти все решения принимаются в обсуждении с бизнесом. Мы рассказываем бизнесу, что вот тут мы сейчас идем на компромисс ради скорости, но у нас копится техдолг, сейчас мы сделаем по-простому, но если мы захотим в дальнейшем развивать эту часть, то нам нужно будет дополнительное время, чтобы этот техдолг разгрести.
И если вот так гибко лавировать между качеством и скоростью, то у нас получается, что где-то код написан качественно, где-то нет, но мы это все держим под контролем и не скатываемся в ситуацию, когда у нас весь сервис — куча говна, в которой никто уже не может нормально ориентироваться.