Хватит разрабатывать софт с запасом

Original author: George
  • Translation

Или делайте это правильно


Если выбрать одну идею, которая убивает больше всего продуктов, то это создание запаса на будущее (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-х, ничем вам не поможет.

Итак, не прекращайте думать о будущем


Просто начните планировать правильно.

Проектируйте с учётом не только своего продукта, но и всей окружающей экосистемы.

Проектируйте для гибкости, а не для совершенства. Гибкость в конечном счёте поможет адаптировать программное обеспечение для будущего. Она помогает принять новые вызовы, а не защищает от воображаемых.
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 101

    +5
    Но иногда Z наступает.
    И чем опытнее тот, кто проектирует, тем лучше он может предугадать вероятность Z.
      +1
      А если предугадать сложно, то нужно просто делать Y так, чтобы это не усложняло потом X, а лучше хоть немного, но приблизило X.
        +7
        Давно уже пора сделать под каждой статьей кнопку «Давайте без крайностей» со счетчиком нажатий.
          +1
          Хорошая идея. Не часто, но достаточно регулярно встречаю на Хабре не плохие, на первый взгляд, статьи, которые портит избыточная категоричность автора. Так в данном случае я бы предложил такую формулу:
          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, то можно использовать что угодно.


            0
            Использовал схожую формулу при планировании написания вспомогательных утилит. В итоге большая часть утилит осталась ненаписанной.
              0
              Бывает. На самом деле я привёл довольно упрощённый вариант, в котором все переменные, кроме (очевидно) Profit, считаются известными, постоянными во времени и попарно линейно независимыми. Если же нет, то формула заметно усложняется.
              0
              Весьма распространена ситуация — это когда P(z) равна 1, в случае, если проект вообще «взлетит». И вопрос на самом деле в том, через сколько месяцев/лет это z возникнет, и как это время распределить — сразу писать X, или писать Y, а потом переделать в X.
          +3
          По моему опыту, быстро выпустить продукт Y и потом готовиться к Z, имея в активе работающий и приносящий деньги продукт — это практически всегда значительно более выигрышная стратегия, чем выйти на рынок позже и потратить на разработку больше средств, но сразу получить Z.
        • UFO just landed and posted this here
            +14
            Желаю вам поддерживать проект, который на 99% состоит из «запаса».
            Это была шутка, на самом деле такого я никому не пожелаю.
              +2

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

                +7
                А функционал-то зачем?!
                Главное — что всё отказоустойчивое, масштабируемое и на микросервисах! Чего вам ещё?
                  +1
                  Блокчеин и ИИ забыли.
                +2
                Такие проекты не доходят до стадии поддержки, а банкротятся.
                  0
                  Если платят — легко, даже делать ничего не надо. Там же ничего нет — ничего не ломается, не функциональности — не пользователей — нет проблем.
                  +7
                  У меня сейчас на работе ощущение, что я поддерживаю работу гигансткого карьерного экскаватора, который за свою жизнь выкопал ямку в которой и хомячка не похоронишь. Крайне интересные ощущения свой полной бесполезности. Уж лучше пытаться вытащить лодчонку из шторма, чем на авианосце в луже на мели стоять.
                    0

                    Рефакторинг же.

                      +2
                      Я этим занимаюсь уже второй год. При этом нагрузка увеличилась в 25 раз при неизменной стоимости хостинга и сильно улучшенном времени отклика. Все это время проект приносит деньги — а если бы сразу кинулись оптимизировать, наверное по сей день бы не запустились.
                      +1
                      Если пользоваться современным инструментарием, то писать своего кода придется довольно немного. Готовые библиотеки, фреймворки, контейнеризация, распределенные хранилища, облачные хостинги — в наше время все делается очень просто и быстро.

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


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


                              В обычное время работает — и ладно, а на пики как-то поровну? Железо нынче дешёвое, но вот простои бизнеса по-прежнему очень дороги.
                              +4
                              Просто начните планировать правильно.

                              «Просто» — одно из самых засадных слов в программировании, как мне кажется. Особенно когда оно звучит из уст заказчика. «Давайте „просто“ сделаем...».
                              Честно говоря в моей «окопной правде» я гораздо чаще встречаюсь с недостатком планирования будущих проблем, чем с чрезмерным запасом на будущее.
                              Возможно специфика работы такая, когда меня приглашают поправить то, что уже в тупике.
                              Я помню на заре информатизации было достаточно много статей о том как чего то спроектировать, какие это будет иметь последствия.
                              Сейчас все больше: «Освой за 24 часа», «Сделай быстро, что бы первым захватить рынок» (хочется перефразировать, относительно программиста: «Сделай быстро и свали, пусть проблемы разгребают пришедшие после»).
                              Обобщу:
                              Левая крайность — это перезакладывание на будущие проблемы. Правая крайность — не думать на шаг вперед вообще. К какому краю сейчас ближе общая масса разработок, не знаю. Мне кажется к правому, автору статьи к левому.
                                0
                                Согласен, зависит от ниши продукта. В суровом ынтырпрайзе почти всё заранее известно, риски имеют высокую вероятность сбываться и потери потенциально огромные. В стартапах неизвестно ничего (слабаем МВП, отточим бизнес-модель, вот это всё), вся разработка — один сплошной риск и потери относительно больше (закрытие компании), но абсолютно меньше. От этого и подходы разные, конечно.

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

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

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

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


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

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


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

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


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

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


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

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


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

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

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

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

                                                  +1

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


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

                                                0

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

                                                  0

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

                                                    0

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


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

                                                  –1

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

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

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

                                                      0

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

                                                        0

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


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

                                                          0

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

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

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

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

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

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

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

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

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

                                                                        0

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

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

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

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

                                                                                  –1

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

                                                                                    0

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


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

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

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

                                                                                  А то полгода конструируешь подводную лодку, а потом только понимаешь, что нужен-то был самолет. Зато микросервисы есть, и кластер с файловером.
                                                                                    0
                                                                                    Аналогиями можно оправдать все, что угодно:
                                                                                    Например: Чем создание за три месяца трех прототипов подлодок и выбрасывание их на помойку поможет клиенту если ему нужен самолет?
                                                                                    Быть может имело смысл сначала узнать у клиента, что ему нужен самолет (затратить время на более глубокое проектирование) и потом уже создавать самолет?
                                                                                    И еще.
                                                                                    Подход — быстро создадим 10 прототипов самокатов (сайтов визиток) и определимся, какой из них нужен клиенту, прекрасно подходит при создании самокатов (сайтов визиток).
                                                                                    Но такой подход при создании самолета (приложения, как уже упоминали выше для работы банка или большого склада), чреват катастрофой.
                                                                                    Просто каждый проецирует свой опыт (такова человеческая природа).
                                                                                    Тот кто разрабатывал банковские приложения имеет один опыт, а тот у кого «средний срок жизни проекта и работы в одной организации» год-полтора, другой опыт.
                                                                                    И попытка один опыт натянуть на глобус разных сфер обречена на неудачу.
                                                                                    Можно мелкие фишки использовать разных подходов, но целиком заменять один подход другим в разных сферах не получится.
                                                                                      0
                                                                                      Например: Чем создание за три месяца трех прототипов подлодок и выбрасывание их на помойку поможет клиенту если ему нужен самолет?

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

                                                                                        0
                                                                                        Поскольку заказчика изначально никто не слушал, на его восклицание может быть построен вариант лодки №2.
                                                                                        Ну или как вариант, первый прототип сожрал все бабки и проект завершился.
                                                                                        Я же говорю, аналогии можно наворачивать до бесконечности.
                                                                                        К сожалению, здравый подход: «Не пытайтесь заложиться на 10 шагов вперед, частенько заменятся на: „Не пытайтесь продумать на 1-2 шага вперед“, в пределе „Не думайте вообще, все равно первая версия умрет“.
                                                                                          0
                                                                                          Так ведь гибкая разработка не означает что заказчика не надо слушать. Напротив, это способ добиться от заказчика важной информации как можно раньше.

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

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

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

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

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


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


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

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

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


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

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

                                                                                                            А самые продвинутые сразу верстают разные варианты и потом тестируют их всей толпой, не доверяя заказчику — потому что мнение об удобстве интерфейса от пары десятков человек объективнее мнения одного человека.
                                                                                                              0
                                                                                                              Вот снова ваш пример из веб разработки. Других нет в этом мире?
                                                                                                              Вот пример, элементарный.
                                                                                                              У ритейл компании появилась услуга доставки. Доставкой занимается компания «Пупер».
                                                                                                              Пограммер создает по быстрому табличку «Пупер», в чеки добавляется поле «Пупер» и все поехало. На это насоздавали ссылок на формах и отчетах.
                                                                                                              Хорошо, клево.
                                                                                                              Но через месяца 3-4 (огромный срок по современных веб меркам, вероятно) появляется компания доставщик «Вася».
                                                                                                              И оказывается, что в «Пупер» она уже как то плохо влезает.
                                                                                                              Затевается переделка.
                                                                                                              Заводится справочник доставщиков, в таблицы нужные код из этого спровочника. Переброс данных в новые поля. При работающей системе. С получением и обработкой ошибок в процессе перехода.
                                                                                                              Как бы нет ничего не реального, все делается.
                                                                                                              Но что мешало продумать хотя бы на 1 шаг в перед и сделать структуру сразу такой? Трудозатраты суммарные были меньше на порядок и срок исполнения тоже не был бы выше.
                                                                                                              Это маленький реальный пример.
                                                                                                              А примеры поболее, включают в себя год! работы по исправлению изначально заданных косяков структуры, которые более-менее опытный базовик не допустил бы изначально.
                                                                                                              Конечно сетевых торгующих компаний меньше на порядки, чем студий создателей сайтов. И вакансий меньше.
                                                                                                              Но расстраивает то, что не звучит: «Да, опыта мало, да таких задач не стоит или не стояло».
                                                                                                              Звучит: «Да не нужно это вообще в жизни, средний срок проекта — год полтора, зачем вообще напрягаться думать».
                                                                                                              Это отношение к работе на «от… вали». Быстро чего то сбацать и уйти на новый проект, такой же убогий и краткосрочный.
                                                                                                                0
                                                                                                                Добавил колонку с именем поставщика и нехватающие колонки. Финита. Пример какой-то неудачный.
                                                                                                                  0
                                                                                                                  Да, вы хорошо показали пример мышления, о котором я говорю. Молодец.
                                                                                                                  Куда вы добавите колонку с именем поставщика?
                                                                                                                  И потом всю оставшуюся работу системы, каждому новому члену команды объяснять будете, что таблица «Пупкин» это на самом деле справочник компаний, занимающихся доставкой товаров и таблицу так назвали, потому, что первую такую компанию завали «Пупкин». И это нужно будет держать в голове.
                                                                                                                  И это в элементарном примере. А что со сложными?
                                                                                                                  А через год-два-три, каких финит накапливается столько, что в голове уже не удержишь и вдруг начинает резко падать скорость доработки и резко расти стоимость сопровождения. Но это конкретному программисту пофигу, он уже свалил в новую компанию, на новый проект, простите говнокодить финиты.
                                                                                                                    0
                                                                                                                    Переименовать таблицу — дело нехитрое. Если, конечно же, нет требований работы 24/7 и разработчик не увлекался бизнес-логикой в хранимках.
                                                                                                                      0
                                                                                                                      А сразу сделать минимально годную для развития структуру дело хитрое?
                                                                                                                        0
                                                                                                                        Ага, в итоге у тебя шаурмяной ларек, а структура базы данных, такая как будто это Газпром))) в котрой черт ногу сломит.
                                                                                                                          –2
                                                                                                                          Как раз наоборот, структура БД замороченная у тебя, с твоим подходом, где черт ногу сломит.
                                                                                                                          Впрочем это же не твое горе, ты через год-полтора свалишь делать БД с подходом «для шаурмяного ларька».
                                                                                                                  +1
                                                                                                                  Вот снова ваш пример из веб разработки. Других нет в этом мире?
                                                                                                                  Я стараюсь не спорить с людьми в тех областях, где я некомпетентен. Допускаю, что есть множество дел, где нужно делать качественно и «в продакшен» уже на первой итерации. Но сам с таким не сталкивался.

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

                                                                                            Only users with full accounts can post comments. Log in, please.