Code-Quality

Фраза сидит в вашей кодовой базе как бомба замедленного действия с перегоревшим светодиодным таймером. Никто не помнит, кто её установил, зачем она там и когда стала «принятым порядком вещей». Но она есть — устаревшие шаблоны, архитектурные решения и процессы, которые с течением времени и из-за инерции учреждения превратились в абсолютную истину. Самая опасная фраза в инженерии — это не синтаксическая ошибка или исключение нулевого указателя. Она гораздо тише и коварнее: «Мы всегда делали это так»....

Когда вы впервые сталкиваетесь с линтером, который кричит на вас из-за несогласованных отступов в 15:00 в пятницу, это может казаться не столько полезным руководством, сколько наличием у вашего кода очень педантичного руководителя. И, честно говоря, у вас есть на это основания. Правила линтинга занимают особое место в разработке программного обеспечения — где-то между необходимой дисциплиной и чрезмерным контролем. Вопрос не в том, полезны ли линтеры (они явно полезны), а в том, когда соблюдение стандартов кодирования переходит черту от наилучшей практики к угнетающему надзору?...

В мире стартапов известна мантра: «Действуй быстро и ломай систему». Но где-то между эпохой быстрых действий и зрелостью предприятия мы коллективно решили, что все технические долги — это злодеи, ожидающие, чтобы нас уничтожить. Мы строили целые карьеры на ликвидации долгов, создавали заявки в JIRA с апокалиптическими описаниями и относились к каждому ярлыку как к поджогу кода. Ирония в том, что некоторых из самых успешных компаний в мире не существовало бы, если бы они не взяли на себя стратегический технический долг в нужный момент....

Мы любим говорить о техническом долге. Это монстр под нашей кроватью, виновник медленных спринтов и разочарованных разработчиков. «Нам нужно провести рефакторинг», — кричим мы. «Базовое кодовое хранилище — беспорядок!» — протестуем мы на ретроспективах. Но вот неудобная правда, которую никто на вашем последнем совещании по архитектуре не хотел услышать: иногда настоящий виновник — это не быстрые исправления и короткие пути. Иногда всё наоборот — мы создали нечто слишком хорошее для того, что на самом деле нужно было сделать....

Переполнение стека — это одновременно спасение и подозреваемый злодей в современной разработке программного обеспечения. Это тот друг, который всегда знает ответ в 2 часа ночи, когда вы отлаживаете регулярное выражение, которое, как вам кажется, вообще не должно существовать. Но где-то в коридоре исполнительной власти кто-то в пиджаке, вероятно, ходит взад и вперёд, бормоча о «защите интеллектуальной собственности» и «несанкционированном заимствовании кода». Стоит ли компаниям запрещать использование Stack Overflow? Давайте поговорим о том, почему это всё равно что запретить Википедию, чтобы предотвратить плагиат — это временное решение, которое не устраняет реальную проблему....