Как стать автором
Обновить

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

А если предугадать сложно, то нужно просто делать Y так, чтобы это не усложняло потом X, а лучше хоть немного, но приблизило X.
Давно уже пора сделать под каждой статьей кнопку «Давайте без крайностей» со счетчиком нажатий.
Хорошая идея. Не часто, но достаточно регулярно встречаю на Хабре не плохие, на первый взгляд, статьи, которые портит избыточная категоричность автора. Так в данном случае я бы предложил такую формулу:
Profit = M(z)*P(z) — (M(X) — M(Y)), где
Y — максимально дешёвое, из всех подходящих решений. Назовём его стандартным подходом.
z — потенциальная проблема, которая может возникнуть в будущем. (намерено написана маленькой, что бы подчеркнуть различие: X, Y — суть решения, в то время как z — проблема)
X — более дорогое решение, которое представляет собой объединение стандартного подхода Y и решения проблемы z.
M(X) и M(Y) — стоимость реализации решений X и Y, соответственно.
M(z) — потенциальный убыток, в случае наступления z.
P(z) — вероятность наступления z.
Profit — потенциальная прибыль от использования более дорогого подхода X, вместо стандартного Y.

Очевидно, что:
  • Если Profit сильно больше 0, то нужно использовать более дорогое решение, даже если вероятность возникновения проблемы крайне мала.
  • При этом, если Profit сильно отрицателен, то подход X использовать никак нельзя, даже если наступление проблемы z почти гарантированно и убытки от него велики. Такое может произойти, например, в случае, если X несоизмеримо дороже Y.
  • Если же Profit мало отличается от 0, то можно использовать что угодно.


Использовал схожую формулу при планировании написания вспомогательных утилит. В итоге большая часть утилит осталась ненаписанной.
Бывает. На самом деле я привёл довольно упрощённый вариант, в котором все переменные, кроме (очевидно) Profit, считаются известными, постоянными во времени и попарно линейно независимыми. Если же нет, то формула заметно усложняется.
Весьма распространена ситуация — это когда P(z) равна 1, в случае, если проект вообще «взлетит». И вопрос на самом деле в том, через сколько месяцев/лет это z возникнет, и как это время распределить — сразу писать X, или писать Y, а потом переделать в X.
По моему опыту, быстро выпустить продукт Y и потом готовиться к Z, имея в активе работающий и приносящий деньги продукт — это практически всегда значительно более выигрышная стратегия, чем выйти на рынок позже и потратить на разработку больше средств, но сразу получить Z.
НЛО прилетело и опубликовало эту надпись здесь
Желаю вам поддерживать проект, который на 99% состоит из «запаса».
Это была шутка, на самом деле такого я никому не пожелаю.

Мне интересно, как так получилось, что 99% кода — запас?) А где функционал то?)

А функционал-то зачем?!
Главное — что всё отказоустойчивое, масштабируемое и на микросервисах! Чего вам ещё?
Блокчеин и ИИ забыли.
Такие проекты не доходят до стадии поддержки, а банкротятся.
Если платят — легко, даже делать ничего не надо. Там же ничего нет — ничего не ломается, не функциональности — не пользователей — нет проблем.
У меня сейчас на работе ощущение, что я поддерживаю работу гигансткого карьерного экскаватора, который за свою жизнь выкопал ямку в которой и хомячка не похоронишь. Крайне интересные ощущения свой полной бесполезности. Уж лучше пытаться вытащить лодчонку из шторма, чем на авианосце в луже на мели стоять.
НЛО прилетело и опубликовало эту надпись здесь
Я этим занимаюсь уже второй год. При этом нагрузка увеличилась в 25 раз при неизменной стоимости хостинга и сильно улучшенном времени отклика. Все это время проект приносит деньги — а если бы сразу кинулись оптимизировать, наверное по сей день бы не запустились.
Если пользоваться современным инструментарием, то писать своего кода придется довольно немного. Готовые библиотеки, фреймворки, контейнеризация, распределенные хранилища, облачные хостинги — в наше время все делается очень просто и быстро.

Надо просто погуглить и использование нужной технологии сразу упростит «вариант Z через 5 лет».
За пять лет ваши нагугленные сегодня фреймворки сменят 10 несовместимых релизов, а про докер будут вспоминать только динозавры типа тех, что сейчас поддерживают какой-нибудь OpenVZ.
Самый цимес, что переписать это вот всё на технологии «сегодня плюс пять лет» через пять лет окажется дороже, чем впихнуть в эти технологии будущего простое как табуретка решение Y.
Исповедь говнокодера и адепта «просто купите ещё планку памяти, чем нам утечки искать»,
хотя здравая мысль всё же в этом есть. Главное не возводить её в абсолют.
А еще, зачастую, «написать как попало» и «спроектировать правильно» по сложности и трудозатратам примерно одинаковы.
Например, вот дешёвый большой сервер:
[...]
Такой сервер стоит от ~800 до $1300 в месяц в зависимости от местоположения. Вы можете взять десяток за зарплату опытного инженера DevOps в Лондоне.


Лихо.
Особенно когда в следующем абзаце:
Могу поспорить, что у большинство распределённого программного обеспечения требует рабочую нагрузку менее чем в половину от мощности этого любительского сервера.


В обычное время работает — и ладно, а на пики как-то поровну? Железо нынче дешёвое, но вот простои бизнеса по-прежнему очень дороги.
НЛО прилетело и опубликовало эту надпись здесь
Согласен, зависит от ниши продукта. В суровом ынтырпрайзе почти всё заранее известно, риски имеют высокую вероятность сбываться и потери потенциально огромные. В стартапах неизвестно ничего (слабаем МВП, отточим бизнес-модель, вот это всё), вся разработка — один сплошной риск и потери относительно больше (закрытие компании), но абсолютно меньше. От этого и подходы разные, конечно.

Впрочем, особенно в стартапе если не закладываться на рост 1000% в год, можно быстро обанкротиться.
При средней продолжительности работы современного программиста на одном месте в год-полтора — чего ему вообще задумываться о последствиях? Будут проблемы — наймут контракторов и починят.
НЛО прилетело и опубликовало эту надпись здесь
Средняя длительность жизни проекта год-полтора. Потом он все равно умрет или поменяется. Легче переделать лопату в грабли, чем экскаватор в комбайн.
Ну такое бывает разве что если работать в какой-то замшелой области, где написанный софт может по 5-10 лет работать без серьезных переделок. Типа банков или крупного ритейла.
Да любой корпоративный софт может десятилетиями работать, на самом деле. В небольшом МУПе, где я работал, был написан в 2008 году софт для автотранспортного цеха, он проработал до 2017 года (потом его перенесли практически 1-в-1 на новую платформу). Там же биллинговое ПО работало с 2004 года до 2018, прежде чем его переписали на современную платформу. Работало бы и дальше, но новые свистелки и перделки существенно тормозили как говно построенную систему (ее писали физики, математики и даже один информатик), к примеру, расчеты и пересчеты пеней, а железо хоть и покупали новое время от времени, но без оглядки на особенности системы (максимальную производительность на 1 ядро заменяли 16 ядерной машиной с частотой в 2ГГц. Можно, но зачем, если условно десктопный софт из 2004 года не знал о существовании любых ядер за первым?). Программное обеспечения для аварийной диспетчерской тоже было написано в лохматые года и тоже работало плюс-минус нормально. И лишь моральное устаревание (UTF-8 вместо CP1251/KOI-8R, многоядерные машины, 64 битные платформы, выпиливание Windows XP отовсюду) были настоящими причинами его переписывания, а не километры изоленты и костылей внутри этого ПО.
Вы знаете, я наоборот, могу только пару «отраслей» (ну, не совсем отраслей) назвать, где написанный софт не работает длительное время без серьезных переделок. Это всякие информационные стартапы и веб-службы. Во всех остальных наоборот, информационные системы стабильны, и медленно эволюционируют. И этак раз лет в десять-пятнадцать проводят радикальное обновление. Чаще нельзя, это слишком дорогое удовольствие.

Слишком безаппеляционное заявление. Наш проект переделывался «серьёзно» 0 раз, работает больше 10 лет, популярность только растёт, представляет из себя упомянутую ниже «веб-службу» :)

Или промышленности. Это хайпо-блокчейн может очередной полибус каждый месяц рожить и сливаться, в промышленности никто не будет каждый год менять систему или покупать станок, выкидывая старый.
Просто везде надо находить баланс, нельзя бросаться в крайности. Так же как производительность/универсальность. Где то лучше оставить запас, где то лучше сделать проще, часто можно скрестить оба варианта, сделав так что на переделку уйдет меньше времени но и сложность не увеличится (например модульно). Как бы вы не планировали и не оставляли про запас, всегда найдется клиент, который захочет что то эдакое, и придется многое менять
Автор открыл для себя MVP ???

А можно хотя бы один правильный пример?


Для инфраструктуры нужны Kubernetes и Docker, хотя один большой сервер гораздо проще, но когда придётся масштабироваться до 11-ти серверов, это упростит нам жизнь.

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


Для обработки данных нужен распределённый дизайн, хотя централизованное решение гораздо проще, но когда клиент потребует 99,999% безотказной работы в SLA, это упростит нам жизнь.

В противном случае, когда клиент захочет какой либо HA, в 9 из 10 случаев вся инфраструктура покроется костылями со всех сторон, что бы сделать приложение, которое рассчитывает, что оно одно такое распределенным.


Нужно набрать команду разработчиков и создать собственное программное обеспечение, хотя Wordpress и Shopify гораздо проще, но когда клиентская база вырастет в 100 раз, это упростит нам жизнь.

А почему именно клиентская база в 100 раз? Тут стоит исходить из вопросов доработок, как мне кажется, и далеко не всегда получается так, что написать с нуля плохая идея.


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

Эм… что? В каком месте композиция заменяет наследования?


Нужно написать код в C++ с кэшированием представлений, хотя Python-скрипт с прямыми запросами к Postgres гораздо проще, но при большом увеличении объёма данных это упростит нам жизнь.

Эм… а что мешает просто написать скрипт на python через celery, что бы он масштабировался?

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

Мне почему-то кажется, что ситуация "по виртуалке на продукт" автора более чем устроит. Более того, такой вариант позволит даже немного вертикально масштабироваться путем переноса виртуалок на новые сервера.

Ну, тогда уж по виртуалке на приложение, но проблема в том, что такая схема слишком избыточна, когда у вас много мелких приложений. Менеджить 1000 и 1 сервер все-таки не очень круто.


Вот тут из ниоткуда и приходит более удобная схема виртуалка на смысловую единицу и в ней несколько docker контейнеров для приложений. Ну а потом захочется отказаться от смысловых единиц и получится kubernetes/nomad.

Желаю удачи автору с таким подходом. В России все сложнее, ибо что со стартапом, что со средней руки конторой реальные обстоятельства вносят свои коррективы в виде "Вот тебе списанный P4 2.8/1.5gb DDR1/80gb hdd, сделай на базе этого сервер для 10000 клиентов, чтоб летал 24/7/365 и с перспективой на будущее. Ах, да, ещё блокчейн делай. Не знаю, что это такое, но звучит круто". Это, кстати, реальный пример. В самом лучшем случае ещё можно "выбить" что-то типа 2x Xeon X5460/8gb DDR2-800/2x240gb.
А тут нам буржуи ещё заливают про бесполезность избыточной оптимизации, отсутствие перспектив на будущее и т.д.

Хохма в том, что на этом вашем списанном P4 2.8/1.5gb DDR1/80gb hdd вы нормальный Kubernetes тоже не поднимете. Ну, его самого может и поднимете, но вот для нужного количества микросервисов ресурсов уже не найдется. А вот монолитное приложение может даже суметь заработать — все же у монолита куда меньше накладные расходы.

Докинуть 2 плашки по 512 из личных запасов(итого 2.5 гб) — и со скрипом самописная распределялка заводилась(Kubernetes, само собой, не потянет, но вот "комплекс распределенных БД" 2006 года(самописная вариация на тему SQL из позапрошлого места работы коллеги) позволил успешно раскидать все задачи сначала на 1, а потом и на 4 таких пылесоса, нормальные контейнеры колхозили уже сильно после нас на списанном 771 ксеоне от центрального филиала, когда задержки имеющейся конструкции начали переходить за 8 секунд).


P.S. На почти таком же "четвертьпне", но в разгоне до 3.5 и с 4 гигами DDR2 "кубы" заводились и работали(отладочный стенд перед продакшеном).

Статья очень правильная. Хватит уже писать универсальные овер инженерные программы, фантазируя о будущем. Понятный код, который специально заточен под бизнес сценарий в сто раз проще и дешевле переписать, чем мега дизайн с тонной абстракций, который делали в надежде на светлое будущее которое никогда не наступит. Решайте текущую задачу без далёких фантазий о будущем. Время потраченное на универсальность сейчас, отнимает время от действительно нужных бизнесу задач.

Понятный код, который специально заточен под бизнес сценарий в сто раз проще и дешевле переписать

На самом деле, нет. Или у вас просто нет абстракций.

О вот и любители писать в далекий завтрашний день подоспели, громкими заявлениями.
Абстракции не возникают на пустом месте, они вырождаются при поступлении новых use case'ов с учётом уже реализованых текущих.
Могу привести простой пример. Нечто пишется в файл, простое. Для чего делать абстракцию и растрачивать сложность, если file.wriebytes или file.writetext решает все проблемы. Требований нет — выдумывать не надо.
Как появится новое требование надо читать писать из файла и по сети, вот, тогда уже надо подумать над дизайном. Потом появится ещё посередине кеш, опять придется чуть чуть переделать, но главное не делать это заранее, потому что время будет потрачено, КПД абстракций близко к нулю, т.к. простой метод решает задачу.

Это все круто и понятно выглядит на простых примерах.


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

Если это используется в куче мест, то SomeUtil.ReadFromFile
Семантику вызова хранит функция. Переделка стоит 2копейки. Но если ради этого сделают пару интерфейсов и несколько классов — классический оверинжениринг.
SoneUtils должны называеться по области названия этих данных.
Все просто: мы знаем где это используется, и легко можно оценить масштаб переделки. Но такой подход сложен при разработке фреймворка.

Всё сильно зависит от размера кода. Если там 5 000 строк — это одно, если 500 000 — уже не так просто даётся рефакторинг, когда часть написана в 2000-х, а часть — в 2018-м, разными людьми, говорящими на разных языках и думающих сильно по-разному. В таком случае пара лишних интерфейсов лучше, чем пытаться понять «что хотел сказать автор». А если ещё и тестов нет…
… то вы получите обычную информационную систему типичного крупного предприятия практически в любой сфере :)
О. Сразу видно опытного человека!
Автор прав.
Один из тысячи проектов взлетает до больших нагрузок. Зато при мне пара умерла, в стадии «4 пользователя в день, но мы прикручиваем Редис для пользовательских сессий».
Один из эпичнейших багов, который пришлось чинить — аутсорсинговая команда прикрутила Редис для админских сессий (случающихся раз в день) но забыла прикрутить его для кэширования описаний таблиц в БД (к которым уже тогда обращались примерно сто тысяч раз в день).
это же классика
bash.im/quote/420672
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
Спасибо за статью! Для начинающих свой путь в энтерпрайз софте самое то :)
Ну как правило не надо писать лишнего…
Но надо предусмотреть возможность расширения приложения, библиотеки…
Думаю для этого и есть принципы, подходы такие как GRASP, SOLID, REP, CCP, CRP…
НЛО прилетело и опубликовало эту надпись здесь
У меня, почему-то ощущение, что автор не особо работал с большими проектами с большим количеством функционала…

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

Про то, что производительность железа постоянно растёт линейно и будет так расти до конца двадцатых годов я тоже что-то не вижу.

Оверинжиниринг — бесспорно плохо, но думать хотя бы на обозримое будущее и планировать какую-то нагрузку и базу пользователей хотя бы на год вперёд всё же стоит.
Теории хороши. Практика такова:
Проекту более 10 лет. Был сделан как советует автор — только то, что надо, без всяких запасов. Проект постоянно дорабатывался по требованиям заказчика. Если сравнить, что было на старте и что сейчас, то это два разных проекта. Доработки на базе первоначальной архитектуры и логики стоят давно уже не дешево. И возможно, что если бы заказчик на старте лучше подумал о перспективах и больше потратил на это своего времени, то проект в сумме обошелся бы ему дешевле.
Или же он мог обойтись ему еще дороже — если бы он подумал о перспективах, но не угадал…
Как правило, когда клиент берется за идею создать приложение, он находится в стадии какой-то эйфории, но не факт что идея является лучшей и окупаемой.
Так же и программист часто поступает, когда берется за разработку, начинает метаться вокруг старых проблем предыдущих проектов, которые пытается решить с ходу, не задумываясь будут ли эти проблемы.

По этому и цены такие подходы как Agile, что бы проверить теорию на практике, чем раньше, тем лучше.

Такие подходы как Бережливая разработка(то есть не спешить с выводами и не городить безумие) спасают от лишних затрат как денег, так и времени.

Добавлю, я как разработчик не могу видеть всей бизнес модели, могу только предложить варианты решения проблем, user store, от простого к более сложному. А далее уже можно решить по какому пути мы будем двигаться и что разрабатывать.
Проекту более 10 лет.
И возможно, что если бы заказчик на старте лучше подумал о перспективах и больше потратил на это своего времени, то проект в сумме обошелся бы ему дешевле.

Возможно, если бы заказчик так сделал, то проект бы загнулся через год.

Автор «колхозник», который, взяв правильную идею что over-engineering это плохо, превратил её в идиотскую схему «купите один мощный сервер, так проще разрабатывать». Рискну предположить, что такое решение может быть основой только такого бизнеса, которому вообще не нужен сервер, всё можно решить наймом людей и покупкой G Suite для совместной работы.

могу за это получить минусов)) ох уж очень много)))

если серьезно, сейчас железо стоит дешевле чем часы разработчика. И да, иногда проще купить железа побольше и наваять нужный функционал, да не оптимизированный, но быстро разработанный и быстрее понять нужно это или нет, и понять куда двигаться, чем вбухать 2 годовых бюджета и получить полный провал… бизнес, он такой бизнес
Да не об этом же речь. Разговор о том, что автор излишне категоричен. Вот даже Вы использовали слово
иногда
. О том и речь. Иногда так, иногда иначе. Нельзя так категорично.
Как Вам сказать…
Автор не категоричен, он просто пишет о том, куда уходят деньги и время…
Сам по юности ваял сверх прочную систему(за свой счет и время), теперь понял что это порыв, вызов для программиста, но время и опыт показал что нужно себя держать в руках и видеть чуть больше, заходить за рамки профессии.
На счёт сверх прочных систем согласен: Они, чаще всего, не нужны. Но, всё же вероятность получить попоболь в будущем от собственной непредусмотрительности в прошлом отнюдь не нулевая, если Вы, конечно, собираетесь поддерживать данный проект. И весь вопрос в том, какие проблемы стоят того, что бы предупреждать их заранее, а какие нет.
Конечно, я с Вами согласен.
По этому и писал про GRASP, SOLID...Agile и т.д.
это помогает так сказать не убивать ПО на его заре, если GRASP, SOLID… постоянный рефакторинг помогает удерживать ПО в нормальном состоянии, то Agile подходы позволяют прощупывать путь…
Конечно многое приходит с опытом, но самое важное что приходит с тем самым опытом, это как раз понимание как распределить бюджет, куда вложить силы и время, как распределить приоритеты, что оставить на потом и т.д. и т.п.

Можно мне сервер, который никогда не ломается, который находится в датацентре, в котором никогда не бывает аварий со 100% связностью с, хотя бы, всей Россией?
Никто не просит экономить такты процессорного времени, люди вон JS-ом воздух греют в датацентрах, просто есть проблемы, которые деньгами решаются не в пропорции 2, а в пропорции 100 например. И на такие расходы очень редко кто может пойти.

Вы вообще не поняли о чём я писал, вероятно в силу моего неумелого изложения. Купить сервер потолще не проблема, а давать людям совет «не делайте распределённых систем» это проблема. Это ужасный совет, который ведёт к колоссальным расходам на обеспечение функционирования бизнеса, невозможности улучшения ситуации и деградации разработчиков.
Пусть они хоть на Коболе пишут, но никакой сервис проектировать на работу на одной машине нельзя. Исключения есть, потом про них пишут статьи тут, «как мы купили второй в мире супершкаф, который никогда не ломается за столько денег что и сказать не сможем, потому что наша система не подлежит распределению», буквально недавно тут была такая статья.

Я постараюсь объяснить свою точку зрения...


Вы вообще не поняли о чём я писал, вероятно в силу моего неумелого изложения.
Купить сервер потолще не проблема, а давать людям совет «не делайте распределённых систем» это проблема.

Не надо тех.специалистам давать советы(как сделать) именно сверху, менеджмента, или руководства, специалисты на то и специалисты что знают как решить +100500 проблем, но и специалистам надо задуматься и больше общаться с любым видом заказчиков функционала которые могут не понимать технической части и решать именно нужные проблемы, но и специалисты должны вовремя предупредить заказчика о возможных рисках..

Подпишусь под каждым словом. Как архитектор систем, вижу свою задачу не столько в определении «что делать» — как «что не делать». На предыдущей работе вообще приходилось все время мирить программистов с «product owner»-ом, которая не могла понять почему добавление кнопки на панель оценивается в две недели. А программисты предлагали зарефакторить всю панель — при том, что предыдущее изменение в ней было год назад и следующего скорее всего в ближайший год тоже не будет.
Поддерживаю автора. Гораздо легче и быстрее по-быстрому написать прототип, за месяц осознать, что он не подходит, выбросить его, написать новый прототип с совершенно другими фичами, за очередной месяц осознать, что вроде бы именно это нужно клиентам, нарваться на всевозможные проблемы, выбросить, и наконец переписать как надо, с нужными оптимизациями, в дальнейшем это поддерживая.

А то полгода конструируешь подводную лодку, а потом только понимаешь, что нужен-то был самолет. Зато микросервисы есть, и кластер с файловером.
НЛО прилетело и опубликовало эту надпись здесь
Например: Чем создание за три месяца трех прототипов подлодок и выбрасывание их на помойку поможет клиенту если ему нужен самолет?

Ничем. Но обычно предполагается, что увидев первую из подлодок клиент воскликнет: да мне же самолет нужен, а не подлодка! :-)

НЛО прилетело и опубликовало эту надпись здесь
Так ведь гибкая разработка не означает что заказчика не надо слушать. Напротив, это способ добиться от заказчика важной информации как можно раньше.

Ну а если бюджет сожрал даже первый прототип — то у проекта вовсе шансов не было ни при каких раскладах.
НЛО прилетело и опубликовало эту надпись здесь
В примере, который тут обсуждается, заказчик забыл рассказать что ему нужен самолет, а не подлодка.
НЛО прилетело и опубликовало эту надпись здесь
А исполнители не заметили как додумали часть задачи и делают подлодку.
Заказчик вообще-то все сказал — говорит, мне надо просто доставлять груз из точки А в точку Б незаметно для патрулей на границе Колумбии.
Ну ему подлодку и сделали. А потом вдруг выясняется, что там в море уже все противолодочными сетями заставленно (Заказчик про это и САМ НЕ ЗНАЛ). И только самолет.
Рискну показаться некромантом, но все же продолжу забытую дискусию :)

Смысл не в том, что программисты не слушают заказчика, а в том, что заказчик не знает, чего он хочет. Это аксиома современности.

Есть методология разработки, называется «водопад». Это когда вначале хорошенько думают, анализируют, пишут требования и тз, а потом по нему реализовывают и отдают готовый продукт. Это хорошо для создания спутников и строительства зданий, когда требования заранее известны и меняться не будут ни сейчас, ни через год.

Но для стартапов «сделать по ТЗ» — это смерть. Наверное, процентов так 95 современных айтишных проектов — это попытка попасть пальцем в небо. Есть лишь смутные идеи, предположения о том, что должно «выстрелить», и цель в данном случае — не реализовать идею, а протестировать её в реальном мире. Каждый месяц, если не каждую неделю, что-то изменяется, одни фичи вдруг становятся не нужны, а вместо них появляются новые. Сделать правильно сразу в таком случае никак не получится. А вот когда что-то «нащупали», тогда да, можно наконец написать правильно.
добавлю, водопад не подходит, также потому что

Барри Боэм построил первую версию того, что Стив Макконелл позднее назвал «конкурс неопределенности», конкурс неопределенности говорит о том, что на этапе оценки осущетвимости проекта оцена обычно отклоняется от истины на 60-160%. Иначе говоря, проект, который, как кажется, должен занять 20 недель, может потребоваться от 12 до 32 недель. После формулирования требований в письменом виде оценка может отклоняться на ± 15% в любом направлении, т.е. плановый срок 20 недель может сократиться до 17 недель или вырасти до 23 недель


Институт управления проектами имеет сходную точку зрения… ИУП предлагает принимать начальный уровень отклонения оценки в диапозоне от +75% до -25%


также есть статистика что часто 64% функционала приложения не используется конечными пользователями.

от сюда и появились такие вещи как MVP, методология Спринт от гугла…
НЛО прилетело и опубликовало эту надпись здесь
Я с вами согласен…
В продолжение вашего примера с банком, все как вы и говорите.
Сам опыта разработки ПО для банков не имею.
Но есть другой простой пример. Разрабатывал систему биллинга, да часть вещей можно уложить в точное Т.З., но многое, особенно интерфейс для работы, переделывали 3 раза, и только после 3 раза получилось сделать удобное приложение, по этому изначально и не пытались обдумать все и особо запаса не делали.
и только после 3 раза получилось сделать удобное приложение, по этому изначально и не пытались обдумать

Ну так проблема была как раз не в том, что есть большая сложность изначально спроектировать биллинг удобным и обойтись без переделок ТЗ на ходу. А в том, что не пытались.
Есть софт уникальный, новаторский. Есть софт типовой. Этих биллингов уже написано тысячи, «best practices» все давно известны, все потребности клиентов и как их лучше оформить в UI, всё это тоже пройдено вдоль и поперёк. И то, что заказчик вместе с разработчиком вместо «взять как у других и сделать так же», несколько раз переделывал, это как раз всего лишь отсутствие компетенции. Намного дешевле было бы взять кого-то в команду, кто эти биллинги видел в лицо :)
Так вот часть отвечающая за бизнес процессы не переписывалась.
Для UI были сделаны прототипы, которые пробовали конечные пользователи. Но во время работы находились тонкости, конечно с каждым разом переделывали, добавляли и изменяли меньше. Но именно уже на практическом использовании ПО было понятно какие проблемы не учли, что можно еще добавить и т.д.
«взять как у других и сделать так же»


Ой не гарантировано что у других хорошо) да и бизнес процессы и биллинги эти, у всех компаний разные, чем больше компания, чем не стандартнее у нее продукция, тем меньше шансов найти как у других)
Так всё дело в количестве. Я бы сказал, что на один «серьезный» проект, приходится сотня «несерьезных». Это примерно из той же категории, что на одно десктопное приложение приходится чуть ли не под тысячу мобильных и браузерных. Или, к примеру, на десятки вакансий с пхп будет одно с си.

Есть еще одно наблюдение, независимое от «серьезности» проекта. Оно касается дизайна. Очень часто бывает так: обсудили фичи, обдумали интерфейс, дизайнер нарисовал. Вроде все круто, красиво, соответствует требованиям. А потом верстальщик отверстал, программист закодил, начали пользоваться и поняли, что неудобно. Как-то так получается, что теоретически все ок, а на практике вылезает то, о чем не подумал ни заказчик, ни разработчик. А значит, нужно построить процесс таким образом, чтобы уже на ранней стадии разработки можно было не просто посмотреть на картинки, но и вручную поиграться — понажимать на кнопки, поотправлять формы и тд. Еще даже до того, как начать писать бекенд. А это уже и есть прототип.

А самые продвинутые сразу верстают разные варианты и потом тестируют их всей толпой, не доверяя заказчику — потому что мнение об удобстве интерфейса от пары десятков человек объективнее мнения одного человека.
НЛО прилетело и опубликовало эту надпись здесь
Добавил колонку с именем поставщика и нехватающие колонки. Финита. Пример какой-то неудачный.
НЛО прилетело и опубликовало эту надпись здесь
Переименовать таблицу — дело нехитрое. Если, конечно же, нет требований работы 24/7 и разработчик не увлекался бизнес-логикой в хранимках.
НЛО прилетело и опубликовало эту надпись здесь
Ага, в итоге у тебя шаурмяной ларек, а структура базы данных, такая как будто это Газпром))) в котрой черт ногу сломит.
НЛО прилетело и опубликовало эту надпись здесь
Вот снова ваш пример из веб разработки. Других нет в этом мире?
Я стараюсь не спорить с людьми в тех областях, где я некомпетентен. Допускаю, что есть множество дел, где нужно делать качественно и «в продакшен» уже на первой итерации. Но сам с таким не сталкивался.

Но что мешало продумать хотя бы на 1 шаг в перед и сделать структуру сразу такой? Трудозатраты суммарные были меньше на порядок и срок исполнения тоже не был бы выше.
А это уже и есть мастерство. Но оно не в том, чтобы всегда делать «на один шаг вперед», а в том, чтобы понимать, когда стоит остановиться. Мы, программисты, народ увлеченный — под настроение можем вместо одного конкретного велосипеда сконструировать завод по производству средств передвижения — от самокатов до самолетов, потому что «ну мало ли, а вдруг пригодится».
Не думайте о системе «на вырост». Другие требования — другая система. Не пытаться строить в деревне небоскреб — это и есть архитектура
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории