Как повысить качество кода

Все мы наслышаны о красивом коде. Книги и страницы специализированных ресурсов пестрят рекомендациями, стандартами и просто хорошими советами. Современные языки предлагают множество путей изящного выражения идей разработчика. Вообще все хорошо. Вроде бы. Но реальная жизнь сурова. По ряду вполне объективных причин только самые счастливые из нас имеют возможность работать с действительно качественной кодовой базой. Большинство же, зная чуть ли не все подробности идеального способа работы, живут здесь и сейчас, за пределами рая, довольствуясь имеющимся.

Но как сделать свою жизнь лучше? Как заставить уровень качества кода расти. Приведу несколько собственных правил-размышлений на эту тему.

1.Полная осознанность выполняемых действий.

Нужно требовать от программистов полного осознания каждой написанной строчки кода. Правило звучит очень просто: «Не понял, почему заработало — не проталкивай изменения в общее хранилище». В последнее время я уделяю особое внимание реализациям «наугад». Распознать их достаточно просто: вычурные конструкции, отсутствие комментариев или их старательно размытые формулировки… Самый точный способ — попросить программиста объяснить механизм реализации подозрительной функциональности.

Результаты наблюдений выглядят пугающе — почти вся «неосознанная» функциональность содержит ошибки, которые проявляются практически мгновенно. Причем чаще всего это оказываются так называемые четные баги, когда исправляешь неверный участок и понимаешь, что только благодаря ему все остальное работало хоть приблизительно правильно.

Плюсы: осознавая выполненную работу, а не просто добиваясь похожих на правду результатов, программисты растут профессионально. Количество ошибок также уменьшается, причем большинство из них по сложности исправления лежит на уровне банальных опечаток. Реализация получается более оптимальной, простой и наглядной — алгоритм легко читается даже без дополнительной документации или комментариев.

Минусы. По времени это очень затратно. Особенно если уровень программистов не сильно высок. Костыльщики будут плохо приживаться в команде, где слишком старательно придерживаются этого правила. И это не так уж и хорошо: в тяжелые времена (например, когда нужно срочно готовить продукт к релизу) пара качественных любителей костылей жизненно необходимы. Да и в спокойные времена они будут помогать коллективу не застревать слишком подолгу в аналитических тупиках.

2. Наличие четких рамок допустимого зла.

Иногда приходится уступить идеалам и пропустить не вполне качественный код. Даже еще хуже. Постоянно приходится идти на те или иные уступки — жизнь жестока и несправедлива. Однако нужно иметь четкие пределы, дальше которых ни-ни. Так, в напряженные периоды, можно смотреть сквозь пальцы на несоблюдение интервалов и правил именования, но опасные небрежности лучше пресекать резко и жестоко, даже если оно как-то работает и сроки жмут.

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

Минусы. Нужно быть готовым к давлению, как снизу, так и сверху. Как же так — нужно скорее, а команда отвлекается на наведение блеска. Без потери нервов не обойтись. К тому же можно сильно подставиться в случае неудачи проекта. Короче, сплошной риск.

3. Откровенность.

Допустим, человек неспособен решать задачи полностью осознанно. Может, просто нет времени сделать правильно — часть параметров пришлось подобрать методом тыка. Или правильное решение слишком сложно — проще сделать упрощенный вариант и подпереть его парой костылей. Такое бывает гораздо чаще, чем этого хочется. Но просто смириться мало. Гораздо лучше культивировать в команде откровенность. Сделал не очень хорошо — признайся в этом в комментарии, тексте описания коммита, а еще лучше, оставь запись в системе управления проектами.

Естественно, наказаний за признания быть не должно.

Плюсы. Хорошие времена случаются, чем больше зацепок будет оставлено, тем больше шансов, что к незаконченным задачам вернутся и сделают все правильно. Даже если не вернутся — честный предупреждающий комментарий сэкономит в будущем много времени и нервов другим программистам, если не на исправление ошибки, то хотя бы на ее поиск… Лучше человек узнает о том, что функция разбора файла не полностью поддерживает некоторые его форматы, из описания этой функции, чем после недели странных проблем поймет это сам. К тому же всегда есть шанс, что, признаваясь в недоделке, автор устыдится и переделает хорошо.

Минусы. Очень легко потерять контроль — сотрудники могут привыкнуть, что достаточно признаться в косяке, чтобы тебе за это ничего не было. Здесь все снова упирается в чутье руководителя. Недоделки не должны превращаться в «ароматные» кучки гуано, гордо разбросанные по всему проекту. Другими словами, основная сложность данного подхода — правильная дозировка безнаказанности.

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