Comments 19
MVP становится базой, на которую навешивают ещё 5 этажей фич.
Ооо, это мое любимое. Сколько я на себе волос вырвал в начале карьеры, когда спотыкался об это. Особенно забавно, когда тебе говорят «Сделай быстренько, посмотрим как будет выглядеть, дальше решим». А потом, спустя пару месяцев, тебе же это приходит, уже пятиэтажное чудо, про которое ты уже забыл, и говорят накинуть еще этаж)
Да да да
Казалось бы, очень очевидная вещь, но на эту ошибку постоянно продолжают натыкаться проекты.
У меня был случай, когда MVP был настолько востребован, что его сразу пустили в боевой прод. Потом, разумеется, всегда не было времени на нормальный дизайн, а количество требуемых фич постоянно росло. Кончилось тем, что в этом кодовом аду не смогли пофиксить ошибку после недели поисков, после чего все-таки было принято решение сделать все по уму. Но не тут-то было... За это время MVP успел обрасти фичами, которые делались по принципу "запили вот это к позавчера", и без какого-либо контроля, насколько эти фичи дополняют друг друга, перекрывают друг друга, или даже вообще друг другу противоречат. При этом заказчики уже во всю пользовались всем спектром функционала. В результате при перезагрузке проекта получилось нечто, что внутри имело хороший дизайн, было поддерживаемо и т.д., и при этом эмулировало наружу весь тот ад, который успел появиться за годы жизни проекта.
так именно поэтому часть проектов долго разрабатывается кстати.
Статья коротко: Делай хорошо, плохо не делай. Вот мой телеграм-канал.
Как-то написал комментарий https://habr.com/ru/articles/902662/comments/#comment_28216466 вообще на другую тему, но, кажется, он сюда даже лучше зайдет)
Хорошая структура — это способ, которым ИИ заменит вас. Так что лучше сделать это не лучшим образом
Делай так, чтобы в твоих услугах нуждались.
Как устроиться в компанию, где нормальные процессы, если есть только опыт работы в компаниях, где ненормальные процессы?
"по уму" - дорого и послезавтра, а бизнесу надо "дёшево и позавчера".
всякую дурь, вне зависимости от сложности, отдают сотрудникам, которых не жалко. то есть, работающим по нижней планке зарплатной вилки.
И вот это "дешево и позавчера" со временем может стоить в разы дороже для бизнеса, чем "по уму"
они смотрят на это под другим углом. под каким именно, я не знаю, но очень сильно под другим.
возможно, даже, под таким, что: "техдолг побоку, ведь это не наш техдолг, так что пусть растет, главное запустить поскорее. а разработчика всегда заменить можно".
можно долго и упорно рассуждать о том, что умеющий сделает хорошо "всегда", но ситуации разные бывают. есть компании, где тебе просто не дадут сделать хорошо. ты, или сделаешь, как все, и побыстрее, или пойдешь на мороз. а допиливать можешь в свободное от работы время - офис открыт круглые сутки, но нет гарантии, что твое крутое решение примут.
Когда в среднем звене сплошные временщики, горизонт планирования съеживается до пары месяцов.
За 25+ лет работы разработчиком убедился не один раз: если человек знает и умеет делать хорошо - он делает хорошо. Всегда. Если человек не знает и не умеет делать хорошо и ему дать неограниченное количество времени на разработку - он будет думать, что делает хорошо, но делать при этом как умеет, т.е. "нехорошо". И это в любом ремесле. Если мастер клеит обои хорошо - он всегда их клеит хорошо, мастер просто не может себе позволить клеить обои плохо, для мастера это оскорбительно. Если кто-то клеит обои плохо - значит он так делает всегда, независимо от количества отведенного времени.
Если мастеру надо на поклейку обоев хорошо 2 дня, а ему дают только 2 часа, если не устраивает просим на выход. То как бы он не умел клеить хорошо, все равно сделает говно. Ну или уволится с очередной работы.
Допускаю, что так, наверное, бывает. Но поделюсь своим опытом. Я примерно 15 лет проработал в заказной разработке - ни разу заказчик не требовал кардинально снизить оценку. Торговля всегда идёт, но не "за 2 часа вместо 2 дней", а процентов за 20 стоимости. Все понимают, что снижение срока всегда означает как минимум повышение стоимости и риска, снижение качества. Если вдруг не понимают - что ж, бывает, расходимся.
Сейчас работаю в продуктовой разработке с жёсткими дедлайнами и постоянными "влётами" - то же самое. Практически все известные мне большие косяки связаны не с требованием сделать быстро, а с банальной ленью и отсутствием опыта. Вместо того, чтобы подумать день и сделать за неделю, разработчик сделал за три дня, а потом переделывает по чуть-чуть годами. Ну да, формально он сэкономил на первом этапе, но заказчику такая экономия не видна на фоне остальных этапов разработки.
Поддерживаю. Много раз замечал что хорошие решения часто даже стоят по времени не то чтобы больше чем плохие. Просто люди
привязываются к своим идеям, и редко готовы их пересмотреть. Потом они реализуют плохую идею, а потом всей команде приходится ее поддерживать, потому что оно уже на проде и так просто не изменить теперь.
не обладают достаточным опытом
упертые ослы ( смотри пункт один )
Когда попадется упертый человек без опыта или с опытом как делать плохо зато быстро, вот тут начинается бесконечная гонка переделываний говнокода.
Ну еще бывает начальство неправильно ставит задачу, или просто "хочет странного". Например не понимают полноценного решения и топят за какое-то но понятное им. Такие понятные и мегапростые решения тоже регулярно выходят боком.
Почему разработчики не делают «по уму», даже когда знают как