Должен ли на продакшене быть идеальный код

Сегодня я хочу поговорить на тему идеального кода на продакшене, когда это важно и можно ли без этого обойтись. Начну с начала. Мое мнение относительно этого вопроса менялось по ходу роста моих навыков и смены должностей. Когда я только начинал разработчиком, мне нужно было делать кучу задач под разные проекты и платформы, которые были нужны на недолгий срок. Я опробовал много языков и платформ, особо в качество упирать естественно не было возможностей, да и понимания, где оно, это качество, не было.Начав разрабатывать долгоживующие проекты, я понял, что очень важно писать их удобно для сопровождения и отладки. А частые правки от бизнеса приучили, что без тестов делать большие смены курса проекта или большой рефакторинг себе дороже.

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

Став СТО, я пришел к выводу, что в повседневной работе нужно всегда отстаивать сроки на разработку качественной фичи (обязательна правильная архитектура и наличие тестов), компромис в коде можно согласовать, если после запуска фичи сразу берется рефакторинг. Но, как правило, любой компромис останется вашим вечным техническим долгом.

Как же быть с проектами, которые нужно просто попробовать или фичами, с которыми нужно лишь протестировать взлетят они или нет? Если вы встраиваете фичу в большой проект, где поверх вашей фичи уже будут писаться другие, то тут без вариантов, качество должно соблюдаться на каждой фиче. Если это проект на попробовать, то у вас два варианта: пишите так, чтобы можно было отрефакторить в случае успеха или пишете с нуля, если выяснили, что проект взлетит. Это надо четко понимать, я видел много проектов, стартовавших как попробовать и потом развивающихся поверх этого кода многие годы. Работать с этим мягко говоря сложно, предсказуемость работы отсутствует. Поэтому если вы понимаете, что времени на исправление не будет, делайте хорошо сразу, если время будет, то я выбираю вариант с рефакторингом (при условии, что проект делается с запасом по нагрузке х2 и будет без огрехов выполнять заказанный функционал).

Добавить комментарий