В одній з компаній CEO мав звичку спілкуватися з розробниками, намагаючись прикинутися не аби яким експертом в ІТ і посилаючись на те, що першу версію системи він розробив самостійно (що не правда) та на те, що його батько працює якимось профессором у Утрехті. Під час однієї з таких розмов я розповів йому, що код проєкта – лайно і що ми маємо усе переписати з нуля, заново зібравши вимоги, оскільки вони не очевидні з наявного коду та оскільки ~70% коду є мертвим, як і більшість функціональності проєкта.
CEO на це відповів: Кожного разу, коли я наймаю розробників, то вони розповідають мені, що код – лайно.
– Справа у тому, що розробників, які писали той код більше немає, а останній, хто був до нього причетним звільнився з проєкта через місяць після того, як я вийшов на роботу. Ми втратили усі знання про проєкт і повернути більшість із них із самого коду неможливо, а решту дуже затратно по часу. Крім того, у різних розробників різні ментальні моделі. Вони користувалися одними, я користуюся іншими і мені чи будь-кому ще важко зрозуміти, чим вони насправді керувалися.
Моя відповідь здивувала CEO, певно тому, що він вважав, що це буде типове ниття та переведення відповідальності на попередників, але ж проблема була не у попередниках, як у тому, що їх не залишилося. В решті решт, CEO був специфічною людиною, дуже схильною і здатною до маніпуляцій, через що розробники дуже швидко звільнялися.
Якість коду
Більшість розробників постійно повторюють мантру про те, що якість кода – це в першу чергу легкість його читання та розуміння. Я не можу з цим погодитися, або конструктивно заперечити це, оскільки жодного разу не зустрічав код, який можна було легко прочитати та зрозуміти. Кожний проєкт на якому я працював мав жахливий як на мене код. Висновок до якого я можу дійти з усього свого досвіду розробки, це те, що будь-який код, який писав не я – гівно. Більше того, навіть код який був написаний мною, але до якого я тривалий час не торкався також був лайном.
І справа навіть не у тому, що за два тижні я ставав набагато кращим програмістом, а у тому, що його розуміння випаровувалось з моїх мізків і мені було необхідно знову витрачати багато часу аби завантижити його у власний RAM. То ж оновлена версія мого висновку може виглядати так: Поганий код – це код, який необхідно читати.
Про вирішення цієї проблеми я вже писав у Читати чи видаляти? Або: Вибачте, але ніхто не хоче читати Ваш код.
Бізнес не працює з кодом
… і тому не розуміє пов’язаних з ним проблем. Бізнес не розуміє чим програмування принципово відрізняється від більшості інших людьских діяльностей, не розуміє, що втрачає, коли розробник звільняється, не розуміє психології програмування, не розуміє, що код – це зафіксовані думки і декільком людям дуже важко потоваришувати свої думки.
Зі зміною складу команди код сильно деградує.
З відсутністю модульності і чітко закріпленої відповідальності за той чи інший модуль, випаровується його розуміння та контроль над ним.
Цього бізнес не розуміє, як, нажаль, і більшість розробників, які також слабо рефлексують над власним ремеслом. Програмування та розробка ПЗ – це не виключно механістична діяльність, як, скажімо, транспортування вантажів чи складський облік.
Залишити відповідь