Как запускать проекты без жиры и прочей скукотени: вот наши главные принципы
В этой заметке мы расскажем о принципах, на которых построили разработку в UIG, платформы для кибертурниров. Надеемся, статья будет полезна основателям и техническим директорам ИТ-стартапов, особенно тем, кто не идет к аутсорсерам.
А как хранятся требования к продукту, если ТЗ суть зло и заводить задачи скучно? Вот начинаем мы делать фичу №73 через год, а она, вроде, косвенно начинает влиять на фичу №14 сделанную где-то на старте. Как это разрулить без чётко прописанного требования? Собрались обсуждать и сообразить как эти фичи должны работать вместе, но вот помнят все первую фичу по разному, ибо её потом ещё патчили пару раз и дорабатывали... как тут быть?
Не подумайте, вопрос не из разряда докопаться, правда интересно как при таком быстром и легком старте решаются такие вот проблемы потом.
Короткий ответ: тестами! Если ты сломаешь предыдущую фичу - то узнаешь от этом в своём CI. Не все можно покрыть тестами, конечно.
Но положа руку на сердце - я редко видел, чтобы можно было открыть жиру и быстро понять, какое текущее состояние системы. В лучшем случае ты получишь changelog, который нужно восстановить по десятку ишью и двум десяткам багов, проиграв их все последовательно в голове. Можно поставить цель содержать полное состояние системы где-то в документации, но я видел такое только в оборонке и в космосе. Медицина - уже нет.
Поэтому, лучше тестов для этого, кажется, человечество ещё ничего не изобрело.