Тема дня №15 по разработке программного обеспечения
Примечание. Первоначально это было написано и опубликовано на внутреннем Armakuni Slack мной.
Ранее мы говорили о том, как описывать ваши коммиты и куда ваши коммиты должны идти, но что в них должно быть?
Чтобы объяснить, что должно быть в коммите, мне нужно познакомить вас с идеей: Bit Rot. Bit Rot — это идея о том, что со временем код приходит в негодность независимо от того, что вы делаете. Bit Rot может быть реальной и физической вещью; жесткие диски служат только где-то между 3 и 5 годами. Bit Rot существует и в более социальной форме: разработчики библиотек выпускают библиотеки с изменениями, которые ломают ваш код, кто-то рядом с вами может изменить нужный вам интерфейс. Программный код всегда умирает, гниет.
Когда вы не вставляете код в master, это особенно верно, потому что вместо того, чтобы все видели, что от чего зависит, вы должны сидеть там и исправлять нарушения, которые сделали все остальные. Когда вы что-то переделываете, вы создаете отходы. Мы хотим избежать этого.
Так какой именно оптимальный размер для нажатия?
У нас есть одно ограничение — наша система контроля версий; git bisect предполагает, что каждое изменение, по крайней мере, не нарушит наши автоматические тесты. Мы также переходим к производству с нашими изменениями, поэтому нам не нужно нарушать это.
Тем не менее, это все еще оставляет нам довольно широкое игровое поле. Посмотрим на науку.
Исследование изучало эффективность рецензирования при разработке программного обеспечения, которое они извлекали из репозиториев с открытым исходным кодом. Они обнаружили, что строки кода в изменении увеличивают время, необходимое для понимания и проверки кода кем-то другим. Хотя мы не используем экспертную оценку вне запроса на парное программирование, полученные результаты очень важны.
Исследование показало, что точка отсечки составляет 3KLOC (3000 строк кода), прежде чем люди полностью разочаруются в обзоре и скажут: да, это, вероятно, нормально. Самый высокий комментарий к плотности строк составлял около 20 строк кода на одно изменение.
Мы должны фиксировать, когда у нас есть около 20 строк полной работы, которая не нарушит производство или сборку.
Как флаги функций могут увеличить частоту фиксации?
Как вы работаете с автоматизированными инструментами, которые вносят большое количество изменений?
Что такое TCR?
