Чому написання ідеального коду може призвести до вашого звільнення

Блогер та розробник Джозеф Круз розповів, чому не варто писати ідеальний код та чому це не вигідно.

Пропонуємо вам переклад його його авторського блогу від нашої редакції. Далі — слово автору.

Мабуть, ніхто не буде сперечатися з тим, що програмний код повинен бути чистим і не мати «запаху коду», а патерни проектування і TDD повинні стати вірними супутниками будь-якого більш-менш грамотного розробника протягом всієї його непростої, але продуктивної кар’єри.

Всі також знають, що вартість помилки у виробництві зростає в десятки разів і що хороші програмісти оптимізують код, а погані — купують нові сервери.

Було б нерозумно стверджувати, що писати хороший код — це неправильно. Більше того, серед моїх попередніх публікацій уважний читач знайде цілу серію статей на тему ідеального коду.

Але я вирішив написати цю замітку тому, що останнім часом часто стикаюся з ідеалізацією процесу розробки і порадами в стилі «мені начхати на все, головне — ідеальний код». Нижче кілька спостережень та історій з життя.

Аутсорсерам вигідно писати паскудний код

Що тут приховувати? Більшість успішних компаній, що працюють на локальних ринках, є аутсорсерами, які, як відомо, заробляють гроші, надаючи послуги зовнішнім замовникам. Якщо ціна фіксована, ще є надія, що код буде написаний правильно, але час і матеріали обмежені. Одного разу була така ситуація: ми тиждень робили один функціонал, два дні його переробляли, потім повернули все як було, і тут прийшло технічне завдання.

На моє резонне запитання, чому я не міг дочекатися специфікацій, а потім писати, я отримав дуже резонну відповідь: ти отримав гроші за те, що зробив, і за те, що переробив, чому ти незадоволений?

Я знаю випадки, коли розробники навмисно створювали баги в системі, щоб потім отримати додаткове замовлення на підтримку. В одній з попередніх компаній хлопець називав свою роль «багмейкер»! Він дуже пишався цим, бо не давав розслабитися ще трьом розробникам і двом тестувальникам.

Пишіть хороший код — вас можуть звільнити!

Це звучить абсолютно жахливо, але ви нічого не вигадуєте. Хороший розробник і сильний архітектор завжди (?) є цінними працівниками, але в деяких випадках (наприклад, у фрілансі або якщо ви підрядник) вас можуть позбутися, як тільки ви виконаєте всю складну роботу і навчите індійських працівників методично розфарбовувати код у правильному порядку. Я жартую? Ні.

А як же підтримка, нові розробки? Тут все дуже просто. Багато компаній живуть за рахунок одного замовника і роблять все (абсолютно все), що він скаже, бо його відхід = кінець компанії.

Тому в такій війні всі засоби хороші. Навіщо зв’язуватися з такими компаніями? У короткостроковій перспективі вони можуть бути набагато вигіднішими через жорсткі дедлайни, брак ресурсів і примхи керівництва.

Рефакторинг заради рефакторингу

Мабуть, це проблема всіх хороших (або потенційно хороших) розробників: Викинути все і написати заново! Додайте до цього синдром «Не тут придумали», і ми отримаємо повний набір проблем для менеджменту та замовника. Адже розробники на чолі з тімлідом не вирішують бізнес-задачу, а грають у гру під назвою «ідеальний код».

Іноді вам доводиться писати поганий код

Наприклад, якщо ви пишете прототип, тестуєте ідею або займаєтеся дослідженнями та розробкою. У таких випадках ідеальний код з трирівневим ООП на вершині TDD з Agile — це скоріше ворог, ніж помічник. Тому що завдання — перевірити гіпотезу, здогадку, заощадити час в майбутньому на виправлення архітектурних або функціональних багів.

Чому досі вважається, що потрібно писати ідеальний код?

Аргумент тих, хто каже, що потрібно писати ідеальний код, найчастіше базується на тому, що паршивий код складно підтримувати в майбутньому. Ментальна помилка полягає в тому, що найчастіше код не потрібно підтримувати, або це буде хтось інший, хто повинен буде його підтримувати. Тому, з точки зору бізнесу, написання ідеального коду — непотрібна трата часу і ресурсів.

В одній з компаній, перш ніж сідати писати кошторис проекту і комерційну заявку, я (в обхід керівництва) завжди запитував замовника: виберіть бажаний тип кошторису з трьох варіантів «дешевше, але швидше», «працює — не чіпайте», «ми робимо правильно». Залежно від побажань клієнта бюджет збільшувався в 2-5 разів, але я відразу розумів, як ми будемо писати.

Друга проблема — постійне невдоволення розробника своїм кодом. Місячний код хочеться спалити, піврічний з’їсти, а через код, написаний три роки тому, когось вбити.

Не потрібно писати поганий код навмисно

Тільки за розрахунком!

В одному проекті для дуже відомого замовника на початку роботи не було жодних вимог щодо конвенцій коду. Не піддавшись на таку халяву, команда встановила дуже конкретні, суворі правила і регулярний перегляд коду.

В результаті, за тиждень до здачі проекту замовники остаточно розлютилися і викотили кодову конвенцію, що приголомшило менеджмент (і мене теж, оскільки я повинен був здати продукт). Однак завдяки контролю з самого початку проекту всі доопрацювання зайняли максимум один день.

У кожного свої приклади і антиприклади, але, думаю, всі погодяться, що розробник, а особливо професійний, повинен бути прагматиком, а вже потім архітектором-космонавтом або фанатом ідеально чистого коду. Змусьте себе написати хоча б один проект «правильно», і тоді ви просто не зможете робити це по-іншому.