Как поставить качество кода на поток и при этом не разориться? Какие шаги стоит сделать уже завтра, чтобы повысить планку качества?

Меня зовут Козлов Иван, я из компании Бизнес Лоджик, город Москва, я – технический руководитель.

Поднимите руки, кто считает, что качество на проекте – это важно? А кто считает, что счастливый клиент и сданная работа – это важно?

Возьмем две крайности одной и той же сущности – у нас есть буддийский монах, который 10 лет медитировал на горе и жизнь познал, и есть какой-нибудь капиталист Дональд Трамп, который, скорее всего, нигде не медитировал, но тоже жизнь познал.

Как правило, суть находится посередине – должен быть баланс: и проект должен быть сдан, и заказчик должен быть удовлетворен, и качество не должно страдать.

Я сегодня расскажу вам, как мы внедряли процессы по улучшению качества кода в нашей компании и еще в одной компании, в которой я работал до этого. По сути, процесс тот же самый – один раз попробовал и сделал это еще раз.

Причины появления некачественного кода

Перейдем к истокам. Как вы считаете, зная опыт человека, можно ли определить – хороший он программист или нет? Я считаю, что все-таки можно. Но тут возникает следующий вопрос – чем мы этот опыт будем измерять. По версии HeadHunter, опыт можно измерить годами – опыт от 3 до 5 лет, 10 лет.

Так как я собеседую кандидатов практически каждую неделю по нескольку раз, активно набираю сотрудников, я видел людей, которые приходят в 50 лет устраиваться на работу программистом, и бывают такие случаи, когда человек 20 лет работал программистом и все эти 20 лет потратил не зря. Приходит человек со светлой головой, если увидишь его вживую – никогда не скажешь, что ему 50 лет. Он молодой. А бывают люди, которые 20 лет потратили впустую и практически ничему не научились.

Я время от времени играю на гитаре, но у меня не очень хорошо получается. Прихожу к преподавателю, прошу его: «Научи меня». Он мне говорит: «У тебя вообще не получается» – «Как так, я же уже три года играю» – «Ко мне приходят люди, которые по двадцать лет играют, но так ничему и не научились, они новички с двадцатилетним опытом». Это очень печально.

Мы должны признать, что чтобы стать хорошим программистом, нужно развиваться. И опыт все-таки нужно измерять в тех задачах, в тех предметных областях, в которых человек уже «поварился» – оценить именно то, что он сделал, а не то, за какой промежуток времени он это сделал.

То есть если предположить, что в какой-то компании есть внятная модель обучения, где каждого сотрудника готовят к тому, чтобы он стал программистом, а не просто – бросают его на 10 лет, а через 10 лет он ничего не научился делать. И потом получается так, что человек, который 10 лет программировал, уступает по навыкам тому человеку, который три года целенаправленно занимался, становясь программистом. И тот человек, который 10 лет на это потратил, понять не может, как же так получилось.

Кто это накодил?

Соответственно, рано или поздно в каждой организации возникает вопрос – как же мы будем управлять качеством того продукта, который мы производим?

Когда возникает этот вопрос? Если компания небольшая, меньше 15-20 сотрудников, там есть старожилы – любая компания с чего-то начиналась. И скорее всего, там есть сотрудники, которые работают давно. И поскольку компания запустилась и работает успешно, то, скорее всего, эти сотрудники были квалифицированными, иначе бы ничего не получилось.

А потом начинается набор новых сотрудников, и об их обучении никто не заботится, а внятного набора новых сотрудников и критериев, которым они должны соответствовать, нет. На Инфостарте недавно задавали вопрос: «Какое самое необычное задание вам давали при приеме на работу» – «Никакого задания не дали, и на работу приняли».

Однажды, когда я устраивался на работу в Москву, я, проходя собеседование, просто поздоровался с человеком, рассказал: «Я – такой-то, умею то-то и то-то». И мне ответили: «Вы нам подходите». Я удивился: «А как же вы будете оценивать, что я вам действительно подхожу?»

Вернемся к сотрудникам-старожилам, которые с течением времени работы в компании начинают замечать, что с кодом что-то не так – начинают появляться какие-то ошибки. Разработчики открывают модуль, где вроде бы недавно все было хорошо, и ужасаются – кто все это сделал? И все молчат. Как найти виноватого?

В качестве примера предлагаю обратить внимание, что я сегодня с классическими брюками надел кроссовки. Так захотелось. А один мой товарищ мне сказал: «Почему ты так сделал? Так нельзя делать» – «Почему нельзя? Где записано, что мне нельзя эти кроссовки к этим брюкам надевать?» – «Ну, это же все знают». Понимаете, к чему я клоню – что нужно человеку дать, чтобы он мог понять, правильно он кодит или неправильно?

Для этого существуют стандарты разработки.

Пути решения

Есть замечательные статьи Виталия Онянова про стандарты разработки – он об это рассказывал и в докладах на Инфостарте.

Можете взять стандарты с ИТС, которые предлагает фирма «1С». Они тоже замечательные. Правда, по причине того, что их никто никогда не читал, они не всегда работают. Поэтому, чтобы они начали работать, их нужно сначала прочитать.

Соответственно, когда вы прочитаете эти стандарты – обсудите с разработчиками, что из них вам нужно. Как сделали в команде у Виталия Онянова – они отобрали то, что нужно, и тем, что нужно, пользуются. Доходить до каких-то крайностей и соблюдать стандарты все, до последнего, не обязательно.

По поводу стандартов первое, с чего мы начали, это – определили стандарт комментирования, чтобы мы могли направлять человеку какие-то замечания адресно. Чтобы можно было сразу определить, кто это сделал.

Для кого-то комментировать изменения – это само собой разумеющийся факт, они ни разу не видели кода без комментария. Но бывают компании, где изменения вообще не комментируют – либо не успели научить этому молодого сотрудника, либо еще по какой-то причине.

Цели Code Review

Есть несколько вариантов, почему люди пишут некачественный код. Изначально мне казалось, что есть только один вариант – люди знают, как нужно делать, но почему-то ленятся. Но потом при ближайшем рассмотрении выяснилось, что люди попросту не знают, как делать правильно. И делают так, как у них получается. А почему так происходит?

Вернемся к вопросу, который был задан изначально: «Что важнее – довольный заказчик или качественная разработка?»

Как обычно получается – приходит человек в большой франч, ему дают какую-то задачу, и он ее решает. Аналитический склад ума у него есть, задачу он решил, главный бухгалтер его поблагодарил – тот довольный пошел. А то, как этот отчет устроен внутри – никто не видел, потому что все вроде и так работает. И потом через какое-то время бывалый программист туда заглядывает и ужасается – так делать не надо.

Поэтому не надо тыкать людей в то, что они неправильно делают, а надо просто понять причины, почему они так делают, и как-то постараться эти причины исправить.

И дальше возникает такой вопрос – зачем мне вообще вводить Code Review? И в каком объеме я его должен вводить? Ради чего это нужно сделать?

Надо понимать, что первое возражение, с которым вы столкнетесь, когда захотите ввести в своей команде Code Review – это вопрос: «Сколько это будет стоить?» Ты приходишь с горящими глазами с очередного хакатона: «Все, Code Review будем проводить – я там такие штуки видел интересные». А собственник спрашивает тебя: «А сколько это будет стоить?» А ты об этом даже не думал, ты же думал про качество. Поэтому в большинстве случаев Code Review не получается ввести по причине того, что его нельзя продать.

Хотя в некоторых случаях – наоборот, Code Review вводят принудительно и покупают коммерческий плагин к 1С для Sonar. Это две крайности одной и той же сущности.

Я же призываю вас совершенно к другому. Вы должны понимать, в каком объеме это нужно делать, чтобы не спалить весь бюджет.

Как проводить Code Review

Переходим к вопросу – как же быть в такой ситуации? Я расскажу, как мы у себя в компании решили вопрос с Code Review.

Мы знали, что у нас есть компетентные люди, которые могут проводить Code Review, но мы понимали, что не хотим тратить их время. Потому что, объективно, это – реальные производительные ресурсы. И мы не можем выключать их из работы – ведь, если проводить Code Review за всеми новичками (а их человек 10, допустим), то они работать вообще не будут. Будут работать молодые, а высококлассные специалисты будут просто следить, как это должно быть выполнено. Это неразумно.

Соответственно, мы сделали выборку – проверяли не все задачи, решенные программистом, а выборочно. Причем, задачи выбирались случайным образом – программист не знал, какие в итоге задачи будут выбраны.

Чего мы добиваемся при помощи этого?

• Во-первых, человек не знает, что именно мы будем проверять, поэтому он старается делать хорошо везде – пролететь можно на любой задаче.
• А второй момент – если человек косячит и делает что-то неправильно, то он это делает везде. Он косячит не выборочно – сегодня здесь накосячу, а здесь – нет. Он научился так делать и продолжает делать так дальше. Соответственно, найдя некачественный код где-то в одном месте, вы тиражируете это сразу на все аналогичные вхождения этого кода. И сотрудник сразу же получает обратную связь, что так делать не нужно. А если человек вменяемый, и ему нормально донесли, почему так делать не нужно, он перестает так делать. Есть саботажники, которые продолжают делать неправильно, зная, как делать правильно. Но это – отдельный разговор. Это можно у Александра Орлова спросить, что такое конструктивная конфронтация, и как этим людям объяснить, почему так делать не нужно. Но таких людей, к счастью, гораздо меньше.

Соответственно, дальше происходило так – мы составляли отчеты на первом этапе. И обезличенные отчеты, чтобы не тыкать никому, что ты делаешь неправильно, потому что молодые сотрудники будут регулярно в этих отчетах мелькать, а это демотивирует. Мы делали эти отчеты анонимными и рассылали на всех, чтобы все могли поймать, посмотреть. Кого-то не поймали на ошибке, но он это увидел, посмотрел – понял, что так делать не нужно. Но в индивидуальном порядке разъяснительные работы были. Так мы снимаем психологический момент, когда человеку некомфортно, что его постоянно на доске позора вывешивают.

Потом мы решили, что составлять отчеты – это долго и муторно. Поэтому мы сделали просто анонимный чат в корпоративном портале. И когда что-то находилось, просто вывешивали туда.

Интересно, кстати, по поводу сотрудников, которые 10 лет занимались разработкой, но не научились стандартам. Иногда эти сотрудники даже в анонимном чате начинают писать: «А почему неправильно-то? Я это сделал по такой-то причине». То есть анонимность нарушалась самими сотрудниками. Он яро начинал доказывать, что у него все правильно – он так всегда делал, и все были довольны. И этому человеку объясняли, почему это неправильно.

Как автоматизировать Code Review

Мы поговорили про Code Review, который проводится руками, а дальше будем говорить про автоматизацию.

Что нам дает автоматизация Code Review? Она дает нам машинный результат, и ошибки, которые она показывает, относятся больше к «мясу на скелете». А к самому скелету автоматизированные проверки особых требований не предъявляют.

Опять же, чтобы человек правильно программировал – это не значит, что он не должен писать запросы в цикле, обязательно что-то указывать в исключении транзакции или не превышать порог цикломатической сложности. Некоторые даже не знают, что такое цикломатическая сложность – и я скажу, что не всегда на первых этапах вообще к ней стоит подходить. Все должно приходить со временем.

К чему это я говорю? Прежде всего, нужно понимать, как человек мыслит, делать структурный подход – принимать именно алгоритмически правильные и архитектурно правильные решения. А автоматизированных проверок архитектурных решений я не видел – можно сделать только ручные манипуляции.

Опять же – что мы имеем. Имеем опытных сотрудников, которые учат молодых, как нужно делать правильно. Проводят разъяснительную работу как по ошибкам, поиск которых может быть автоматизированным, так и по архитектурным ошибкам – просчетам, которые могут стрельнуть потом.

А когда проходит время, мы понимаем, что постоянно искать одни и те же ошибки, даже если они допущены по невнимательности, неприятно – это начинает раздражать, тем более что со временем сотрудников становится больше. На этом этапе, когда у программистов уже не получается справляться с такой текучкой – возникает автоматизация.

У нас два варианта, которые мы можем использовать, чтобы автоматизировать этот процесс – это SonarQube и АПК.

Вариант №1 – плагин 1С к SonarQube

На тот момент, когда я пользовался SonarQube, единственный вариант был – приобретение плагина. Когда я решил, что нужно попробовать этот плагин, он стоил определенное количество денег, которое казалось мне неподъемным для нашей компании. Но мы все равно решили попробовать. И в тот день, когда мы его попробовали, он стал стоить в четыре раза дороже, поэтому нам пришлось от него отказаться.

Чем хорош SonarQube? Это инструмент, который используется программистами многих языков. У некоторых 1С-ников есть стремление к тому, чтобы инструменты разработки были такими же, как у других программистов – использовать Best Practices из других языков. А SonarQube – это как раз такой инструмент, который можно использовать и в 1С.

Это стильно, модно, молодежно, и дает свои результаты. Здорово.

Вариант №2 – АПК

Что подразумевает под собой АПК? Это бесплатный вариант, на определенных этапах он был достаточно сумбурный и сложный. А те метрики, которые он выдавал, нужно было еще анализировать – понимать, зачем они нужны. Например, ты проверяешь какую-нибудь типовую бухгалтерию фирмы 1С, а потом смотришь – в ней сотни тысяч ошибок. Как же так? Что-то тут неладно. Справедливости ради нужно отметить, что ошибок с каждым релизом становится все меньше и меньше. Видно, что работа ведется.

Что можно сказать про АПК?

АПК – это продукт живой. Даже за тот год, в который я с ним сталкивался и работал, он уже претерпел качественные изменения, которые меня стали устраивать.

Вариант №3 – кастомизированный АПК

И третий вариант – если мы понимаем, как работает проверка на SonarQube и как работает проверка на АПК, мы можем доработать АПК. Она же написана на 1С – и в этом у нее неоспоримое преимущество, потому что дополнительных компетенций для того, чтобы освоить этот программный продукт и дорабатывать его, нам не требуется. Берешь и дорабатываешь – ты же 1С-ник.

АПК не работает напрямую с конфигуратором, она работает с XML-ками, точно так же, как работает SonarQube. А выгружать каждый раз конфигурацию в файлы, даже в пакетном режиме, не очень удобно.

Инфраструктура

Инфраструктура у нас выглядела примерно таким образом.

• Работа с SonarQube уже описывалась в докладе Олега Тымко. Методология остается совершенно той же самой – мы, опять же, выгружаем изменения из хранилища конфигурации в локальный репозиторий при помощи утилиты GitSync. Причем, мы можем делать это итеративно. Не всю конфигурацию каждый раз выгружаем, а по частям – только те объекты, которые были изменены. Это очень удобно и экономит время. Если кто-то пытался ERP выгрузить в XML, вы понимаете, что это занимает определенное количество времени – явно дольше, чем 5 минут происходит. И на этот момент мы получаем исходники в АПК гораздо быстрее – практически в реальном времени.
• Соответственно, в Jenkins мы можем поставить триггер – либо по времени, либо на изменение в самом хранилище. Это уже кому как нравится.

Здесь возникает важный вопрос – если мы вернемся к SonarQube, то там подразумевается, что мы можем следить за качеством практически в динамическом режиме (в реальном времени).

Но возникает вопрос – а нужно ли нам следить за качеством кода в реальном времени? В определенных случаях это наверняка нужно – когда это критично. Но если никакого Code Review до этого в компании не было, делать проверки раз в день или даже раз в неделю – будет вполне достаточно. И здесь аргумент, что АПК работает медленно, отпадает – поскольку никакой скорости не требуется, АПК можно использовать.

Там есть наборы правил. Если использовать все наборы, получится каша. Но если анализировать только те правила, которые нужны (остальные отключить), то можно получать именно тот результат, который бы хотелось получить.

Как улучшить АПК

Использование SonarQube подразумевает, что там есть проверка копипаста, есть цикломатическая сложность, есть пороги качества – ничего такого в АПК нет. Но возникает вопрос – когда это нужно? И для кого это нужно?

Опять же – если мы говорим про АПК, мы же говорим про 1С. Мы все 1С-ники, соответственно, мы открываем Инфостарт, вбиваем в строку поиска КопиПастаМер – и используем в АПК КопиПастаМер, просто как еще одну проверку его добавляем.

Загуглили, как работает алгоритм цикломатической сложности – описали его – и вот, у нас уже есть в АПК цикломатическая сложность.

Опять же, эта проблема должна назреть, что она действительно нужна. И именно в таком эволюционном подходе можно под себя программный продукт подстраивать. Тем более, вы никаких дополнительных денег не тратите, и качественный результат (лучше, чем совсем ничего не делать) – получаете. И тогда вы уже понимаете, нужно ли вам использовать SonarQube.

То, что я рассказывал – это статичный вариант, он больше подходит под проекты – мы где-то развернули эту инфраструктуру, она у нас работает, мы получаем какие-то метрики. Но большинство франчайзи ведь не про это. Есть еще огромный пласт клиентов – это представители малого и среднего бизнеса, базы которых не развернуты на ваших серверах, которым это и не требуется. Доработки случаются не так часто. Но проверять, тем не менее, хочется. Что можно здесь сделать? Это как раз веб-интерфейс.

Можно посмотреть на Инфостарте слово Code Review и первые пять статей вам расскажут много интересных вещей про это Code Review.

Например, есть статья, как сделать веб-интерфейс при помощи одного расширения к АПК. И вы уже сможете смотреть. Конечно, на это будут тратиться лицензии, но, тем не менее, вы сможете получить веб-интерфейс. Это обработка, публикуете клиент. И ваши сотрудники могут туда закидывать куски кода и проверять. Очень удобно, когда в спешке что-то делаешь. И чтобы что-то не пропустить, и не накосячить. Вы можете это быстро проверить.

В Инфософте (компании, где я работал раньше) мы сделали достаточно простую формочку – человеку прямо сюда возвращался результат с проверкой кода, точно так же, как и в SonarQube, по строчкам.

В АПК есть один неприятный нюанс – он показывает только строку, где возникла проблема. Не в контексте модуля в целом, а только одну строчку. А в веб-форме расширения, про которое я говорил, можно реализовать просмотр модуля в целом. И вы будете видеть результат точно так же, как и в SonarQube.

Заключение

Давайте теперь поговорим о достаточности. Что мы хотим – улучшить качество или внедрить SonarQube? Это вопросы, на которые стоит ответить.

Мне АПК был более интересен тем, что его можно было дорабатывать под свои нужды и требования, и делать это эволюционно.

Понятно, что есть компании, у которых более 200 разработчиков, и там без SonarQube просто не обойтись, тем более, если использовать определенный плагин, который включает большинство проверок АПК.

А если вы просто хотите повышать качество кода в какой-то определенный момент времени, можно попробовать АПК.

Вопросы:

• Вы говорите, что проверяете задачи своих разработчиков выборочно. А если вы проверяете только одну из десяти задач, и нашли в ней какую-то недоработку, то там, где вы ее нашли, он эту недоработку исправит, а в остальных девяти?
• Здесь у нас два пути решения. Либо мы ему говорим: «Везде это исправляй». Чаще всего мы так и говорим, что надо исправить везде. Но если этого не требуется, и мы просто на будущее хотим планомерно повышать квалификацию специалиста – мы говорим: «В будущем так не делай». Мы ведь проверяем сданные задачи. Она в Production уже ушла. Смотря какую задачу вы решаете. Либо вы решаете то, что он прямо сейчас должен все исправить. Либо чтобы он в будущем так не делал. Но мне на определенных этапах казалось, что гораздо более ценно, чтобы он в будущем так не делал. То, что он в будущем этого делать не будет – это гораздо более ценно, чем если он в этих десяти доработках эту ошибку исправит.
• То есть для вас не критично, что в будущем какой-то другой разработчик скажет – здесь в девяти местах написано так – я сделал по примеру. В чем проблема?
• А этот вопрос уже отдается на рефакторинг. У нас есть специальные люди, которые занимаются рефакторингом периодически – ищут такие проблемы и их исправляют. Это, опять же, опытные сотрудники. У нас есть конкретный релиз, на котором мы исправляем технический долг. Но смысл заключается в том, что ты можешь, конечно, за всеми все исправлять, но конечно лучше, чтобы они вообще в принципе этих ошибок не делали.
• Сколько у вас разработчиков работает в таком режиме?
• Сейчас 15.
• А что в SonarQube, что в АПК – показывается, каким программистом была допущена ошибка?
• Есть такая возможность в GitSync – определить по пользователю хранилища, но мы GitSync не пользуемся. Мы сейчас определяем по комментариям.
• Но АПК же может у хранилища узнать, кто сделал заливку?
• Может, если сделано под определенным пользователем. А если инфраструктура развернута у клиента, и к этому хранилищу подключен только один пользователь, под которым просто изменения в конфигурацию перекладываются – в таких случаях определить нельзя.
• То есть если мы заливаем изменения в АПК под разными пользователями, то видим, чья ошибка, а в SonarQube без «плясок с бубном» нельзя узнать?
• В GitSync есть ini-файл, который связывает пользователей хранилища конфигурации с пользователем в Git. А Sonar цепляет замечания по данным, полученным из Git. Он смотрит на сам файл, берет git blame и по каждой строке проверяет – кто виноват. В GitSync ничего дополнительно колдовать не нужно. Это одна опция.
• Расскажите, какой инструмент Code Review вы используете? Где вы сравниваете cf-файлы конфигурации? Как вы это проводите?
• В конфигураторе проверяем. Мы на EDT не перешли, мы в конфигураторе проверяем. Смотрите, как это работает. У нас есть трекер задач. В трекере задач случайным образом выбирается несколько задач. Обязательно при входе сотрудник точно знает, что это нужно комментировать. Соответственно, ты по комментариям проверяешь, запускаешь и выясняешь, где эти ошибки были сделаны. Пока этот процесс у нас на таком уровне. Дальше мы пока не пошли.
• А у вас продукта Atlassian нет в компании? Потому что у них хорошая связка получается – Jira+Cruisible. Удобные инструменты.
• Пока нет. Я рассказываю на том уровне, на котором мы сейчас. У нас есть обычный трекер задач, написанный на 1С. Пока Atlassian у нас нет, чтобы эти вопросы решать. Пока мы можем только так это сделать. Пока этого достаточно. Опять же, я уже говорил – нужен эволюционный подход. Если на определенных этапах без этого уже будет нельзя – мы перейдем на Atlassian. Но пока мы и так справляемся.
• У меня дополнение – цикломатическая сложность – тоже есть на Инфостарте обработка. Это все можно использовать. Более того, на Инфостарте есть платный TurboConf, в который можно встроить вызов HTTP-сервиса для проверки всего модуля (в EDT так тоже можно сделать).
• Мы пробовали TurboConf – да, прикольная штука.
• По результатам Code Review разработчик сразу дорабатывает свой код, или же это производится потом?
• Все в зависимости от того, как именно это можно сделать. Тут не стоит применять какое-то конкретное решение – либо так, либо так. Все от ситуации. Мы стараемся делать все сразу, пока это в голове есть. Тем более, мы проводим это раз в две недели, чтобы сильно не нагружать разработчиков, которые будут это проверять. Соответственно, за две недели у человека из головы еще не вылетело, что он там делал, он может это оперативно поправить. Не прямо сейчас, а в течение дня, в течение двух дней.
• А еще вопрос – семинары для новых сотрудников проводятся какие-нибудь у вас внутри компании, на которых вы объясняете, почему у вас такие стандарты, почему вы придерживаетесь тех или иных правил?
• Конечно, эти семинары провожу я сам. А для вновь прибывших сотрудников у нас проходит обязательный вводный инструктаж. Понятное дело, что на это нельзя потратить несколько дней. Но мы потом проводим вводный инструктаж по предметным областям – начиная с комментариев, со стандартов и т.д. Эта практика делается регулярно. Мы это обновляем. Понятное дело, что это никакая не статика. Мы, допустим, поработали так месяц – и к нам пришла обратная связь, что вот это и это нужно добавить, а это выбросить.
• Вы собираете статистику по результатам Code Review? Например, что у вас такой-то сотрудник получил столько-то баллов, другой – столько-то. Ранжирование сотрудников по результатам ведете?
• Мы ставим галочки, но подробную статистику все-таки не ведем. Потому что у нас цель направлена именно на обучение, а не на порицание. Понятное дело, что есть соблазн, особенно у руководства, поставить все на учет, чтобы понять, кто развивается, а кто нет. Но программисты-то видят – у кого есть результат, а у кого – нет.
• Но здесь не обязательно должно быть порицание. Здесь можно сделать доску почета, что эти двое у нас без отрицательных результатов Code Review, и они молодцы.
• У нас есть такие сотрудники, они же и проверяют. Тот, кто владеет доской почета – владеет компанией.
• Вы упомянули о том, что SonarQube –платный.
• На тот момент, когда я узнал о плагине к SonarQube, он был только у одной компании, и был только платным. Сейчас он есть бесплатный – есть OpenSource-плагин с поддержкой комьюнити. Но плагин же написана на Java, его нужно поддерживать и дорабатывать. Если у вас компетенции по его доработке – тогда да. А если вам, допустим, нужно доработать прямо здесь и сейчас, и компетенций в Java-разработке нет – тогда АПК. Мы пока в эту сторону склонились. Возможно потом, когда плагин наберет в весе, будем использовать другой.
• У вас ревьюеры – это только опытные сотрудники, которые смотрят за новичками? Или бывает и обратная схема?
• Хороший вопрос. Опять же, кто сказал, что опытные сотрудники не косячат? У нас есть сотрудники, которые по определенным параметрам не дотягивают до топовых, их проверяют ведущие разработчики или тимлиды. А потом они проверяют друг друга.
• На презентации было написано, что нужно придумать, как это продать клиенту. Если это франчайзи, и клиент привык работать без проверки кода – как можно продать ему то, что это теперь будет дороже, но качественнее? Как клиенту объяснить?
• Как это объяснить клиенту – я не знаю. Я в докладе старался акцентировать внимание, что объяснять не придется – затраты на это Code Review вообще минимальные. У нас часа четыре на всех разработчиков за две недели тратится. Кажется, что Code Review – это сложный процесс. Что ты должен на 100% погрузиться и разобраться. Да, в некоторых случаях это действительно требуется. Но в большинстве случаев, когда опытный разработчик смотрит код разработчика, который уровнем ниже, он видит все сразу же. Вы же сразу видите – предложение написано с ошибками или нет, с запятыми или нет. Точно так же оно и работает.

****************

Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.