Журнал DZone собрал отзывы экспертов от ИТ по поводу того, как раз и навсегда покончить с плохим кодом. Делимся с вами переводом этого материала.
Первый шаг
«Компьютеры не наделяет смыслом переменные или другие семантические конструкции. Вместо этого они только хранят биты в регистрах и передают данные по шинам. Слишком часто мы совершаем ошибку при написании кода — его может понять компьютер, но не человек.
Мы сокращаем имена переменных, создаем загадочные структуры и даже добавляем комментарии, чтобы скрыть истинную природу нашего кода. Если мы хотим писать лучший код, нам нужно сосредоточиться на написании кода для людей. Будь то сотрудник в нашем офисе, участник open source проекта, находящийся за километры от нас, или мы сами... люди — это те, кто являются читателями кода.
Один из лучших способов написать хороший код — это написать код для аудитории из людей. Мы должны изменить подход и писать код так, как если бы это была книга: книга, которая читается сверху вниз и рассказывает историю решаемой проблемы. Эта книга использует имена переменных, методов, классов, условные операторы и другие вещи в качестве предложений, абзацев и глав. С их помощью человек может понять, как наше приложение решает проблему.
Это больше искусство, чем наука, и требует немалой дисциплины и практики, но приносит огромные дивиденды. Всегда пишите код так, чтобы незнакомец прочитал его и легко определил, что именно с ним можно достичь».
Джастин Альбано, Software Engineer и Catalogic Software
Шаг второй
«Меня вдохновляют альтернативные источники, когда я думаю над тем, как сократить количество плохого кода. Я чаще воспринимаю кодирование большее как искусство, а не как инженерию. Если мы позволим этому виду искусства вдохновиться другими видами искусства, такими как музыка, живопись, скульптура и т. д., больше людей смогут проникнуть в проблему.
Попробуйте задать себе вопросы: «Какой ритм имеет мой код», «Каков цветовой профиль этого конкретного фрагмента кода» и т. д. Это позволяет увидеть код как единое целое. Иначе код может предстать как множество деталей, соединенных вместе, в результате чего получится мозаика разных стилей.
Красивый код должен быть удивительно простым для понимания, а продукт в целом должен основываться на одной идее, и эта идея должна быть видна во всем продукте. В такой среде создание плохого кода становится практически невозможным. По сути, это стандартизирование способа создания кода.
Чтобы стандартизировать код и заставить его играть, убедитесь, что вы используете возможные инструменты везде, где их можно использовать».
Томас Хансен, главный распорядитель в Server Gardens
Шаг третий
«Работайте и учитесь вместе с другими. Большинство разработчиков увлечены своим делом. Прекрасный работник постоянно совершенствует свое мастерство. Он пробует новые вещи. То, что не сработало, воспринимается как ценный опыт. Разработчики, которые собираются вместе с другими разработчиками, всегда будут учиться друг у друга. Митапы и конференции предоставляют прекрасные возможности для обмена опытом и обучения.
Неважно, сколько у вас опыта. Это не улица с односторонним движением. Никогда не прекращайте изучать другие языки, стеки и инструменты.
Пусть инструменты делают рутину. Потратьте время на настройку IDE, редакторов, инструментов командной строки и т. д. Чем больше они совершенствуются, тем лучше можно сосредоточиться на реальной задаче — обеспечении функциональности.
Хорошие инструменты также выявляют проблемы и предлагают предложения. За этими идеями стоят десятилетия знаний. Не отказывайтесь от всех наблюдений, сделанных инструментами. Код будет лучше, люди, которые его используют, оценят усилия, а автор кода улучшит свои навыки».
Рэй Елентени, Главный Владелец Solutech Consulting
Шаг четвертый
«В нашей организации все, что делают программисты, это код. Но у нас есть небольшое количество разработчиков, которых мы не хороним в исправлениях багов. Мы даём им доступ к инструменту Dynatrace, и он помогает быстрее устранить проблемы. С DevOps теперь они больше взаимодействуют с операциями.
Продвижение с помощью инструмента Dynatrace в нашей компании началось с разработки программного обеспечения. Я включил их в него из-за способности продукта идентифицировать узкие места в коде.
Это экономит много времени для разработчиков. Затем мы развернули воспроизведение сеанса так, чтобы, когда у клиента есть проблема, он мог вызвать клиента во время воспроизведения сеанса и посмотреть, что происходит. Это позволяет идентифицировать узкую область, которая отказывает».
Марк Каплан, старший директор по информационным технологиям в BARBRI
Шаг пятый
«Надеемся, у вас есть какой-то автоматизированный процесс, который создаёт, развертывает и запускает тесты.
С Dynatrace, каждый раз, когда вы развертываете и тестируете инкремент, мы отслеживаем все. Мы отслеживаем время отклика, потребление ресурсов, а также архитектурные KPI. Мы отслеживаем множество запросов и хотим, чтобы разработчик видел это. Таким образом возможно отследить незапланированное поведение и не плодить баги.
Вы просматриваете сборку сборкой и затем автоматически говорите: «Эй, что-то не так, вы увеличили количество обращений к базе данных на 50% и включили две новые зависимости. Вы действительно хотите внедрить это в работу? Да или нет?» Это останавливает плохой код, а также изменения конфигурации и архитектуры до того, как они попадут на продакшн.
Лучше всего, если вы не только делаете это перед релизом, но и интегрируете проверки в цикл сборки каждого коммита. С каждым созданным вами коммитом вы запускаете несколько значимых тестов и смотрите на метрики, проводите проверку SLI и SLO не только на стандартных показателях производительности, но и на этих показателях архитектуры и масштабируемости.
Энди, активист DevOps в Dynatrace
Резюме
- Автоматизируйте все, что вы можете автоматизировать.
- Относитесь к коду как к искусству.
- Сотрудничайте с другими и учитесь у них.
- Пишите красивый код, который могут понять люди.
- Используйте правильные инструменты, чтобы стать лучше.