6 способов угодить в ад готовых решений и спустить миллион-другой



Привет, сейчас я расскажу тебе, что будет с перспективным проектом, если с самого начала обратиться к готовым решениям а-ля Wordpress, Open Cart и любым CMS, думая, что это и есть MVP. Основываться буду на трёхмесячном опыте работы на одном из проектов, в GitHub которого за предыдущие 8 месяцев так и не упало ни одного коммита в production ветку.

Рецепт раздутого ВП/OC/CMS до геостационарной орбиты


1. Выбираем любую готовую CMS


Ни в коем случае не зовите архитекторов и забудьте про микросервисы и архитектуру, рассчитанную под ваши потребности. Наша задача — сделать так, чтобы можно было крутить админку уже через 5 минут после того, как разработчик включил ПК, а не сделать простую в управлении разработку. Настоящий MVP должен состоять исключительно из готовых решений. Ведь именно в нашем проекте плагины никогда не будут конфиликтовать и уже рассчитаны на нагрузки любых интенсивностей.

2. Запрещайте документировать что бы то ни было


Ни одна cms не нуждается в документировании. Запрещайте документировать что угодно. Особенно модификации ядра. Ведь уже через 3 месяца фрилансер превращается в хранителя сакральных знаний о том, как работает вот этот изумрудный пельмень, и магическими техниками запуска сервера, который, естественно, один, и с момента первоначальной установки набора утилит его никто не пересоздавал. Залог достойного менеджмента — зависимость от сотрудников и, конечно же, от единственного работающего сервера.

3. Зовите ГУРУ!


После того, как фиксы конфликтов между 234 и 417 плагином стали занимать хотя бы в 10 раз больше времени, чем внедрение новых функций, ваш верный путь — искать ГУРУ, умудрённого опытом, который без особых усилий за неделю отрефакторит (перепишет) немножко кода, и очередные 500 плагинов займут законное место. К слову, мне и «посчастливилось» побывать в роли гуру, который вертит технологиями, а потому это реальная история болезни.

4. Ваш проект должен состоять из одной зоны ответственности


На микросервисы мы благополучно и осознанно положили с самого начала, и через 5 месяцев пора нанять нового программиста. И пусть он будет отвечать за вёрстку. Ну и ещё чуть-чуть за backend, ведь они у нас перемешаны. Ну и за базы данных, ведь как отвечать за backend без баз данных. Ну и за фиксы пусть ещё отвечает. И ещё… и ещё… и ещё…

5. Trello + Jira + Slack + Excel +… + Skype


Благодаря добрым полутора тысячам плагинов, которые УЖЕ есть, примерно каждый день находится по 5 ошибок, разрешение которых требует по 2 дня. Скорость написания фич падает в геометрической прогрессии. Очевидно, что нас кидают на время разрабы. И нужно ввести третий менеджер задач. (Да, клинические проекты обычно имеют от двух менеджеров задач). Trello, Jira и Excel — это лишь фундамент контроля. Некоторые мастера пользуются ещё и внутри-корпоративными task менеджерами, закреплёнными сообщениями в чатах и внеплановыми внезапными указаниями.

6. Стенограммы голосовых конференций


Разрабы водят нас за нос, а потому все голосовые конференции по согласованию багфиксов необходимо архивировать, сохранять на облако и регулярно переслушивать. Ведь дело всегда в разрабах…

Совет 1: Тестирование прошло успешно — срочно выбрасывай готовые решения и пиши подходящую архитектуру.

Совет 2: Если ты не просто замотивированный стартапер и имеешь либо ресурсы, либо финансовую стратегию, то обязательно включай в неё именно написание с нуля. Да и вообще отдай это дело профессионалам или техническому директору. (Важно, чтобы это был программист, а не профессор из НИИ, иначе перфокарт не оберёшься)

Что делать, если УЖЕ и ты главный?
– Переписывать.

Что делать, если УЖЕ и ты не главный?
– Объяснить суть проблемы руководству и переписывать.

P.S. В проекте использовался Yii2, но даже с ним были эти проблемы. Что происходит с WP – это катастрофа вовсе.

P.P.S. Причина, конечно же, в некомпетентности менеджмента, хотя монолитная архитектура также не стоит в стороне.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 11

    +2
    Совет 1: Тестирование прошло успешно — срочно выбрасывай готовые решения и пиши подходящую архитектуру.

    Это вы серьезно или имеет место сарказм? А то я что-то теряюсь.
      +2
      Это вы серьезно или имеет место сарказм? А то я что-то теряюсь.
      Вот, я тоже не понял.

      Готовые решения — типа того же сверх-популярного WP — имеют то преимущество, что по ним всегда можно найти информацию. Если у тебя есть проблема — скорее всего, с ней уже кто-то сталкивался, это уже где-то обсуждалось, что-то предлагалось и т.д. Вплоть до того, что эта проблема может быть (и, очень вероятно так) уже кем-то давно решена. Нужно лишь ознакомиться с этим решением и его использовать.

      А чтобы 100500 плагинов не конфликтовали — не нужно набирать такую их армию, если не понимаешь (и / или не хочешь / не можешь понять) как они работают. Ну, в крайнем случае, свой плагин можно написать. В чём проблема-то? В разводе заказчика на разработку «с нуля» по соответствующим расценкам?
      +2

      На хабре сезон статей "менеджмент пожадничал выбрасывать MVP/прототип"

        +2
        >Ни в коем случае не зовите архитекторов и забудьте про микросервисы и архитектуру, рассчитанную под ваши потребности
        Начинать с микросервисов — оверкилл, особенно с 1 разработчиком
        Так что совет как-то наполовину вредный
          0
          Судя по заголовку «6 способов угодить в ад», все эти 6 способов вредные)
            0

            Начинать с них — да. А вот сразу делать проект максимально готовый к переходу на них — хорошая идея. При том и вордпресс может быть частью такой архитектуры, пускай не микро, но сервисом

              0
              проблема микросервисов только в инфраструктуре, если есть готовое решение для мониторинга, выкладки, распределения нагрузки, обработки отказов, то почему нет?
              istio — что то такое обещает.
              Но на самом деле до всяких микросервисов, надо формализовать бизнес процессы и уже их растаскивать по модулям и сервисам или дробить до микросервисов.
              0

              Мне вот кажется проблема у Вас не в том что какое-то «не такое» решение выбрали изначально (оно ведь работало!), а в том что проморгали момент когда надо было перейти от «мы ж стартап, фигак в прод и ладно» к «мы ж энтерпрайз». Причём на этапе перехода надо понимать что таки нет — ещё не энтерпрайз.


              Я не прав?

                0

                ИМХО с микросервисами на ранних стадиях (проверка гипотез ценности и роста стартапа) огребли бы то же самое плюс проблемы с деплоем, мониторингом, консистентностью, траблшутингом межсервисного взаимодействия и e2e тестированием. Я не против микросервисов, но в условиях аврала, неопределенности и бардака в процессах (судя по описанным вами остальным пунктам) они бы вас потопили.

                  0
                  Пост о том как нехорошо использовать CMS основывающийся на опыте использования фреймворка Yii2, так так очень интересно.
                  Какие там плагины будет конфликтовать и кто запрещает писать документацию. Сам Yii прекрасно документирован, не разу не видел на сайтах Yii или какой либо cms призыва не писать документацию.

                  Так может не надо на зеркало пенять, коли… сами знаете что
                    0
                    Вот ИМХО но избежать проблем можно было бы если:
                    1. Выбираем любую готовую CMS с большим комьюнити
                    2. Запрещайте документировать что бы то ни было кроме того, что внесли сами
                    3. Зовите Гуру
                    4. Ваш проект должен состоять из одной зоны ответственности в том числе менеджмента. Если компания нанимает «менеджера» значит не доверяет программисту, тут нужно начинать решать проблему с ее корня. Если программист занимается всем, то пусть занимается всем, что касается программирования, по крайней мере он самостоятельно лучше распределит задачи и выставит приоритеты, а если нет то проблема в программисте, значит он не годится для этой работы. Другой вопрос, что такой спец стоит дорого, иногда слишком, но вы ведь зовете Гуру.
                    5. Если программист сам отчитывается перед бизнесом, то пятый пункт отпадает.
                    6. Снова недоверие между руководством и исполнителем и неспособность прозрачно отобразить процесс разработки.
                    Корневая проблема в том, что бизнес видит в программисте источник расходов. Если он будет видеть в нем перспективу и возможность, то все будет иначе. А для этого нужно сделать процесс разработки прозрачным и понятным, нужно снизить риски бизнеса переложив эти риски на программиста, конечно при условии, что это увеличит гонорар в случае успешного достижения результатов (например, пока сайт лежит программист не зарабатывает).

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое