SkyXEngine 0.9.3. Процесс разработки

21.11.2017 мы выпустили новую версию нашего движка SkyXEngine 0.9.3. Процесс разработки новой версии привнес много изменений в проект, было совершено много ошибок ведения проекта. В данной статье поговорим именно об этом)

Синхронизация разработки

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

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

А  в чем причина асинхронности? В какой-то момент времени один из нас не успевал сделать то что мы задумали, а другой не мог ждать пока тот доделает и брался за другую задачу в ожидании окончания предыдущей. Все просто, надо просто проявлять терпение, либо браться за мелкие задачи, реализация которых не займет много времени, и по ее завершении может наступить момент синхронизации.

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

  • если невозможно синхронизироваться то необходимо разделять работу чтобы синхронизация не требовалась
  • браться за мелкие задачи, которые можно быстро осуществить, пока другой подходит к синхронизации
  • браться за рефакторинг, он всегда нужен
  • проявлять терпение, отдыхать)

Синхронизация результатов работы

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

Решили что надо коммитится как можно чаще, пусть изменения несущественны, но зато проблем со слияние меньше. Однако нам редко удавалось соблюдать данные правило, будем работать над этим)

Также синхронизации игровых ресурсов отнимала достаточно времени, репозитория игровыч ресурсов нет. Как быть в данном случае мы еще толком не придумали, поэтому этот пункт в разработке)

Стандарта оформления кода

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

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

Ссылка на стандарт оформления кода.

План работы, ограниченное время

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

Из-за отсутствия четкого плана, мы брались за иные задачи, процесс разработки затягивался. А отсутствие плана, который рассчитан на определенный промежуток времени, серьезно ударил по нашему энтузиазму: мы делаем, делаем, а версия еще не готова(

В итоге мы решили ставить небольшие задачи как по объему так и по количеству на разработку текущей версии, выставляя при этом приемлемый график.

Документация, руководства

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

Ситуация такая, одному из нас пришлось взяться за недокументированный модуль другого, а этот другой занимался синхронизацией, то есть у него крайне мало времени на объяснения))

Подходя к моменту выпуска, мы начали понимать что нам не хватает руководств по движку, нет какого-то неизменного фундамента, на котором уже можно было бы продолжать воздвигать наш движок. Мы поняли, что на первую версию движка уже необходимо создавать некие основы, которые были бы неизменными до версии 1.0. Чтобы пользователи могли уже использовать наш движок, а мы смогли увидеть некую общую абстрактную картину движка, чтобы выявить дальнейший вектор его развития.

В итоге решили постепенно к этому подойти, за несколько версий)

Отдых

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

Решили завести блоги, чтобы было где отдыхать с пользой))


Разработка SkyXEngine 0.9.3 была очень тяжелой, но поучительной, думаю мы применим полученный нами опыт ведения проектов при разработке 0.9.4 в полной мере))

Поделиться:

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

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

*

code