Я разработал большую и сложную систему около пяти лет назад. Я провел следующие пять лет, внедряя себя в каждый проект, который затрагивал «мою» систему, чтобы варвары не испортили мою архитектуру. Пока я оказывал постоянное, неослабное давление, мне удавалось сохранять архитектуру довольно чистой, но я сражался в проигрышном бою. И вот почему:
1) Большинство людей судят о том, выполнили ли они работу сегодня . Никто никогда не получал выговор, потому что они обрезали угол (или два) три года назад, чтобы вовремя выпустить проект. С другой стороны, многие люди получили выговор за то, что они вовремя не выпустили проекты.
2) Вы можете поддерживать систему в чистоте, потому что у вас есть чувство владения кодом, или приложением, или пользователями, и т. Д. У многих людей не будет чувства собственности, и поэтому они слишком счастливы взломать что-нибудь, чтобы они могли быть сделаны с этим. Вы можете привести лошадь к воде, но вы не можете заставить ее заботиться.
3) Если вы поступите , убедите всех в правильности работы с кодом, на его борту появятся новые люди, которых необходимо научить правильно делать вещи. Поэтому, даже если вы добились успеха, вы можете чувствовать, что терпите неудачу, потому что вы всегда сражаетесь в одной и той же битве с новыми противниками.
4) Вы можете ошибаться. Будет ли для Microsoft финансовым смысл тратить вдвое больше времени на программирование, делая MS-Paint надежным и обслуживаемым? Иногда уродливая взломанная система достаточно хороша. Большинству хороших программистов трудно понять это, но обычно это потому, что они хорошие программисты.
5) Клянусь, есть некоторые люди, которые получают извращенное удовольствие от совместной работы, потому что они могут делать это быстрее, или они будут единственными, кто понимает это, или у них есть детская потребность нарушать правила. Вы не можете рассуждать с этими людьми, и чем больше времени вы будете спорить с ними, тем ближе будет срок выполнения проекта, что в любом случае заставит вас что-то взломать.
6) Есть большая вероятность, что вы понимаете систему лучше, чем они. То, что вам кажется уродливым, может показаться «легким шагом» для человека, который не так хорошо знаком с системой. Или дополнительные усилия, направленные на то, чтобы сделать код устойчивым, защитят программиста от проблемы, которой у него никогда не было, и поэтому она не может быть взломана. Вы не научитесь проверять коды возврата, пока что-то пойдет не так, потому что вы не проверяли код возврата. В этот момент он перестает быть «дополнительной работой» и становится «необходимой работой».
Если у вас небольшая, тесная команда разработчиков, это возможно. Но чем больше организация, тем меньше у вас шансов на успех. Если вам удастся заставить ИТ-магазин на 250 человек ценить правильные действия, а не быстрые, то ваши убеждения легендарны.