Уточню разбираемую мной ситуацию, дабы убедиться, что мы говорим об одном и том же.
Разработчик работает над фичей недельку и каждый день делает commit’ы, дабы не заморачиваться с backup’ами. Допустим, что у него получилось порядка 15 commit’ов в разные файлы и что один файл участвовал во всех 15 commit’ах, причём код в этом файле правился, добавлялся, удалялся, рефакторился.
После того, как разработчик посчитал, что закончил работу над функционалом, и готов представить результаты на инспекцию, он создаёт инспекцию и добавляет все ревизии, которые относятся к этой задаче.
Меня как инспектора интересует diff было-стало. Что там было посередине – для меня не интересно, слишком дорого.
Лично мы своей командой работали в trunk’e, но на каждую задачу создавали свою рабочую копию. Поэтому, когда коммитил изменения по одной задаче и переключался на другую, то всегда обновлял рабочую копию, чтобы все изменения объединились.
Если работая над задачей видел, что какой-то разрабатываемый функционал будет нужен мне в других задачах, то мог его разработку провести отдельной подзадачей. Такое, правда, случалось очень редко, т.к. в большинстве своём задачи в работе (как правило, не больше 3 задач) редко пересекаются кодовой базой. Поэтому мы решили, что такие единичные случаи нам дешевле обработать, проведя разработку общей части в рамках новой подзадачи (прямо в багтрекере разработчик заводил новую задачу, в рамках которой выполнялась разработка общего функционала).
Поэтому, когда я начинал инспекцию, мне было совсем не интересно, как там правил код автор, и пытаться понять, каким образом автор пришёл к конечному решению — слишком дорого, в моём понимании.
Мы проводили инспекцию итогового решения:
1) удовлетворяет ли оно предъявляемым требованиям;
2) достаточно ли use-case’ов покрывают unit-тесты;
3) проверить код на отсутствие логических дефектов (например, конфигурация прибора читается до начала работы с ним);
4) проверить на применение правильных идиом (те же shared_ptr, отсутствие утечки ресурсов и применение RAII);
5) проверить корректную обработку граничных условий и обработку и сигнализацию ошибок (exception/return value).
Резюмируя, не припомню, чтобы комментарии к коммитам как-то помогали мне на инспекциях. Unit-тесты и комментарии к ним – да, doxygen комментарии к функциям/классам – да, комментарии в коммитах – нет.
CC не умеет отслеживать переименование/перемещение файлов в SVN. Запрос на разработку этого функционала висит еще с 2008 года. Разработчики отмазываются ограничениями самого SVN.
Переименование/перемещение файла CC понимает как удаление старого и создание нового. Не совсем удобно.
Хотя такие ситуации возникают достаточно редко. У нас были заведены, например, шаблоны именования файлов.
С другой стороны, если файл разрастается, то в конечном итоге, он подвергается рефакторингу и делению на несколько файлов. Корректность copy-paste’а из старого файла в новый приходится отслеживать вручную.
Извините меня за долгий ответ, был в командировке с четверга.
Более подробно формализации use-case'ов инспекций кода у нас была посвящена предыдущая статья. В ней рассмотрены, в частности, межкомандные инспекции.
Этот пример я взял из личного опыта предыдущего проекта, и мне было просто удобно на нём продемонстрировать интерфейс CC.
На предыдущем проекте у меня часто были задачи поддержки какого-то нового оборудования. Например, нужно поддержать новый контроллер или прибор учёта какого-то производителя (например). В этом случае создавался каталог для этого счётчика и создавались файлы реализации логики конкретно этого прибора, которые потом попадали на инспекцию (мы вели разработку прямо в trunk’e). Мы создали очень хорошую объектную модель(что типа фреймворкa), у которой всё было разнесено по разным уровням абстракции, и для поддержки нового прибора чаще всего нужно было создать реализацию абстракций именно под этот конкретный прибор. Схема очень похожа на модель драйверов в ядре Linux'a. Там есть так называемый bus драйвер, ниже — драйвер контролера, ещё ниже — драйвер конкретной железяки. Добавление достаточно объёмных новых файлов у нас было нормальным явлением.
Заводилась одна большая задача, которая делилась на несколько небольших подзадач, по каждой подзадаче делались commit'ы и на каждую подзадачу создавалась отдельная инспекция. Деление проводилось по разным логическим единицам: поддержка чтения архивов, поддержка чтения журналов, поддержка чтения текущих значений и т.д.
Т.е. разработчик каждый день, когда хотел, коммитил свой код в репозиторий. Затем, когда приходило время инспекции, указывал все нужные ревизии в инспекцию.
Когда я инспектирую вновь добавленные файлы, в которые уже было сделано по несколько commit'ов, то хочу видеть последнее состояние файла без промежуточных изменений, которые для меня не интересны. Вот это как раз позволяет сделать СС автоматически.
Такой живой интерес к посту не может не радовать :-)
К сожалению, всю прошлую пятницу хабр оставался для нас недоступен. Видимо, корпоративный IP был зафильтрован в процессе масштабной борьбы с DDoS-атаками. Сейчас ситуация изменилась, и в ближайшее время предоставим вам автора ;-)
Еще раз, огромное спасибо за вопросы и комментарии!
Думаю, у вас очень дисциплинированная команда, очень похвально.
Напишу именно про себя и свой опыт.
Когда мы использовали схему отслеживания commit’ов, то часть commit’ов оставлась в репозитории не проверенной.
Иногда в «запарке», я откладывал проверку на потом, а там ещё commit’ов накидали и старые уже просто лень смотреть совсем, и этого потом так у меня и не наступало.
Поэтому, дабы дисциплинировать себя самого, мы использовали инструмент, чтобы это «потом» однозначно наступало рано или поздно.
Ещё инструмент позволяет удобно отслеживать всю историю изменений и общения по конкретным блокам кода. В почтовой программе такого удобства, к сожалению, нет.
Инструмент позволяет работать с изменениями наподобие wiki движка: все комментарии видны, удобство обсуждения и хорошо отслеживается история изменений по ходу общения.
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.
Надо убедить человека совершить то или иное действие либо выдать информацию о себе. При этом говорить «я участвую в конкурсе, подыграйте мне» не стоило)
Можно и разжевать :)
Смотрите, при реализации кроссплатформенных приложений – главное, правильная архитектура, разделение кода на логические слои: GUI, бизнес-логика, слой коммуникации. В данной статье я по сути описал именно алгоритм создания такого слоя коммуникации.
Что же касается GUI – тут все плохо: для каждой платформы пишется свой GUI. Но если грамотно спроектировать приложение, то вам по сути и придется, что только перерисовать несколько вьюшек, если конечно не шибко замудренный интерфейс.
ObservableCollection — можно, но осторожно, все упирается в отсутствие нормальной поддержки generic-типов. :) Так что если вы будете работать с ObservableCollection как с необобщенной коллекцией – то попробовать можно, хотя я этого делать крайне не рекомендую. Лично я для этого написал свой класс, который реализует все не типизированные интерфейсы ObservableCollection, и горя не знаю:)
На счет XAML – должен вас огорчить. По сети давно ходят слухи, что некие энтузиасты работают над таким решением, но рабочего решения я так и не видел. Однако не все так печально: нативные библиотеки iOS и Andorid весьма богаты функционально и просты в использовании. А учитывая гайды по построению пользовательских интерфейсов – для каждой платформы должен быть свой интерфейс, учитывающий специфику платформы (поверьте, iOS пользователь, увидев на Айпаде Metro-интерфейс на долго впадет в ступор и врядли заъочет использовать ваше приложение).
Если эта тема в самом деле интересна – я могу написать по ней еще несколько статей.
Что касается дженериков – согласитесь, возможность переопределять виртуальные методы generic-типов – одно из их главных преимуществ в .NET. И отсутствие возможности реализовать IEnumerable очень сильно огорчает. Хотя тут да, вы правы, я погорячился, говоря что нет «никаких» генериков. Правильнее было бы сказать «большинства возможностей генериков».
На счет рефлексии – вы правы, тут я то же погорячился как и в предыдущем примере :) Однако согласитесь, вряд ли в клиентских приложениях потребуется сложная логика по анализу классов без возможности работы с их экземплярами. Лично мне не приходит в голову сценарий использования этого функционала.
Разработчик работает над фичей недельку и каждый день делает commit’ы, дабы не заморачиваться с backup’ами. Допустим, что у него получилось порядка 15 commit’ов в разные файлы и что один файл участвовал во всех 15 commit’ах, причём код в этом файле правился, добавлялся, удалялся, рефакторился.
После того, как разработчик посчитал, что закончил работу над функционалом, и готов представить результаты на инспекцию, он создаёт инспекцию и добавляет все ревизии, которые относятся к этой задаче.
Меня как инспектора интересует diff было-стало. Что там было посередине – для меня не интересно, слишком дорого.
Лично мы своей командой работали в trunk’e, но на каждую задачу создавали свою рабочую копию. Поэтому, когда коммитил изменения по одной задаче и переключался на другую, то всегда обновлял рабочую копию, чтобы все изменения объединились.
Если работая над задачей видел, что какой-то разрабатываемый функционал будет нужен мне в других задачах, то мог его разработку провести отдельной подзадачей. Такое, правда, случалось очень редко, т.к. в большинстве своём задачи в работе (как правило, не больше 3 задач) редко пересекаются кодовой базой. Поэтому мы решили, что такие единичные случаи нам дешевле обработать, проведя разработку общей части в рамках новой подзадачи (прямо в багтрекере разработчик заводил новую задачу, в рамках которой выполнялась разработка общего функционала).
Поэтому, когда я начинал инспекцию, мне было совсем не интересно, как там правил код автор, и пытаться понять, каким образом автор пришёл к конечному решению — слишком дорого, в моём понимании.
Мы проводили инспекцию итогового решения:
1) удовлетворяет ли оно предъявляемым требованиям;
2) достаточно ли use-case’ов покрывают unit-тесты;
3) проверить код на отсутствие логических дефектов (например, конфигурация прибора читается до начала работы с ним);
4) проверить на применение правильных идиом (те же shared_ptr, отсутствие утечки ресурсов и применение RAII);
5) проверить корректную обработку граничных условий и обработку и сигнализацию ошибок (exception/return value).
Резюмируя, не припомню, чтобы комментарии к коммитам как-то помогали мне на инспекциях. Unit-тесты и комментарии к ним – да, doxygen комментарии к функциям/классам – да, комментарии в коммитах – нет.
Имхо, конечно.
Переименование/перемещение файла CC понимает как удаление старого и создание нового. Не совсем удобно.
Хотя такие ситуации возникают достаточно редко. У нас были заведены, например, шаблоны именования файлов.
С другой стороны, если файл разрастается, то в конечном итоге, он подвергается рефакторингу и делению на несколько файлов. Корректность copy-paste’а из старого файла в новый приходится отслеживать вручную.
Более подробно формализации use-case'ов инспекций кода у нас была посвящена предыдущая статья. В ней рассмотрены, в частности, межкомандные инспекции.
Этот пример я взял из личного опыта предыдущего проекта, и мне было просто удобно на нём продемонстрировать интерфейс CC.
На предыдущем проекте у меня часто были задачи поддержки какого-то нового оборудования. Например, нужно поддержать новый контроллер или прибор учёта какого-то производителя (например). В этом случае создавался каталог для этого счётчика и создавались файлы реализации логики конкретно этого прибора, которые потом попадали на инспекцию (мы вели разработку прямо в trunk’e). Мы создали очень хорошую объектную модель(что типа фреймворкa), у которой всё было разнесено по разным уровням абстракции, и для поддержки нового прибора чаще всего нужно было создать реализацию абстракций именно под этот конкретный прибор. Схема очень похожа на модель драйверов в ядре Linux'a. Там есть так называемый bus драйвер, ниже — драйвер контролера, ещё ниже — драйвер конкретной железяки. Добавление достаточно объёмных новых файлов у нас было нормальным явлением.
Заводилась одна большая задача, которая делилась на несколько небольших подзадач, по каждой подзадаче делались commit'ы и на каждую подзадачу создавалась отдельная инспекция. Деление проводилось по разным логическим единицам: поддержка чтения архивов, поддержка чтения журналов, поддержка чтения текущих значений и т.д.
Т.е. разработчик каждый день, когда хотел, коммитил свой код в репозиторий. Затем, когда приходило время инспекции, указывал все нужные ревизии в инспекцию.
Когда я инспектирую вновь добавленные файлы, в которые уже было сделано по несколько commit'ов, то хочу видеть последнее состояние файла без промежуточных изменений, которые для меня не интересны. Вот это как раз позволяет сделать СС автоматически.
К сожалению, всю прошлую пятницу хабр оставался для нас недоступен. Видимо, корпоративный IP был зафильтрован в процессе масштабной борьбы с DDoS-атаками. Сейчас ситуация изменилась, и в ближайшее время предоставим вам автора ;-)
Еще раз, огромное спасибо за вопросы и комментарии!
Напишу именно про себя и свой опыт.
Когда мы использовали схему отслеживания commit’ов, то часть commit’ов оставлась в репозитории не проверенной.
Иногда в «запарке», я откладывал проверку на потом, а там ещё commit’ов накидали и старые уже просто лень смотреть совсем, и этого потом так у меня и не наступало.
Поэтому, дабы дисциплинировать себя самого, мы использовали инструмент, чтобы это «потом» однозначно наступало рано или поздно.
Ещё инструмент позволяет удобно отслеживать всю историю изменений и общения по конкретным блокам кода. В почтовой программе такого удобства, к сожалению, нет.
Инструмент позволяет работать с изменениями наподобие wiki движка: все комментарии видны, удобство обсуждения и хорошо отслеживается история изменений по ходу общения.
Меня в свою команду вы, видимо бы не взяли :)
1. Мы реализуем новый функционал в отдельных ветках.
2. Каждая большая задача всегда разбивается на подзадачи.
3. Разработчик отдаёт код на инспекцию вменяемыми законченными частями.
4. Приоритет на инспекцию у нас ниже только критических уязвимостей.
Смотрите, при реализации кроссплатформенных приложений – главное, правильная архитектура, разделение кода на логические слои: GUI, бизнес-логика, слой коммуникации. В данной статье я по сути описал именно алгоритм создания такого слоя коммуникации.
Что же касается GUI – тут все плохо: для каждой платформы пишется свой GUI. Но если грамотно спроектировать приложение, то вам по сути и придется, что только перерисовать несколько вьюшек, если конечно не шибко замудренный интерфейс.
ObservableCollection — можно, но осторожно, все упирается в отсутствие нормальной поддержки generic-типов. :) Так что если вы будете работать с ObservableCollection как с необобщенной коллекцией – то попробовать можно, хотя я этого делать крайне не рекомендую. Лично я для этого написал свой класс, который реализует все не типизированные интерфейсы ObservableCollection, и горя не знаю:)
На счет XAML – должен вас огорчить. По сети давно ходят слухи, что некие энтузиасты работают над таким решением, но рабочего решения я так и не видел. Однако не все так печально: нативные библиотеки iOS и Andorid весьма богаты функционально и просты в использовании. А учитывая гайды по построению пользовательских интерфейсов – для каждой платформы должен быть свой интерфейс, учитывающий специфику платформы (поверьте, iOS пользователь, увидев на Айпаде Metro-интерфейс на долго впадет в ступор и врядли заъочет использовать ваше приложение).
Если эта тема в самом деле интересна – я могу написать по ней еще несколько статей.
На счет рефлексии – вы правы, тут я то же погорячился как и в предыдущем примере :) Однако согласитесь, вряд ли в клиентских приложениях потребуется сложная логика по анализу классов без возможности работы с их экземплярами. Лично мне не приходит в голову сценарий использования этого функционала.