Или делайте это правильно
Если выбрать одну идею, которая убивает больше всего продуктов, то это создание запаса на будущее (future proofing).
Обычно идея проявляется по схеме.
Нам нужен {X}, и хотя сделать {Y} гораздо легче, но при наступлении {Z} первый вариант упростит нам жизнь.
Где {Z} — событие, которое может произойти в далёком будущем.
Вот несколько примеров:
- Для инфраструктуры нужны Kubernetes и Docker, хотя один большой сервер гораздо проще, но когда придётся масштабироваться до 11-ти серверов, это упростит нам жизнь.
- Для обработки данных нужен распределённый дизайн, хотя централизованное решение гораздо проще, но когда клиент потребует 99,999% безотказной работы в SLA, это упростит нам жизнь.
- Нужно набрать команду разработчиков и создать собственное программное обеспечение, хотя Wordpress и Shopify гораздо проще, но когда клиентская база вырастет в 100 раз, это упростит нам жизнь.
- Нужно использовать дизайн на основе наследования типов, хотя композиция гораздо проще, но после 5 лет увеличения кодовой базы это упростит нам жизнь.
- Нужно написать код в C++ с кэшированием представлений, хотя Python-скрипт с прямыми запросами к Postgres гораздо проще, но при большом увеличении объёма данных это упростит нам жизнь.
Недавно я написал статью о воображаемых проблемах, которые люди придумывают себя со скуки, а не для пользы. Создание запаса на будущее обычно относится к этой категории. Я бы даже сказал, что это самая популярная ошибка в большинстве маленьких компаний.
Но это стоит дальнейшего обсуждения, потому что создание запаса на будущее может действительно помочь продукту, есть сделать всё правильно. Тем не менее, большинство людей делают ошибки и вредят работе.
Добиться успеха сложнее, чем жить с ним
Как бы странно это ни звучало, я думаю, что одна из главных причин происходящего — культ знаменитостей.
У людей странная одержимость — ставить себя на место кого-то более успешного. Затем они строят планы с этой позиции, а не думают по-своему.
Каждый фантазирует, что бы сделать с той удивительной силой, которой у него нет. Словно он президент страны, миллиардер, знаменитость, виртуозный исполнитель или супермен со сверхчеловеческими способностями.
Проблема разработчиков в том, что они слишком потакают этим фантазиям. Программное обеспечение может написать каждый. Не только Facebook способен создать медиаплатформу, которая поддерживает миллиарды пользователей, но вы зря потратите время. Магия Facebook состояла в том, чтобы привлечь эти миллиарды пользователей, а масштабирование системы — лёгкая часть.
Здесь два аспекта:
- a) Достичь роста намного сложнее, чем технически обеспечить его.
- б) Самые выдающиеся и известные инженеры работают над продуктами, которым требуется масштаб.
Первый пункт очевиден, если подумать. Сколько софтверных компаний потерпели неудачу, когда достигли миллиардного дохода или миллионного количества пользователей? Может, 80%… если определить «неудачу» очень строго.
Тем не менее, из всех когда-либо созданных софтверных компаний, возможно, только 0,05% когда-либо достигали такого масштаба.
Проблема с созданием запаса состоит в том, что он обычно создаётся для сценариев, которые никогда не воплощаются в жизнь. Будь то рост до 1000 сотрудников, 10 000 000 пользователей или 10 крупных клиентов с драконовскими требованиями.
И трудно отказаться от таких планов, потому что это мешает мыслям об успехе. Мешает людям фантазировать, как они побеждают Amazon, а вместо этого возвращает к реальности. А в реальности у вас 50 клиентов, половина из которых — родственники и друзья.
Второй пункт лишь ухудшает ситуацию. Вполне естественно, что лучшие программисты получают лучшие места в ведущих компаниях. Они либо помогли их создать, либо там платят миллионы за поддержку.
Принцип Парето работает против нас, поскольку лучшие программисты пишут большинство книг и дают большинство лекций. Мы постоянно слышим о распределённых сервисах на тысячах машин, которые обрабатывают петабайты данных и борются за каждый процент производительности. Но большинству из нас не придётся думать, какого масштаба или надёжности требуют системы вроде Facebook или Google.
Так если фантазии о будущем не помогают, значит, не нужно планировать?
Нет, конечно. Думать о будущем важно. Следует закладываться на него, но делать это правильно.
Дизайн ради гибкости порождает несовершенство
Когда дело доходит до размышлений о будущем, то лучше меньше, да лучше.
Очень редкие продукты точно соответствуют потребностям пользователей, остальные подстраиваются на ходу.
Вряд ли возможно совпадение, что вы предоставляете сервис A и 90% пользователям нужно именно это. Обычно вы предоставляете сервис A, а 90% пользователям нужен сервис Z. Однако A — ближайшая альтернатива Z и никто не предоставляет Z… поэтому некоторые клиенты решают смириться.
Это хорошо. Когда клиенты решают смириться с вашим продуктом, то вы можете изменить его в соответствии с их точными потребностями. По сути, пользователи помогают определить нишу на рынке. Как только вы сможете лучше заполнить эту нишу, то начнёте расти.
Это продуктивная парадигма мышления, потому что она поощряет подход «лучше меньше, да лучше» в отношении будущего развития. Запас на будущее предполагает не увеличение сложности, а наоборот — максимальное упрощение. Чтобы иметь возможность адаптироваться.
Чем проще ваша кодовая база, тем легче её настроить для выполнения другой задачи.
«Я ненавижу код и хочу, чтобы его было как можно меньше в нашем продукте». — Джек Дидерих
Идеальный дизайн требует жертв. Обычно они связаны с гибкостью.
Зачастую именно несовершенный софт решает мировые проблемы, поскольку несовершенное более гибко. Несовершенство по определению оставляет возможности для улучшения.
Проектируйте оптимистично, будущее может вас приятно удивить
Ещё важно помнить, что мир вокруг не статичен.
Будущие проблемы нужно решать будущими технологиями.
Многие люди не только не думают о будущих инструментах, но вообще пользуются инструментарием десятилетней давности. Они накладывают на себя ограничения, которые давно сняты.
Поясню на конкретной проблеме: проектирование распределённого программного обеспечения. Одна из распространённых причин, почему разрабатывают такой софт — потому что единственный сервер не сможет масштабироваться до требуемых спецификаций. Хотя в некоторых ситуациях это верно, но трудно поверить в такие перспективы большинства проектов, особенно стартапов, у которых почти нет клиентов.
Думаю, частично причина в том, что большинство разработчиков в 2018 году всё ещё думают о серверах 2005 года. Но компьютеры с каждым годом улучшаются, и многие провайдеры продают дешёвые выделенные серверы.
Например, вот дешёвый большой сервер:
- Два Xeon E5-2680v4 (28 ядер, 56 потоков, тактовая частота от 2,4 ГГц до 3,3 ГГц)
- 512 гигабайт DDR4-2400 RAM
- 2 NVMe SSD по 1,2 ТБ (у каждого ~3 ГБ/с чтение, ~1,5 ГБ/с запись)
Могу поспорить, что у большинство распределённого программного обеспечения требует рабочую нагрузку менее чем в половину от мощности этого любительского сервера.
Такой сервер стоит от ~800 до $1300 в месяц в зависимости от местоположения. Вы можете взять десяток за зарплату опытного инженера DevOps в Лондоне.
Ещё приятнее, что сервер вдвое подешевеет через два-три года.
Компьютеры продолжают улучшаться, и они будут делать это линейно до конца 2020-х годов. Кто знает, какие появятся изобретения. К тому времени мы даже можем увидеть революцию открытого железа.
Тем не менее, люди продолжают разрабатывать ПО для аппаратных спецификаций и цен начала 2000-х, хотя в 2018 году нужно разрабатывать софт для машин 2019 года.
Это касается не только серверов. Если хотите подумать о будущем, подумайте обо всех будущих периферийных устройствах. Я уверен, что ребята, которые предусмотрели для своего устройства голосовой интерфейс в 2016 году, вполне счастливы в 2018-м.
К какой периферии готовиться в 2018 году? Чёрт его знает. Но я знаю, что она ещё не стала популярной. Когда она станет популярной, то поможет вам занять монопольное положение на рынке, потому что вы уже адаптировали для неё свой софт.
И речь не только о железе, прогресс в программном обеспечении абсолютно удивителен. С появлением WASM браузеры становятся универсальными виртуальными машинами. Через два года вы сможете собрать высокопроизводительное приложение, скомпилировав его для единственной платформы: WebAssembly.
Несмотря на это, люди по-прежнему создают софт для домашних компьютеров образца 2012 года. Они используют Babel, хотя у 99%+ пользователей браузеры с поддержкой ES6.
Постоянно появляются новые языки, а некоторые из них очень хороши. Только за последние 8 лет появились Go, Rust, Scala и D, которые полностью изменили парадигму системного программирования. В ближайшие два года мне кажется, что Julia произведёт такую же революцию в научных вычислениях… и это только области, которыми я лично занимаюсь, а общее количество будущих удивительных вещей просто невероятно.
Но я отвлёкся…
Легко радоваться будущему. Но реально никто не знает, что произойдёт через год-два-пять лет. Есть некоторые прогнозы, но они, естественно, не идеальны.
Тем не менее, если вы действительно хотите создать запас на будущее, то сначала поймите, что предлагает настоящее. Ко всему прочему, так вы сделаете более точный консервативный прогноз на основе реальных данных.
Софт с запасом на 2020-й год, сделанный в духе начала 2000-х, ничем вам не поможет.
Итак, не прекращайте думать о будущем
Просто начните планировать правильно.
Проектируйте с учётом не только своего продукта, но и всей окружающей экосистемы.
Проектируйте для гибкости, а не для совершенства. Гибкость в конечном счёте поможет адаптировать программное обеспечение для будущего. Она помогает принять новые вызовы, а не защищает от воображаемых.
Комментарии (65)
nafgne
31.08.2018 12:44+4Желаю автору поддерживать проект, написанный «без запаса».
mayorovp
31.08.2018 15:23+1Желаю вам поддерживать проект, который на 99% состоит из «запаса».
Это была шутка, на самом деле такого я никому не пожелаю.SirEdvin
31.08.2018 15:49Мне интересно, как так получилось, что 99% кода — запас?) А где функционал то?)
lostpassword
31.08.2018 22:10+4А функционал-то зачем?!
Главное — что всё отказоустойчивое, масштабируемое и на микросервисах! Чего вам ещё?
dididididi
31.08.2018 17:16У меня сейчас на работе ощущение, что я поддерживаю работу гигансткого карьерного экскаватора, который за свою жизнь выкопал ямку в которой и хомячка не похоронишь. Крайне интересные ощущения свой полной бесполезности. Уж лучше пытаться вытащить лодчонку из шторма, чем на авианосце в луже на мели стоять.
Paskin
01.09.2018 19:36+2Я этим занимаюсь уже второй год. При этом нагрузка увеличилась в 25 раз при неизменной стоимости хостинга и сильно улучшенном времени отклика. Все это время проект приносит деньги — а если бы сразу кинулись оптимизировать, наверное по сей день бы не запустились.
slonpts
31.08.2018 12:45Если пользоваться современным инструментарием, то писать своего кода придется довольно немного. Готовые библиотеки, фреймворки, контейнеризация, распределенные хранилища, облачные хостинги — в наше время все делается очень просто и быстро.
Надо просто погуглить и использование нужной технологии сразу упростит «вариант Z через 5 лет».
lokkiuni
31.08.2018 12:46+1Исповедь говнокодера и адепта «просто купите ещё планку памяти, чем нам утечки искать»,
хотя здравая мысль всё же в этом есть. Главное не возводить её в абсолют.
t13s
31.08.2018 12:47+1А еще, зачастую, «написать как попало» и «спроектировать правильно» по сложности и трудозатратам примерно одинаковы.
JC_IIB
31.08.2018 12:47Например, вот дешёвый большой сервер:
[...]
Такой сервер стоит от ~800 до $1300 в месяц в зависимости от местоположения. Вы можете взять десяток за зарплату опытного инженера DevOps в Лондоне.
Лихо.Angerslave
31.08.2018 13:01Особенно когда в следующем абзаце:
Могу поспорить, что у большинство распределённого программного обеспечения требует рабочую нагрузку менее чем в половину от мощности этого любительского сервера.
В обычное время работает — и ладно, а на пики как-то поровну? Железо нынче дешёвое, но вот простои бизнеса по-прежнему очень дороги.
VMichael
31.08.2018 12:59+1Просто начните планировать правильно.
«Просто» — одно из самых засадных слов в программировании, как мне кажется. Особенно когда оно звучит из уст заказчика. «Давайте „просто“ сделаем...».
Честно говоря в моей «окопной правде» я гораздо чаще встречаюсь с недостатком планирования будущих проблем, чем с чрезмерным запасом на будущее.
Возможно специфика работы такая, когда меня приглашают поправить то, что уже в тупике.
Я помню на заре информатизации было достаточно много статей о том как чего то спроектировать, какие это будет иметь последствия.
Сейчас все больше: «Освой за 24 часа», «Сделай быстро, что бы первым захватить рынок» (хочется перефразировать, относительно программиста: «Сделай быстро и свали, пусть проблемы разгребают пришедшие после»).
Обобщу:
Левая крайность — это перезакладывание на будущие проблемы. Правая крайность — не думать на шаг вперед вообще. К какому краю сейчас ближе общая масса разработок, не знаю. Мне кажется к правому, автору статьи к левому.Angerslave
31.08.2018 13:05Согласен, зависит от ниши продукта. В суровом ынтырпрайзе почти всё заранее известно, риски имеют высокую вероятность сбываться и потери потенциально огромные. В стартапах неизвестно ничего (слабаем МВП, отточим бизнес-модель, вот это всё), вся разработка — один сплошной риск и потери относительно больше (закрытие компании), но абсолютно меньше. От этого и подходы разные, конечно.
Впрочем, особенно в стартапе если не закладываться на рост 1000% в год, можно быстро обанкротиться.
Stas911
31.08.2018 16:33При средней продолжительности работы современного программиста на одном месте в год-полтора — чего ему вообще задумываться о последствиях? Будут проблемы — наймут контракторов и починят.
VMichael
31.08.2018 16:40Ну собственно своим комментарием вы подтверждаете то, что я написал. Исповедуется принцип «после нас хоть потоп». Тоже имеет право на жизнь. Хотя лично мне доставляет удовольствие, что мои поделки работают и после моего ухода многие годы и мне приятно слышать хорошие отзывы о моей работе от людей, которые пришли после меня. Профессиональная гордость.
Ну, как говорится «женщину, религию, дорогу каждый выбирает по себе».dididididi
31.08.2018 17:11Средняя длительность жизни проекта год-полтора. Потом он все равно умрет или поменяется. Легче переделать лопату в грабли, чем экскаватор в комбайн.
Stas911
31.08.2018 18:04Ну такое бывает разве что если работать в какой-то замшелой области, где написанный софт может по 5-10 лет работать без серьезных переделок. Типа банков или крупного ритейла.
Areso
01.09.2018 15:15Да любой корпоративный софт может десятилетиями работать, на самом деле. В небольшом МУПе, где я работал, был написан в 2008 году софт для автотранспортного цеха, он проработал до 2017 года (потом его перенесли практически 1-в-1 на новую платформу). Там же биллинговое ПО работало с 2004 года до 2018, прежде чем его переписали на современную платформу. Работало бы и дальше, но новые свистелки и перделки существенно тормозили как говно построенную систему (ее писали физики, математики и даже один информатик), к примеру, расчеты и пересчеты пеней, а железо хоть и покупали новое время от времени, но без оглядки на особенности системы (максимальную производительность на 1 ядро заменяли 16 ядерной машиной с частотой в 2ГГц. Можно, но зачем, если условно десктопный софт из 2004 года не знал о существовании любых ядер за первым?). Программное обеспечения для аварийной диспетчерской тоже было написано в лохматые года и тоже работало плюс-минус нормально. И лишь моральное устаревание (UTF-8 вместо CP1251/KOI-8R, многоядерные машины, 64 битные платформы, выпиливание Windows XP отовсюду) были настоящими причинами его переписывания, а не километры изоленты и костылей внутри этого ПО.
DrPass
01.09.2018 16:58Вы знаете, я наоборот, могу только пару «отраслей» (ну, не совсем отраслей) назвать, где написанный софт не работает длительное время без серьезных переделок. Это всякие информационные стартапы и веб-службы. Во всех остальных наоборот, информационные системы стабильны, и медленно эволюционируют. И этак раз лет в десять-пятнадцать проводят радикальное обновление. Чаще нельзя, это слишком дорогое удовольствие.
onyxmaster
01.09.2018 19:18Слишком безаппеляционное заявление. Наш проект переделывался «серьёзно» 0 раз, работает больше 10 лет, популярность только растёт, представляет из себя упомянутую ниже «веб-службу» :)
filkt
31.08.2018 13:37Просто везде надо находить баланс, нельзя бросаться в крайности. Так же как производительность/универсальность. Где то лучше оставить запас, где то лучше сделать проще, часто можно скрестить оба варианта, сделав так что на переделку уйдет меньше времени но и сложность не увеличится (например модульно). Как бы вы не планировали и не оставляли про запас, всегда найдется клиент, который захочет что то эдакое, и придется многое менять
SirEdvin
31.08.2018 13:56А можно хотя бы один правильный пример?
Для инфраструктуры нужны Kubernetes и Docker, хотя один большой сервер гораздо проще, но когда придётся масштабироваться до 11-ти серверов, это упростит нам жизнь.
Автор, а вы жили с одним большим сервером, на котором все крутится? Попробуйте, и вы больше никогда в жизни не будете предлагать такой вариант. Не обязательно прямо docker и kubernetes, но хотя бы виртуалки у вас там точно будут.
Для обработки данных нужен распределённый дизайн, хотя централизованное решение гораздо проще, но когда клиент потребует 99,999% безотказной работы в SLA, это упростит нам жизнь.
В противном случае, когда клиент захочет какой либо HA, в 9 из 10 случаев вся инфраструктура покроется костылями со всех сторон, что бы сделать приложение, которое рассчитывает, что оно одно такое распределенным.
Нужно набрать команду разработчиков и создать собственное программное обеспечение, хотя Wordpress и Shopify гораздо проще, но когда клиентская база вырастет в 100 раз, это упростит нам жизнь.
А почему именно клиентская база в 100 раз? Тут стоит исходить из вопросов доработок, как мне кажется, и далеко не всегда получается так, что написать с нуля плохая идея.
Нужно использовать дизайн на основе наследования типов, хотя композиция гораздо проще, но после 5 лет увеличения кодовой базы это упростит нам жизнь.
Эм… что? В каком месте композиция заменяет наследования?
Нужно написать код в C++ с кэшированием представлений, хотя Python-скрипт с прямыми запросами к Postgres гораздо проще, но при большом увеличении объёма данных это упростит нам жизнь.
Эм… а что мешает просто написать скрипт на python через celery, что бы он масштабировался?
mayorovp
31.08.2018 15:44Автор, а вы жили с одним большим сервером, на котором все крутится? Попробуйте, и вы больше никогда в жизни не будете предлагать такой вариант. Не обязательно прямо docker и kubernetes, но хотя бы виртуалки у вас там точно будут.
Мне почему-то кажется, что ситуация "по виртуалке на продукт" автора более чем устроит. Более того, такой вариант позволит даже немного вертикально масштабироваться путем переноса виртуалок на новые сервера.
SirEdvin
31.08.2018 15:48Ну, тогда уж по виртуалке на приложение, но проблема в том, что такая схема слишком избыточна, когда у вас много мелких приложений. Менеджить 1000 и 1 сервер все-таки не очень круто.
Вот тут из ниоткуда и приходит более удобная схема виртуалка на смысловую единицу и в ней несколько docker контейнеров для приложений. Ну а потом захочется отказаться от смысловых единиц и получится kubernetes/nomad.
david52522
31.08.2018 15:44Желаю удачи автору с таким подходом. В России все сложнее, ибо что со стартапом, что со средней руки конторой реальные обстоятельства вносят свои коррективы в виде "Вот тебе списанный P4 2.8/1.5gb DDR1/80gb hdd, сделай на базе этого сервер для 10000 клиентов, чтоб летал 24/7/365 и с перспективой на будущее. Ах, да, ещё блокчейн делай. Не знаю, что это такое, но звучит круто". Это, кстати, реальный пример. В самом лучшем случае ещё можно "выбить" что-то типа 2x Xeon X5460/8gb DDR2-800/2x240gb.
А тут нам буржуи ещё заливают про бесполезность избыточной оптимизации, отсутствие перспектив на будущее и т.д.mayorovp
31.08.2018 15:53Хохма в том, что на этом вашем списанном P4 2.8/1.5gb DDR1/80gb hdd вы нормальный Kubernetes тоже не поднимете. Ну, его самого может и поднимете, но вот для нужного количества микросервисов ресурсов уже не найдется. А вот монолитное приложение может даже суметь заработать — все же у монолита куда меньше накладные расходы.
david52522
31.08.2018 18:34Докинуть 2 плашки по 512 из личных запасов(итого 2.5 гб) — и со скрипом самописная распределялка заводилась(Kubernetes, само собой, не потянет, но вот "комплекс распределенных БД" 2006 года(самописная вариация на тему SQL из позапрошлого места работы коллеги) позволил успешно раскидать все задачи сначала на 1, а потом и на 4 таких пылесоса, нормальные контейнеры колхозили уже сильно после нас на списанном 771 ксеоне от центрального филиала, когда задержки имеющейся конструкции начали переходить за 8 секунд).
P.S. На почти таком же "четвертьпне", но в разгоне до 3.5 и с 4 гигами DDR2 "кубы" заводились и работали(отладочный стенд перед продакшеном).
vyatsek
31.08.2018 16:16Статья очень правильная. Хватит уже писать универсальные овер инженерные программы, фантазируя о будущем. Понятный код, который специально заточен под бизнес сценарий в сто раз проще и дешевле переписать, чем мега дизайн с тонной абстракций, который делали в надежде на светлое будущее которое никогда не наступит. Решайте текущую задачу без далёких фантазий о будущем. Время потраченное на универсальность сейчас, отнимает время от действительно нужных бизнесу задач.
SirEdvin
31.08.2018 16:18Понятный код, который специально заточен под бизнес сценарий в сто раз проще и дешевле переписать
На самом деле, нет. Или у вас просто нет абстракций.
dididididi
31.08.2018 17:00Автор прав.
Один из тысячи проектов взлетает до больших нагрузок. Зато при мне пара умерла, в стадии «4 пользователя в день, но мы прикручиваем Редис для пользовательских сессий».Paskin
01.09.2018 19:49Один из эпичнейших багов, который пришлось чинить — аутсорсинговая команда прикрутила Редис для админских сессий (случающихся раз в день) но забыла прикрутить его для кэширования описаний таблиц в БД (к которым уже тогда обращались примерно сто тысяч раз в день).
saga111a
31.08.2018 17:34это же классика
bash.im/quote/420672
Вася и Петя одновременно начали писать один и тот же продукт.
Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.
А Петя месяц разрабатывал архитектуру, месяц делал удобный интуитивный интерфейс, которому позавидывал бы Джони Айв, потом месяц писал тесты, потом два месяца писал сам код и получил идеальное стабильное приложение.
Но Вася выпустил уже через месяц первую версию программы, пусть и не идеальную, пусть с багами, но рабочую, и начал её продавать. Ещё через месяц выпустил вторую версию исправляющие баги первой и добавляющие новые баги. Ещё через месяц на доходы от продаж нанял двух толковых программеров, которые за два месяца перелопатили весь код, согласно пожеланиям пользователей допилили интерфейс и выпустили третью версию программы.
Итого, через пять месяцев у Васи было два работника, куча клиентов и сносно работающее приложение отвечающее желаниям клиентов.
У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.
В завершение этого выдуманного примера можно сказать, что через полгода Вася купил все наработки Пети, Петю взял в штат тестировщиком, а сам по пьяни разбился на своём новеньком Туареге
R33GTRVspec
31.08.2018 20:48Спасибо за статью! Для начинающих свой путь в энтерпрайз софте самое то :)
inew-iborn
01.09.2018 13:23Ну как правило не надо писать лишнего…
Но надо предусмотреть возможность расширения приложения, библиотеки…
Думаю для этого и есть принципы, подходы такие как GRASP, SOLID, REP, CCP, CRP…
Jenix
01.09.2018 13:23Хватит разрабатывать софт с запасом
«Хватит» говорит автор? а сам пытается рассмотреть все возможные случаи, когда не надо так делать. Т.е. тот же максимальный подход. Та же концепция максимализма. Тоталитарный детский подход ко всему — или всё или ничего. ))
Это в голове сидит у всех программистов, к сожалению. Это не выбросить просто так. Это воспитание системы подготовки таких людей.
Всё предусмотреть, а то «вдруг позовут на свидание, а я не накрасилась»… Или а вдруг пригласит IBM, а я вот такой им новый эксель как выложу, и они сразу удивятся и сделают меня главным председателем над «сеньорами».
Наивные и простые дети. Как же они просты и наивны. ))
ReElevator
01.09.2018 13:23У меня, почему-то ощущение, что автор не особо работал с большими проектами с большим количеством функционала…
Ну и после таких статей приходят в сотрудники девы, которые шлют по паре запросов в базу на каждый кейпресс в поле поиска, а потом удивляются, что ж всё так тормозит когда приложением пользуется хотя бы сотня-другая пользователей, а данных чуть поболее, чем тестовый набор.
Про то, что производительность железа постоянно растёт линейно и будет так расти до конца двадцатых годов я тоже что-то не вижу.
Оверинжиниринг — бесспорно плохо, но думать хотя бы на обозримое будущее и планировать какую-то нагрузку и базу пользователей хотя бы на год вперёд всё же стоит.
lotse8
01.09.2018 13:26Теории хороши. Практика такова:
Проекту более 10 лет. Был сделан как советует автор — только то, что надо, без всяких запасов. Проект постоянно дорабатывался по требованиям заказчика. Если сравнить, что было на старте и что сейчас, то это два разных проекта. Доработки на базе первоначальной архитектуры и логики стоят давно уже не дешево. И возможно, что если бы заказчик на старте лучше подумал о перспективах и больше потратил на это своего времени, то проект в сумме обошелся бы ему дешевле.mayorovp
01.09.2018 13:28Или же он мог обойтись ему еще дороже — если бы он подумал о перспективах, но не угадал…
inew-iborn
01.09.2018 14:20Как правило, когда клиент берется за идею создать приложение, он находится в стадии какой-то эйфории, но не факт что идея является лучшей и окупаемой.
Так же и программист часто поступает, когда берется за разработку, начинает метаться вокруг старых проблем предыдущих проектов, которые пытается решить с ходу, не задумываясь будут ли эти проблемы.
По этому и цены такие подходы как Agile, что бы проверить теорию на практике, чем раньше, тем лучше.
Такие подходы как Бережливая разработка(то есть не спешить с выводами и не городить безумие) спасают от лишних затрат как денег, так и времени.
inew-iborn
01.09.2018 14:33Добавлю, я как разработчик не могу видеть всей бизнес модели, могу только предложить варианты решения проблем, user store, от простого к более сложному. А далее уже можно решить по какому пути мы будем двигаться и что разрабатывать.
onyxmaster
01.09.2018 19:22Автор «колхозник», который, взяв правильную идею что over-engineering это плохо, превратил её в идиотскую схему «купите один мощный сервер, так проще разрабатывать». Рискну предположить, что такое решение может быть основой только такого бизнеса, которому вообще не нужен сервер, всё можно решить наймом людей и покупкой G Suite для совместной работы.
inew-iborn
01.09.2018 20:42могу за это получить минусов)) ох уж очень много)))
если серьезно, сейчас железо стоит дешевле чем часы разработчика. И да, иногда проще купить железа побольше и наваять нужный функционал, да не оптимизированный, но быстро разработанный и быстрее понять нужно это или нет, и понять куда двигаться, чем вбухать 2 годовых бюджета и получить полный провал… бизнес, он такой бизнесJBMurloc
01.09.2018 20:47Да не об этом же речь. Разговор о том, что автор излишне категоричен. Вот даже Вы использовали слово
иногда
. О том и речь. Иногда так, иногда иначе. Нельзя так категорично.inew-iborn
01.09.2018 20:53Как Вам сказать…
Автор не категоричен, он просто пишет о том, куда уходят деньги и время…
Сам по юности ваял сверх прочную систему(за свой счет и время), теперь понял что это порыв, вызов для программиста, но время и опыт показал что нужно себя держать в руках и видеть чуть больше, заходить за рамки профессии.JBMurloc
01.09.2018 21:01На счёт сверх прочных систем согласен: Они, чаще всего, не нужны. Но, всё же вероятность получить попоболь в будущем от собственной непредусмотрительности в прошлом отнюдь не нулевая, если Вы, конечно, собираетесь поддерживать данный проект. И весь вопрос в том, какие проблемы стоят того, что бы предупреждать их заранее, а какие нет.
inew-iborn
01.09.2018 21:07Конечно, я с Вами согласен.
По этому и писал про GRASP, SOLID...Agile и т.д.
это помогает так сказать не убивать ПО на его заре, если GRASP, SOLID… постоянный рефакторинг помогает удерживать ПО в нормальном состоянии, то Agile подходы позволяют прощупывать путь…
inew-iborn
01.09.2018 21:00Конечно многое приходит с опытом, но самое важное что приходит с тем самым опытом, это как раз понимание как распределить бюджет, куда вложить силы и время, как распределить приоритеты, что оставить на потом и т.д. и т.п.
onyxmaster
01.09.2018 23:05Можно мне сервер, который никогда не ломается, который находится в датацентре, в котором никогда не бывает аварий со 100% связностью с, хотя бы, всей Россией?
Никто не просит экономить такты процессорного времени, люди вон JS-ом воздух греют в датацентрах, просто есть проблемы, которые деньгами решаются не в пропорции 2, а в пропорции 100 например. И на такие расходы очень редко кто может пойти.
onyxmaster
01.09.2018 23:11Вы вообще не поняли о чём я писал, вероятно в силу моего неумелого изложения. Купить сервер потолще не проблема, а давать людям совет «не делайте распределённых систем» это проблема. Это ужасный совет, который ведёт к колоссальным расходам на обеспечение функционирования бизнеса, невозможности улучшения ситуации и деградации разработчиков.
Пусть они хоть на Коболе пишут, но никакой сервис проектировать на работу на одной машине нельзя. Исключения есть, потом про них пишут статьи тут, «как мы купили второй в мире супершкаф, который никогда не ломается за столько денег что и сказать не сможем, потому что наша система не подлежит распределению», буквально недавно тут была такая статья.inew-iborn
01.09.2018 23:57Я постараюсь объяснить свою точку зрения...
Вы вообще не поняли о чём я писал, вероятно в силу моего неумелого изложения.
Купить сервер потолще не проблема, а давать людям совет «не делайте распределённых систем» это проблема.Не надо тех.специалистам давать советы(как сделать) именно сверху, менеджмента, или руководства, специалисты на то и специалисты что знают как решить +100500 проблем, но и специалистам надо задуматься и больше общаться с любым видом заказчиков функционала которые могут не понимать технической части и решать именно нужные проблемы, но и специалисты должны вовремя предупредить заказчика о возможных рисках..
Paskin
01.09.2018 20:00Подпишусь под каждым словом. Как архитектор систем, вижу свою задачу не столько в определении «что делать» — как «что не делать». На предыдущей работе вообще приходилось все время мирить программистов с «product owner»-ом, которая не могла понять почему добавление кнопки на панель оценивается в две недели. А программисты предлагали зарефакторить всю панель — при том, что предыдущее изменение в ней было год назад и следующего скорее всего в ближайший год тоже не будет.
Kroid
02.09.2018 00:10Поддерживаю автора. Гораздо легче и быстрее по-быстрому написать прототип, за месяц осознать, что он не подходит, выбросить его, написать новый прототип с совершенно другими фичами, за очередной месяц осознать, что вроде бы именно это нужно клиентам, нарваться на всевозможные проблемы, выбросить, и наконец переписать как надо, с нужными оптимизациями, в дальнейшем это поддерживая.
А то полгода конструируешь подводную лодку, а потом только понимаешь, что нужен-то был самолет. Зато микросервисы есть, и кластер с файловером.
shai_hulud
Но иногда Z наступает.
И чем опытнее тот, кто проектирует, тем лучше он может предугадать вероятность Z.
CheY
А если предугадать сложно, то нужно просто делать Y так, чтобы это не усложняло потом X, а лучше хоть немного, но приблизило X.
shai_hulud
Давно уже пора сделать под каждой статьей кнопку «Давайте без крайностей» со счетчиком нажатий.
JBMurloc
Хорошая идея. Не часто, но достаточно регулярно встречаю на Хабре не плохие, на первый взгляд, статьи, которые портит избыточная категоричность автора. Так в данном случае я бы предложил такую формулу:
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.
Очевидно, что:
Oxoron
Использовал схожую формулу при планировании написания вспомогательных утилит. В итоге большая часть утилит осталась ненаписанной.
JBMurloc
Бывает. На самом деле я привёл довольно упрощённый вариант, в котором все переменные, кроме (очевидно) Profit, считаются известными, постоянными во времени и попарно линейно независимыми. Если же нет, то формула заметно усложняется.
DrPass
Весьма распространена ситуация — это когда P(z) равна 1, в случае, если проект вообще «взлетит». И вопрос на самом деле в том, через сколько месяцев/лет это z возникнет, и как это время распределить — сразу писать X, или писать Y, а потом переделать в X.
DrPass
По моему опыту, быстро выпустить продукт Y и потом готовиться к Z, имея в активе работающий и приносящий деньги продукт — это практически всегда значительно более выигрышная стратегия, чем выйти на рынок позже и потратить на разработку больше средств, но сразу получить Z.