Мы все слышали о красивом коде.
Книги и страницы специализированных ресурсов полны рекомендаций, стандартов и просто хороших советов.
Современные языки предлагают множество способов изящного выражения идей разработчика.
В целом все хорошо.
Вроде, как бы, что-то вроде.
Но реальная жизнь сурова.
По ряду вполне объективных причин только самые удачливые из нас имеют возможность работать с по-настоящему качественной кодовой базой.
Большинство, зная почти все подробности идеального способа работы, живут здесь и сейчас, за пределами рая, довольствуясь тем, что имеют. Но как сделать свою жизнь лучше? Как повысить уровень качества вашего кода.
Приведу несколько своих правил и мыслей на эту тему.
1. Полная осознанность совершаемых действий.
Необходимо требовать от программистов полного понимания каждой написанной строки кода.
Правило звучит очень просто: «Не понимаю, почему это сработало — не запихивать изменения в общее хранилище» .
В последнее время я уделяю особое внимание случайным реализациям.
Распознать их довольно легко: причудливый дизайн, отсутствие комментариев или тщательно расплывчатые формулировки.
Самый верный способ — попросить программиста объяснить механизм реализации подозрительного функционала.
Результаты наблюдений выглядят устрашающе — почти весь «бессознательный» функционал содержит ошибки, которые проявляются практически мгновенно.
Причем чаще всего это оказываются так называемые четные баги, когда исправляешь неправильный раздел и понимаешь, что только благодаря ему все остальное работало хотя бы примерно правильно.
Плюсы: Осознавая проделанную работу, а не просто добиваясь результатов, близких к истине, программисты растут профессионально.
Количество ошибок также уменьшается, причем большинство из них по сложности исправления находятся на уровне банальных опечаток.
Реализация оказывается оптимальнее, проще и понятнее — алгоритм легко читается даже без дополнительной документации и комментариев.
Минусы.
Это отнимает очень много времени.
Особенно если уровень программистов не очень высок.
Костыли плохо впишутся в коллектив, который слишком тщательно придерживается этого правила.
И это не так уж хорошо: в трудные времена (например, когда нужно срочно подготовить продукт к выпуску) пара любителей качественных костылей просто необходима.
И даже в спокойное время они помогут команде не застревать надолго в аналитических тупиках.
2. Наличие четких рамок допустимого зла.
Иногда приходится поддаваться идеалам и пропускать не совсем качественный код. Еще хуже.
Постоянно приходится идти на определенные уступки – жизнь жестока и несправедлива.
Однако нужно иметь четкие рамки, за которыми нет-нет. Так, в стрессовые периоды на несоблюдение интервалов и правил наименования можно закрывать глаза, но опасную халатность лучше пресекать резко и жестоко, даже если это как-то работает и сроки сжаты.
Плюсы.
Если вы чувствуете, что реализация некорректна, несмотря на видимость корректной работы, необходимо ее исправить.
Потому что, во-первых, напряжение в ответственные моменты и так велико – еще не хватает мук совести и накопления негатива.
Во-вторых, доставить продукт – это, конечно, основная цель, но свои основные функции он должен выполнять.
Одно дело выпустить приложение с рядом мелких недоработок, а другое — порадовать заказчика бесполезным куском скомпилированного кода.
Не знаю, плюс это или минус, но без развитого инстинкта не обойтись.
Как и без набивных шишек.
Но я все равно оставлю это в плюсе.
Минусы.
Нужно быть готовым к давлению, как снизу, так и сверху.
Как же так — это нужно делать быстро, а команда отвлекается на доводку дел.
Без потери нервов не обойтись.
Кроме того, вы можете сильно пострадать, если проект потерпит неудачу.
Короче говоря, это полный риск.
3. Откровенность.
Допустим, человек не способен полностью осознанно решать проблемы.
Возможно, просто нет времени делать все правильно — некоторые параметры пришлось выбирать наугад. Или правильное решение слишком сложное — проще сделать упрощенный вариант и подкрепить его парой костылей.
Это происходит гораздо чаще, чем хотелось бы.
Но просто примириться недостаточно.
Гораздо лучше культивировать в коллективе открытость.
Если у вас это получилось не очень хорошо, признайте это в комментарии, в тексте описания коммита, а еще лучше оставьте запись в системе управления проектом.
Естественно, никакого наказания за признания быть не должно.
Плюсы.
Хорошие времена случаются: чем больше подсказок осталось, тем больше шансов, что незавершенные задачи будут возвращены и выполнены правильно.
Даже если не вернутся, честный комментарий-предупреждение сэкономит другим программистам много времени и нервов в будущем, если не на исправлении ошибки, то хотя бы на ее поиске.
Человеку лучше научиться что функция парсинга файлов не полностью поддерживает некоторые свои форматы из описания этой функции, то после недели странных проблем он поймет это сам.
К тому же всегда есть шанс, что, допустив недочет, автор устыдится и переделает хорошо.
Минусы.
Потерять контроль очень легко – сотрудники могут привыкнуть к тому, что достаточно признаться в косяке и за это ничего платить не придется.
Здесь все снова сводится к инстинктам менеджера.
Дефекты не должны превращаться в «ароматные» кучи гуано, гордо разбросанные по всему проекту.
Иными словами, главная трудность такого подхода – правильная дозировка безнаказанности.
Конечно, ни одно правило ничего не гарантирует. Кроме того, каждый из них допускает эксцессы, способные свести на нет любой положительный результат. Но что-то нужно делать.
И начнем с признания проблемы: Идеально, наверное, не получится, но надо стремиться использовать ресурсы максимально эффективно.
.
Теги: #программирование #программисты #культура программирования #управление проектами и командой #программирование
-
Алгоритмы Сдачи Егэ В Шад
19 Oct, 24 -
Не Знаю, Как Учиться Или Искать Партнёра?
19 Oct, 24 -
Новый Игровой Ноутбук.
19 Oct, 24 -
Местное Содержимое
19 Oct, 24
