Как понудить программистов писать качественный код? Формал. инспекции
в книге "Совершенный код"В этой книге, как и других подобных, много спорных моментов. Эти книги полезные, но не истина в последней инстанции.
Вот примерно также говорят нежелающие исправляться. Спорят, отнимают время и у себя и у других. Глубинная причина этого, думаю, лень, нежелание учиться лучшему опыту разработки ПО и, конечно, гордость.
Также общая черта этих программистов заключается в непонимании того, что одна из главных задач программиста — это писать код, который можно с минимальными затратами времени, внимания и памяти читать и поддерживать другим разработчикам. В частности поэтому идея проведения формальных инспекций кода, в которых обычно предполагается, что код должен говорить сам за себя, мне кажется такой привлекательной.
Программист должен знать, что его код будут читать (инспектировать иначе какие еще стимулы для написания качественного кода у него будут? Ведь в своем коде он сам нормально ориентируется, а что будет с проектом после его ухода ему не важно, да и дополнительный стимул появляется писать запутанный код центральных частей приложения, чтобы стать незаменимым и застраховаться от увольнения.
Также общая черта этих программистов заключается в непонимании того, что одна из главных задач программиста — это писать код, который можно с минимальными затратами времени, внимания и памяти читать и поддерживать другим разработчикам. В частности поэтому идея проведения формальных инспекций кода, в которых обычно предполагается, что код должен говорить сам за себя, мне кажется такой привлекательной.
Программист должен знать, что его код будут читать (инспектировать иначе какие еще стимулы для написания качественного кода у него будут? Ведь в своем коде он сам нормально ориентируется, а что будет с проектом после его ухода ему не важно, да и дополнительный стимул появляется писать запутанный код центральных частей приложения, чтобы стать незаменимым и застраховаться от увольнения.
давай премии за качественный код, так же как даются премии за прочитанную литературу например.мож поможет?
В проекте есть программисты (Java которые работают продуктивно, но обладают особенными личностными качествами, излишним чувством своей правоты, и не хотят учиться стандартным методологиям разработки ПО, описанным, например, в книге "Совершенный код" или в книге "Effective Java" (Bloch). В частности, пишут большие методы, не выделяют повторяющиеся фрагменты в отдельные методы, а копипастят, форматируют отступы по разному, на разное число пробелов, мало думают над тем, чтобы код был максимально простым и удобным для чтения, вводят переменные с неграмотными в смысле английского языка названиями, не всегда соблюдают верблюжью нотацию, используют низкоуровневые средства организации многопоточности (Thread) вместо простых стандартных подходов, усложняя код для других, и т.п.Две мысли по поводу такой проблемы:
Нужно ввести какой-то регламент, чтобы все его соблюдали. Просто говорить — не пиши говнокод, нельзя. Изучив разные подходы к повышения качества ПО, нашел, что формальные инспекции кода могли бы быть хорошим средством решения этих технико-социальных проблем. Но нужно все организовать так, чтобы свести к нулю споры и взаимные обиды. Как это лучше сделать, у кого был подобный опыт организации контроля качества ПО?
1) такие программисты должны обучать младших -> возьмите джуниоров
2) такие программисты должны гореть в аду
Да, формальная инспекция кода может помочь в том смысле, что вы выявите явных нарушителей ( уже сделали ) и сможете показать им, что они не правы ( невозможно, потому что они "круты" и горды ) путем давления коллектива или страшилками о том, что может произойти ( или уже произошло ) из-за "такой работы копипасты и остального" и кто будет наказан
Если им дать толковых джуниоров, которые хотят учиться, то возникнет доля ответственности ( коей я не замечаю по вашему описанию проблемы ). И вот такое отцовство сможет натолкнуть этих джедаев на путь силы.
Альтернатива джуниоров - большой ненужный кусок старого кода ( клин клином ) или ненужный большой проект ( псевдоответственность ).
Основная идея, которую я хотел бы донести до них - Вы не только пишете код, но еще и являетесь ответственными за него перед коллективом (!)
Поэтому:
- джуниоры
- ненужный старый код
- ненужный проект
Могу и ошибаться в психологии и поведении коллег
Может и поможет, только начальство не согласится.
Разработчики делают лишние копипасты и при этом продуктивно работают? Не стыкуется.
Спасибо за идеи! Но цель в мягком воздействии на авторов кода, чтобы люди делали выводы сами и продолжали разработку приложения, но более качественно с точки зрения его текста.
Как это лучше сделать, у кого был подобный опыт организации контроля качества ПО?Я сделал три проекта с одинаковым стилем кода в достаточно больших командах. По моему опыту здесь только два варианта. Или тимлид с полномочиями на постановку задач на переписывание и рефакторинг кода с наивысшим приоритетом. Или уже созданная общая атмосфера в коллективе (вроде бы, такой коллектив есть в Google когда от нового разработчика требуют соблюдать стиль кодирования, не обращая внимание на его "обиды". Ввести хорошую практику в командах, где среди разработчиков полностью отсутствует вертикаль, практически нереально. Тем более, если усложнить эту задачу попытками всех удовлетворить и никого не обидеть.
Метрики и примеры из книжек, как и другая аппеляция к третьим лицам - это хорошо. Но работает только тогда, когда разработчики согласны так договариваться. А это само по себе большая редкость.
По-моему, это только сверху можно ввести. Надо сверху принять coding style и регламент проведения ревью кода
Неужели угроза тем, что их бог покарает, не работает? 
По-моему, это только сверху можно ввести. Надо сверху принять coding style и регламент проведения ревью кодаТак себе это работает) По крайней мере везде, где я видел работающие практики очищения и улучшения кода - они шли изнутри команд.
Топикстартер - если команда, которая фигачит говнокод, считается продуктивной - то может все остальные команда не так поняли эти-ваши-умные-книги и вас не очень-то надо и слушать? :-)
Так себе это работает) По крайней мере везде, где я видел работающие практики очищения и улучшения кода - они шли изнутри команд.Инициатива должна исходить из команды, а приниматься должно сверху. Т.к. поначалу скорей всего эти практики улучшения и очищения кода увеличат сроки проекта.
В проекте есть программисты (Java которые работают продуктивно, но обладают особенными личностными качествами, излишним чувством своей правоты, и не хотят учиться стандартным методологиям разработки ПО, описанным, например, в книге "Совершенный код" или в книге "Effective Java" (Bloch). В частности, пишут большие методы, не выделяют повторяющиеся фрагменты в отдельные методы, а копипастят, форматируют отступы по разному, на разное число пробелов, мало думают над тем, чтобы код был максимально простым и удобным для чтения, вводят переменные с неграмотными в смысле английского языка названиями, не всегда соблюдают верблюжью нотацию, используют низкоуровневые средства организации многопоточности (Thread) вместо простых стандартных подходов, усложняя код для других, и т.п.Ответ зависит от того, какую роль данные люди играют в компании.
Если эти люди незаменимы, т.е. делают что-то реально сложное, но забивают при этом на культуру разработки, то пусть кто-нибудь менее умный занимается рефакторингом / причёсыванием их кода.
Если же они не являются выдающимися и незаменимыми работниками, можно их просто уволить.
Но нужно все организовать так, чтобы свести к нулю споры и взаимные обиды.Очень хорошо помогает диктатура лида + некоторое количество уважаемых разработчиков, на которых лид может опереться. Тогда остальных можно приучить делать все по-человечески. Не очень понятно, зачем ты хочешь все формализовать, кмк только спровоцируешь буквоедство в духе "я буду так делать, потому что в правилах не прописали, что так делать нельзя ."
Вообще, из того что ты перечислил в списке проблем только размер метода выглядит для меня дискуссионным, все остальное с моей точки зрения любой нормальный java-кодер должен принимать и практиковать без разговоров. Нарушение code style, свой особый размер отступа (в тяжелом случае подобные существа еще и переформатируют чужой код под свои привычки прямое использование Thread - все это выглядит очень плохо.
У вас там крутые олимпиадники или наоборот выходцы из НИИГиТ?
По-моему, это только сверху можно ввести. Надо сверху принять coding style и регламент проведения ревью кодаДа, нужно будет сначала попробовать договориться с разработчиками, убедить их, что практика инспекций кода активизирует обмен опытом между программистами, а потом поговорить с начальством.
У вас там крутые олимпиадники или наоборот выходцы из НИИГиТ?
Нет, вроде бы обычные выпускники технических вузов, но работоспособные и трудолюбивые. Вот только сначала продумать все в голове или на бумажке (на доске выбрать простейший путь решения, а потом реализовать его, еще не очень имеют, как мне кажется (или не хотят).
А реально собрать всех и выработать единый code style, который зафиксировать потом на уровне pre-commit hook-ов?
Заодно в workflow разработки можно внедрить успешно пройденный code review, как необходимое условие попадания кода в мастер.
Заодно в workflow разработки можно внедрить успешно пройденный code review, как необходимое условие попадания кода в мастер.
Вот только сначала продумать все в голове или на бумажке (на доске выбрать простейший путь решения, а потом реализовать его, еще не очень имеют
и!
Да, нужно будет сначала попробовать договориться с разработчиками, убедить их, что практика инспекций кода активизирует обмен опытом между программистами, а потом поговорить с начальством.А прежде чем принуждать какую-то команду - у вас у самих эти практики есть? А работают так как хотите?
Если такие практики работают, это вполне можно делать на уровне полиси - merge в мастер невозможен без двух ревью-аппрувов. Не успеваешь сдать таск из-за ревью? Сам себе злобный буратино
1) такие программисты должны обучать младших -> возьмите джуниоров
Просто говорить — не пиши говнокод, нельзя. Изучив разные подходы к повышения качества ПО, нашел, что формальные инспекции кода могли бы быть хорошим средством решения этих технико-социальных проблем.Не прокатит. Надо нанимать сильных кодеров, а это требует времени и денег. Никакими формальными инспекциями кода это не исправить.
Надо смириться и признать, что уровень качества, который вы можете выдать, ограничен вашим бюджетом.
тимлид с полномочиями на постановку задачВсе задачи проходят через голову одного человека? Как такой подход масштабируется по количеству задач? Этот человек не вникает в детали задач?
как лид вывел для себя два принципа, которых стараюсь придерживаться:
1. На стадии обсуждения все могут предлагать способы улучшения, концепции и т.п.
Окончательное решение принимается лидом, также на него сваливается вся ответственность за принятое решение.
2. Решение окончательное и обязательное к исполнению. На этом этапе несогласные пиздятся ногами вплоть до административных санкций. Могут быть исключения, но только при наличии объективных факторов (невозможность реализации из-за неучтенных особенностей и т.п.)
вообще для продуктивной работы команды лиду надо в первую очередь составить правила работы: оформление кода, политика работы с VCS, зоны ответственности и т.д..
1. На стадии обсуждения все могут предлагать способы улучшения, концепции и т.п.
Окончательное решение принимается лидом, также на него сваливается вся ответственность за принятое решение.
2. Решение окончательное и обязательное к исполнению. На этом этапе несогласные пиздятся ногами вплоть до административных санкций. Могут быть исключения, но только при наличии объективных факторов (невозможность реализации из-за неучтенных особенностей и т.п.)
вообще для продуктивной работы команды лиду надо в первую очередь составить правила работы: оформление кода, политика работы с VCS, зоны ответственности и т.д..
в случае большой команды надо вводить мини-лидов по модулям
в случае большой команды надо вводить мини-лидов по модулямПриходим к первоначальному вопросу. Как эти люди будут договариваться?
Приходим к первоначальному вопросу. Как эти люди будут договариваться?садишься с ними, слушаешь доводы каждого, выносишь вердикт
кто не согласен - пиздишь ногами
Так договариваются лиды?
Чтобы вынести правильный вердикт нужно вникать в детали (дьявол в деталях). Это плохо масштабируется по количеству задач.
Чтобы вынести правильный вердикт нужно вникать в детали (дьявол в деталях). Это плохо масштабируется по количеству задач.
Вот только сначала продумать все в голове или на бумажке (на доске выбрать простейший путь решения, а потом реализовать его, еще не очень имеют, как мне кажется (или не хотят)В какой книжке ты прочитал "продумать все в голове"? Приведи, пожалуйста, ссылку.
Знаю книгу авторитетного автора, в которой написано ровно противоположное.
Чтобы вынести правильный вердикт нужно вникать в детали (дьявол в деталях). Это плохо масштабируется по количеству задач.ты что-нибудь про делегирование слышал?
лиду не нужно вникать большинство задач, ему нужно вникать в наиболее важные из них и создавать политики
к примеру,
мини-лиды берут на себя 80% работы лида по модулям, остальные 20% твои
как пример, я не занимаюсь разработкой UI, но я отвечаю за проект в целом. Я не вникаю в каждую задачу по UI, но я слежу за кодом и метриками (потребление памяти, производительность, предупреждения компилятора, предупреждения статического анализа).
При необходимости делаю полный ревью и анализ проблемного кода (обычно по фидбэку от тестеров) по результатам которого и видно, что надо раздать: пиздюли или пряники.
Я сделал три проекта с одинаковым стилем кода в достаточно больших командах.а ты случайно не сделал пару проектов с разными стилями кода? вот тут ты бы прокачался серьезно
Изучив разные подходы к повышения качества ПО, нашел, что формальные инспекции кода могли бы быть хорошим средством решениянашел? если это самое точное слово, то в данном конкретном случае оно не поможет, т.к. в коллективе чувствуются проблемы с компромиссами.
формальный coding style может решить часть проблем
у меня есть опыт внедрения как кодинг стиля, так и код ревью. последний не прижился (или еще точнее, не внедрился) в коллективе (речь о плюсовиках первый удалось продавить, но нелегко. сначала я составил документ, потом спорные моменты утверждали голосованием. опять же использовался местный авторитет (это не я) для продавливания самого факта существования документа
при составлении самого документа пришлось учитывать местную специфику, чтобы людям не надо было сильно перестраиваться, ведь главная цель документа была выработать единый стиль, а не навязывать некое абсолютное добро.
на данный момент остается куча легаси в старом формате, люди далеко не все пункты стандарта соблюдают. вот так и живем
кстати, очередным толчком для принятия формального документа явилось увольнение одного из новичков (он был на испытательном сроке который сильно выделялся (в плане кода) от корифеев. на копромисс тяжело шел (точнее мы все шли вопросы дизайна тоже плохо обсуждались. с другой стороны, не уверен, что даже если бы документ уже существовал, то этот индивид не выделялся бы. некоторые главы в стандарте пришлось писать по его примерам кода, уж слишком специфическими они были
у меня есть опыт внедрения как кодинг стиля, так и код ревью. последний не прижилсяНа самом деле немножко странно, что coding guide заработал отдельно от код-ревью - они, обычно, неплохо дополняют друг-друга.
Ну и еще - половина боли от coding style решается как правило одним потраченным вечером на настройку Uncrustify или чего-нибудь аналогичногО, после чего 90 процентов проблем форматирования решаются одним хоткеем, а об именовании переменных/методов обычно люди проще договариваются, чем о фигурных скобочках :-)
Но цель в мягком воздействии на авторов кода, чтобы люди делали выводы сами и продолжали разработку приложения, но более качественно с точки зрения его текста.По-хорошему делать долго, дорого и нужны полномочия.
По-плохому:
1. Разбивать задачи на куски, которые можно переписать целиком в случае пропажи программиста.
2. Следить чтобы не было кусков кода, которые знает только один программист (а если они есть см п.1).
Нужно ввести какой-то регламент, чтобы все его соблюдали. Просто говорить — не пиши говнокод, нельзя. Изучив разные подходы к повышения качества ПО, нашел, что формальные инспекции кода могли бы быть хорошим средством решения этих технико-социальных проблем. Но нужно все организовать так, чтобы свести к нулю споры и взаимные обиды. Как это лучше сделать, у кого был подобный опыт организации контроля качества ПО?Это очень жёстко. Для начала хотя бы сделай процесс с обязательным код ревью и покрытием тестами
чтобы свести к нулю споры и взаимные обидывсе равно надо будет стукнуть по столу и сказать или так или уе..сваливай
кусков кода, которые знает только один программистПочему все говорят о хорошей читаемости когда и тут же пишут "программист должен знать код", "должен помнить"? Всегда же можно прочитать.
Тут "знать" = "читал, понял и правил".
странно, что coding guide заработал отдельно от код-ревьюкодинг стайл надо прочитать
код-ревью - надо по-другому работать (другой рабочий процесс)
не все готовы отказываться от многолетнего ритма
какие преимущества у uncrustify перед студийным (MS VS) форматированием (разработка под винду интересует)?
Тут "знать" = "читал, понял и правил".Если у кода хорошая читаемость, то читать, понимать и править можно по требованию. Возникла такая потребность, берешь и делаешь. Почему у вас не так?
Если у кода хорошая читаемость, то читать, понимать и править можно по требованию. Возникла такая потребность, берешь и делаешь. Почему у вас не так?Тред читай с начала.
Ясно. Вместо текстовых файлов с кодом храните информацию в головах программистов.
Ясно. Вместо текстовых файлов с кодом храните информацию в головах программистов.
даже резервные копии делаете:
2. Следить чтобы не было кусков кода, которые знает только один программист (а если они есть см п.1).
Почему все говорят о хорошей читаемости когда и тут же пишут "программист должен знать код", "должен помнить"? Всегда же можно прочитать.Я правильно понимаю, что если ты участвуешь в проекте с объёмом кода от 10мб, то для решения каждой задачи ты читаешь этот код заново, с нуля, все файлы подряд, разыскивая за линейное время первое место, от которого можно начинать твою любимую "навигацию"?
- Siri, найди мне тот кусок кода, который нужно исправить.
Почему все говорят о хорошей читаемости когда и тут же пишут "программист должен знать код", "должен помнить"? Всегда же можно прочитать.
Я правильно понимаю, что если ты участвуешь в проекте с объёмом кода от 10мб, то для решения каждой задачи ты читаешь этот код заново, с нуля, все файлы подряд, разыскивая за линейное время первое место, от которого можно начинать твою любимую "навигацию"?
- Извините, не могу прочитать ваш код, попробую поискать в интернете
Оставить комментарий
nikola1956
В проекте есть программисты (Java которые работают продуктивно, но обладают особенными личностными качествами, излишним чувством своей правоты, и не хотят учиться стандартным методологиям разработки ПО, описанным, например, в книге "Совершенный код" или в книге "Effective Java" (Bloch). В частности, пишут большие методы, не выделяют повторяющиеся фрагменты в отдельные методы, а копипастят, форматируют отступы по разному, на разное число пробелов, мало думают над тем, чтобы код был максимально простым и удобным для чтения, вводят переменные с неграмотными в смысле английского языка названиями, не всегда соблюдают верблюжью нотацию, используют низкоуровневые средства организации многопоточности (Thread) вместо простых стандартных подходов, усложняя код для других, и т.п.Нужно ввести какой-то регламент, чтобы все его соблюдали. Просто говорить — не пиши говнокод, нельзя. Изучив разные подходы к повышения качества ПО, нашел, что формальные инспекции кода могли бы быть хорошим средством решения этих технико-социальных проблем. Но нужно все организовать так, чтобы свести к нулю споры и взаимные обиды. Как это лучше сделать, у кого был подобный опыт организации контроля качества ПО?