Методологии производства мусора

27 August 2019

Последние две недели совершалось маленькое чудо. Я на разработку получил проект, позволяющий заниматься самореализацией в полный рост. Такое бывает редко, но, как оказалось, все-таки случается, и со своей группой мы кинулись в омут изучения и использования новых технологий. Ценой этой работы стало, разумеется, время и времени пописать что-то про свою индустрию или, уж тем более, про общество не осталось совсем. Но, как и в жизни, прошлое иногда возвращается, и снова возникают задачи, заставляющие окунуться в тот чан, из которого, казалось, ты хоть ненадолго вылез.

К чему всё это? Для себя я смог выделить 3 методологии работы, обнаружение которых является ярким маркером того что на проекте трэш, угар и содомия. И главная проблема не в том, что это методологии существуют и применяются, а в том, что разработчики считают такой процесс нормой. Или может это на самом деле норма, а я просто ворчун, матершинник и левак?

Методология №1 – «Путь наименьшего сопротивления». Звучит как что-то нормальное, правда ведь? Я уточню, что я имею в виду. Представьте, что вы обнаружили в проекте очевидную хрень. Очевидную любому студенту-первокуру хрень. И на вопрос – «А почему вы не хотите сделать нормально?» получаете ответ – рефакторинг займет слишком много ресурсов, а на выходе ничего полезного клиент не получит. Вот это вот оно. «Поскольку какаха слишком тяжелая, а лопатка слишком маленькая – пускай лежит и воняет, мы на ней построим завод по производству пердежа в баллончике». Как бороться с такой методологией? Очень сложно. На моей практике неплохо работает громкое публичное порицание защитников данного куска шмуца. В одночасье это не исправится с гарантией, но разбудить желание создать творить разумное доброе и вечное вполне реально. Кстати, если вопрос «А что получит клиент?» все же всплывет – у меня есть ответ. Он получит проект, который гораздо проще поддерживать, а, следовательно, снижается риск возникновения ошибок и время, затрачиваемое как на разработку новых фишек, так и на исправление ошибок.

Методология №2 – «Блин с лопаты». Представьте, что вы открыли блинную. Зажарили вкусный блин на лопате и метнули в лицо клиенту. Сказав в след – «если тебе будет вкусно, то в следующий раз дадим на тарелке». Слишком жестко? Ну, давайте дам более официальную формулировку – «Мы выдаем функционал в представленном виде, и если клиенты проявят интерес к нему, то произведем доработки для повышения удобства клиента». Так лучше? Если да, то не уверен, что поменялась суть. Руководство конечно теоретически может завернуть эту фичу, но у него выбор между «выдать это» и «потратить еще 2 недели на переделку». Т.е. второе потребует дополнительного расхода средств с туманной перспективой получить что-то лучше. Как с такой методологией бороться? Снова называем вещи своими именами. Пусть тестировщики громко эскалируют проблему о том, что разработчик сделал. Такое надо пресекать на максимально раннем этапе. В противном случае это превращается в какую-то вариацию «Стокгольмского синдрома» с сочувствием бездарю-разработчику или бездарю-аналитику.

Методология №3 – «Производство бумажного самолетика». Такую методологию, на моей практике, продвигает уже высокое руководство. Суть – если в компании есть пакет проектов, то 101% стоит необходимость в реализации простых, очевидных, базовых структур. Например, система управления правами доступа (т.е. клиент может управлять правами доступа в своем кабинете, так как ему это удобно), служба рассылки уведомлений, авторизационный гейт, панель администрирования для сотрудников тех. поддержки и т.д. и т.п. Выбора в реализации два. Реализовать «космический корабль», т.е. универсальную оттестированную систему, к которой будут интегрироваться все существующие проекты. Или «бумажный самолетик», т.е. отдать разработку такого бизнес-процесса на откуп разработчикам самого проекта. В глазах некоторых людей почему-то выглядит логичным разработка бумажного самолетика. Оправдание, которое слышал лично я – «разработка займет слишком много времени и слишком сложная система получится на выходе». Ну как бы – да. Система управления правами – вещь сложная, бесспорно. Только вот почему разработка одной гибкой и глобальной корпоративной системы это «сложно и дорого», а реализация одной и той же задачи из раза в раз на каждом новом проекте – это норма. Лично для меня это не норма. Как бороться? Искать единомышленников и продвигать эту идею. Другого пути нет. Смириться? Ну и будете заниматься разработкой методом «посмотри как там и сделай так же». Причем гарантий что «там» сделано хорошо и правильно примерно никаких.

Какой итог? Ну, если вы считаете, что в вашем проекте нет никаких проблем. Что он почти идеален, а то, что я тут написал – бред сумасшедшего. Я вас поздравляю – вы работаете в прекрасном месте. Ну, или просто не осознаете, что поддерживаете все описанные методологии и считаете это нормой. В любом случае извините что потратил ваше время на прочтение моих мыслей.