опубликовано: 06.11.2018
В книге Clean Architecture мне попалась интересная метричка. Там говориться, что основная задача архитектуры приложения это легкое внесение изменений. Т.е. чем проще нам добавить/исправить фичу, тем круче.
Есть способ это измерить: считаем кол-во новых строк кода, считаем стоимость разработки, строим графичек стомости добавления одной строчки кода в прилжение. Если от релиза к релизу стоимость одной строки кода растет, значит с архитектурой все плохо. Если от релиза к релизу стоимость добавления одной строчки кода стабильна или даже уменьшатся, все отлично 👍
Метричка выглядит круто, надо где-нибудь ее опробовать. Пока вижу с ней только одну проблему. Нужно донести до менеджмента, что по этой метрике можно понять только качество архитектуры приложения, но никак не эффективность команды. Если начать смотреть на эту метрику как на метрику эффективности, то мы подтолкнем разработчиков к манипулированию метрикой ради спасения себя, а не улучшения продукта, и все пойдет коду под хвост(
В общем, пробуйте метричку, рассказывайте как оно)
Обсудили с @Mustafin метричку архитектуры, что упоминалась выше. Пришли к тому, что нужно мерить не от релиза к релизу, а за какой-то промежуток времени. Релизы могут выходить с разной частотой, все время разных размеров. Какой-то релиз мы делали два дня, какой-то неделю и в таких условиях метрика не покажет нам абсолютно ничего.
Поэтому имеет смысл брать метричку за промежуток времени. Например, кол-во строк за спринт, месяц и т.д.
Я консультирую о том о чем пишу, связаться со мной можно через telegram @aladmit или по почте [email protected]