Оригінальна стаття https://docs.mineland.net/docs/lokha/evolution-dev/ 31.07.2021
Хочу поделиться одним моим открытием. Это касается методологии разработки.
Возможно, это уже кто-то придумал до меня, но мне как-то пофиг.
Проблема
Кто-то придумал идею для обновы, и всем эта идея понравилась.
Обнова меняет механики игры. А чтобы идеально сделать эту обнову, было бы
неплохо сделать также фичи A, B и C, сделаем их тоже!
Во время разработки выясняется,
что текущая кодовая база плохо подходит для правок,
по этому надо сначала сделать рефакторинг, делаем.
Разработка затянулась на неделю, месяц, год.
За это время в других ветках тоже менялся этот код,
теперь надо будет делать merge, выбора нет.
Из-за крупных изменений кода возникли баги,
на которые также придется тратить время.
А некоторые баги также требуют рефакторинга.
Наконец, мы релизнули обнову. И тут выясняется,
что игрокам она не нравится, онлайн упал или не изменился.
Что же не нравится игрокам? Сама обнова? Какая либо из фич A, B или C?
Результат рефакторинга? Результат merge? Или новые баги?
Часть изменений может оказывать положительный эффект, а часть отрицательный.
Но мы этого знать не можем. Мы лишь можем наблюдать усредненный эффект.
Из-за невозможности определить причину неудачи придется отменять всю обнову целиком.
Подытожим список проблем:
- Долгое время разработки.
- Баги.
- Большие риски неудачи.
- Невозможность определить причины неудачи.
- Длительная окупаемость.
Решение
Биологическая эволюция
Вспомним, как работает биологическая эволюция.
Организм с каждым поколением немножко меняются.
В перспективе множества поколений это позволяет сильно изменить организм, сделать его лучше.
Но также это одновременно накладывает ограничения.
Вряд ли у собак могут образоваться крылья, ведь для этого нет эволюционной базы.
А за одно поколение появление рабочих крыльев - невозможно.
Чтобы все же крылья у собак появились, нужно много поколений.
И на каждом из этих поколений промежуточные крылья должны приносить пользу
или хотя бы не приносить вреда.
Эволюционная разработка
Эволюционный принцип можно применить как методологию разработки.
Любой функционал на mineland - это живой организм.
Изменение кода функционала - это новое поколение.
У поколений должны быть рамки по времени, размеру и характеру изменений.
В биологии эти рамки определяются своими законами. А нам их нужно придумать.
Я предлагаю следующее. Поколение не должно длиться более недели.
За одно поколение должно быть только одно логическое изменение.
Запрещено делать расчет наперед, изменение должны окупаться сразу,
а не через несколько поколений. Изменения должны быть минимальны.
Но как же тогда делать крупные обновы?
Так же, как это делает биологическая эволюция.
Нужно разбить обнову на несколько последовательных
поколений, каждое из которых должно окупаться.
А если разбить крупную обнову не получается?
Тогда от такой обновы стоит отказаться. Это значит,
что у нас нет кодовой базы для этого.
Это то же самое, что пытаться сделать крылья собаке.
Безопасного способа это сделать попросту нет.
Будет ли эволюционная разработка порождать костыли?
Да, будет. Но что такое костыль? Человек дает этому определение,
следовательно, это характеристика “от головы”.
Разделять решения нужно только на рабочие и нерабочие,
ничего более не существует. В природе полно “костылей”,
этим придется пренебречь.
Решает ли проблемы эволюционная разработка
Заявленные проблемы:
Долгое время разработки
Время разработки будет меньше за счет того,
что не будет требоваться совершать рефакторинг, merge, фиксить баги.
Проблемы будут обнаруживаться на промежуточных поколениях,
что также сэкономит общее время разработки.
Баги
Багов будет меньше за счет меньшего количества изменений.
Баги будут обнаруживаться на промежуточных поколениях,
что в целом сгладит процесс разработки.
Большие риски неудачи
Риски будут минимальны, с каждым поколением
будет видно, идем ли мы в правильном направлении.
Если идея обновления в целом провальна,
об этом станет известно на ранних этапах разработки.
Невозможность определить причины неудачи
С каждым поколением можно будет отслеживать изменения показателей роста.
Если после очередного поколения показатели упадут,
будет очевидна причина (последнее поколение).
Длительная окупаемость
Окупаемость начнется с первого же поколения, если идея обновы успешна в целом.
Создание нового функционала
Эволюция не про создание жизни, а про ее изменение.
Но тут тоже можно кое-что добавить.
Если появилась идея сделать новый функционал,
лучше всего будет его сделать в простейшем минимальном виде.
Это позволит сразу понять, успешна ли идея в целом.
А также это оставит свободу для эволюции функционала.
Не стоит создавать функционал,
который не будет успешен на ранних поколениях.