Оценка эффективности разработчиков по коммитам действительно довольно спорный подход. Автор в общем-то это подчеркнул неоднократно в самой статье. Поэтому комментарии про "KPI для разработчиков" не в тему. Любой инструмент (и даже технологию) можно использовать правильно и неправильно, продуктивно и не очень, во благо или назло))
С подобными инструментами я начал работать несколько лет назад. Я использовал https://github.com/tomgi/git_stats (кстати при установке возникала какая-то ошибка и нужно было залезать в исходники, чтобы исправить какую-то одну строку, но это мелочи))
Моя идея была в следующем: периодически (мы делали раз в год -- перед НГ) собирать статистику и на общей встрече разбирать её. В этом я кстати не согласен с автором, что мол лучше особенно не показывать, что есть такой инструмент для анализа. Так вот на общекомандной встрече мы смотрели как мы работаем с точки зрения гита -- кто во сколько коммитит (это очень прикольно, потому что у кого-то это чётко с 08:00 до 17:00 и перерывом на обед, а у кого-то наоборот с 12:00 и до поздней ночи), какой день и час недели самые насыщенные коммитами, кто какие комментарии к комитам пишет. В общем это весёлое и приятное мероприятие для команды, не рядовое ретро с "давайте выпишем n проблем на стикеры и приклеим их к доске"))
Если говорить шире, то у такого инструмента точно есть польза, я могу отметить следующие возможности:
Выявление тенденций. Например, если один и тот же человек раньше коммитил много, а потом стал мало, значит что‑то изменилось. Если у тимлида есть время разбираться, есть регулярные встречи 1:1, то такая информация может быть полезной для выявления проблем (выгорание, наличие второго места работы и т. д.).
Повышение качества коммитов. Я имею в виду не содержимое с точки зрения кода, а стиль создания коммитов (1000 изменений в одном коммите или разбиение на логические части) и комментариев к ним. Когда собирается статистика за большой промежуток времени, становится видно как в целом команда работает с VCS. О пользе дробных коммитов и красивых комментариев некоторые могут поспорить, но я думаю, что единый стиль и информативность точно не могут вредить. А единственная причина, по которой многие разработчики пишут комментарии в духе fix bugs, add file — это довольно низкий уровень самодисциплины, лень. Так вот, инструмент, который наглядно использует эту информацию, может добавить мотивации работать с коммитами более осознанно.
Мотивация. В дополнение к предыдущему пункту. Для новичков в команде полезно видеть, что более опытные разработчики много (и/или структурированно) коммитят, работают с кодом. Может и не для всех, но для многих это стимул тоже вкладывать больше усилий в работу над проектом.
В общем желаю автору положительной кармы, а инструменту развития! Точно буду использовать в будущем.
P.S. Видимо нужно красными большими буквами в начале написать "Это не инструмент для оценки KPI разработчиков"))
Сразу же хочется применить где-то или написать что-то своё. В общем сообщения о релизах всегда побуждают к действию и работе! =) Отличная статья для понедельника, спасибо!
Спасибо за пояснение!
Стал абсолютно понятен механизм разделения потока на части. В принципе это можно увидеть и в примере из статьи, но я сначала не обратил внимания.
CSS Exclusions — очень мощный инструмент. Правда, насколько я понимаю, браузерами он пока не поддерживается.
Спасибо, интересная статья, было приятно почитать.
Интересно, почему column-span может принимать только значения none или all, а не число. Например, если текст разбит на пять колонок, а какой-то фрагмент (цитату) хочется выделить и поместить на ширину двух колонок, то так сделать не получится?
>>через браузер или через stand-alone клиент для Maca и Windows
Хотелось бы увидеть именно «настольный» клиент =)
У меня такое ощущение, что его либо и не было вовсе, либо был, но при релизе сервиса в клиенте обнаружились проблемы, и его убрали с сайта, отправив на доработку.
Это тоже была отличная штука! Можно было дополнительно использовать электромотрчики от сломанных или специально разобранных игрушек)) Мои машинки ездили самостоятельно))) только вот с аккумуляторами была проблема — у меня лично их вообще не было, приходилось использовать батарейки, которые постоянно разряжались и приходилось просить родителей покупать новые =)
А по основной теме — отличный подарок в любом возрасте! Даже не думал, что такое бывает, если честно) Запрограммировать на Питоне робота, который будет раз в час проезжать по столу с табличкой «Сделай перерыв! Позвони любимой!»)))
Мне новый сервис Амазона больше напомнил CloudApp. Веб-интерфес похож и даже логотип немного. Но CloudApp рассчитан исключительно на маленькие файлы, конечно.
Оценка эффективности разработчиков по коммитам действительно довольно спорный подход. Автор в общем-то это подчеркнул неоднократно в самой статье. Поэтому комментарии про "KPI для разработчиков" не в тему. Любой инструмент (и даже технологию) можно использовать правильно и неправильно, продуктивно и не очень, во благо или назло))
С подобными инструментами я начал работать несколько лет назад. Я использовал https://github.com/tomgi/git_stats (кстати при установке возникала какая-то ошибка и нужно было залезать в исходники, чтобы исправить какую-то одну строку, но это мелочи))
Моя идея была в следующем: периодически (мы делали раз в год -- перед НГ) собирать статистику и на общей встрече разбирать её. В этом я кстати не согласен с автором, что мол лучше особенно не показывать, что есть такой инструмент для анализа. Так вот на общекомандной встрече мы смотрели как мы работаем с точки зрения гита -- кто во сколько коммитит (это очень прикольно, потому что у кого-то это чётко с 08:00 до 17:00 и перерывом на обед, а у кого-то наоборот с 12:00 и до поздней ночи), какой день и час недели самые насыщенные коммитами, кто какие комментарии к комитам пишет. В общем это весёлое и приятное мероприятие для команды, не рядовое ретро с "давайте выпишем n проблем на стикеры и приклеим их к доске"))
Если говорить шире, то у такого инструмента точно есть польза, я могу отметить следующие возможности:
Выявление тенденций. Например, если один и тот же человек раньше коммитил много, а потом стал мало, значит что‑то изменилось. Если у тимлида есть время разбираться, есть регулярные встречи 1:1, то такая информация может быть полезной для выявления проблем (выгорание, наличие второго места работы и т. д.).
Повышение качества коммитов. Я имею в виду не содержимое с точки зрения кода, а стиль создания коммитов (1000 изменений в одном коммите или разбиение на логические части) и комментариев к ним. Когда собирается статистика за большой промежуток времени, становится видно как в целом команда работает с VCS. О пользе дробных коммитов и красивых комментариев некоторые могут поспорить, но я думаю, что единый стиль и информативность точно не могут вредить. А единственная причина, по которой многие разработчики пишут комментарии в духе
fix bugs,add file— это довольно низкий уровень самодисциплины, лень. Так вот, инструмент, который наглядно использует эту информацию, может добавить мотивации работать с коммитами более осознанно.Мотивация. В дополнение к предыдущему пункту. Для новичков в команде полезно видеть, что более опытные разработчики много (и/или структурированно) коммитят, работают с кодом. Может и не для всех, но для многих это стимул тоже вкладывать больше усилий в работу над проектом.
В общем желаю автору положительной кармы, а инструменту развития! Точно буду использовать в будущем.
P.S. Видимо нужно красными большими буквами в начале написать "Это не инструмент для оценки KPI разработчиков"))
Стал абсолютно понятен механизм разделения потока на части. В принципе это можно увидеть и в примере из статьи, но я сначала не обратил внимания.
CSS Exclusions — очень мощный инструмент. Правда, насколько я понимаю, браузерами он пока не поддерживается.
Интересно, почему
column-spanможет принимать только значенияnoneилиall, а не число. Например, если текст разбит на пять колонок, а какой-то фрагмент (цитату) хочется выделить и поместить на ширину двух колонок, то так сделать не получится?Хотелось бы увидеть именно «настольный» клиент =)
У меня такое ощущение, что его либо и не было вовсе, либо был, но при релизе сервиса в клиенте обнаружились проблемы, и его убрали с сайта, отправив на доработку.
А по основной теме — отличный подарок в любом возрасте! Даже не думал, что такое бывает, если честно) Запрограммировать на Питоне робота, который будет раз в час проезжать по столу с табличкой «Сделай перерыв! Позвони любимой!»)))