в 2019 уже мало кто говорит такими понятиями
но если коротко, то и то и другое. а модель может быть сложной и бизнес-логика вроде как там.-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Помогите разобраться с исключениями
- Автор темы Forever
- Дата начала
но если коротко, то и то и другое. а модель может быть сложной и бизнес-логика вроде как там.Вурдалак
Продвинутый новичок
throw new HttpException — это конечно, плохая практика, которая провоцирует (точнее, тупо сделана для) на нарушение принципа агностицизма высокоуровневных контекстов относительно низкоуровневых (DIP). Они выполняют краткосрочные задачи быстрее («я нагенерю это за полчаса, а ты будешь об одной модели думать целый день»), наплевав на семантику и контекст. Будет выиграна (и то не факт) пара боёв, но окончательно провалена война.
Семантика и контекст кажутся каким-то незначительными вещами, но пренебрежение ими когда-нибудь будут ломать человеку весь кайф от жизни. Но если человек тупой, то он не будет понимать источника проблемы, а просто спишет на что-нибудь другое (фреймворк, например) и сменит проект.
Эволюция среди трендов в программировании показывает, что контекст (изоляция, Docker, отдельные пакеты, микросервисы, инкапсуляция, whatever) и семантика (DDD, GraphQL, ...) выигрывают. А проекты людей, которые это не понимают, прекращают развитие.
Семантика и контекст кажутся каким-то незначительными вещами, но пренебрежение ими когда-нибудь будут ломать человеку весь кайф от жизни. Но если человек тупой, то он не будет понимать источника проблемы, а просто спишет на что-нибудь другое (фреймворк, например) и сменит проект.
Эволюция среди трендов в программировании показывает, что контекст (изоляция, Docker, отдельные пакеты, микросервисы, инкапсуляция, whatever) и семантика (DDD, GraphQL, ...) выигрывают. А проекты людей, которые это не понимают, прекращают развитие.
Есть простая проблема. Зарплата разработчиков считается простым сложением, а результат работы по архитекторе оценить сложно - это дисконтный анализ эффекта от снижения темпов роста затрат во времени, дисциплина из финансового анализа.
Вы много встречали владельцев проектов или руководителей с образованием в области финансов или менеджмента, которые хотя бы понимали, что такое дисконтирование затрат на архитектуру по цене капитала, и могли сопоставить это с ростом цены разработки во времени, оценить числа, и осознанно решить, что выгоднее?
Я таких не знаю.
Поэтому алгоритм такой:
1. делаем как можно дешевле
2. когда перестает рабоать - назначаем виновных, и судорожно ищем, кто вернет систему в работу
3. проект покупает другая компания, увольняют всех
4. система падает, эффективного менеджера выгоняют на мороз, новый нанимает архитектора, и систему исправляют
думаю, все работали с проектами на каждом этапе
Вы много встречали владельцев проектов или руководителей с образованием в области финансов или менеджмента, которые хотя бы понимали, что такое дисконтирование затрат на архитектуру по цене капитала, и могли сопоставить это с ростом цены разработки во времени, оценить числа, и осознанно решить, что выгоднее?
Я таких не знаю.
Поэтому алгоритм такой:
1. делаем как можно дешевле
2. когда перестает рабоать - назначаем виновных, и судорожно ищем, кто вернет систему в работу
3. проект покупает другая компания, увольняют всех
4. система падает, эффективного менеджера выгоняют на мороз, новый нанимает архитектора, и систему исправляют
думаю, все работали с проектами на каждом этапе
Последнее редактирование:
Чувак не понимает как работать с исключениями и валидировать форму, а вы ему Docker, DDD, GraphQL и продаёте. Я вот не вижу чтобы эти технологии стали серебрянной пулей, скорее даже наоборот, они увеличили сложность, стоимость, сроки разработки и поддержки. Мне иногда приходят просьбы с прошлых проектов, доделать фичи, сажусь за проект десятилетней давности и начинаю гордиться своей работой, за выходные я имплементирую больше изменений, чем на современном проекте за спринт.
Стоимость разработки растет по экспоненте от количества изменений.
"Иногда доделать фичи" - это несколько десятков часов работы за год, и с такими темпами потери отсутствуют.
Вот как форум этот наш - работает себе 20 лет, 3 крупных обновления за всю жизнь, и все хорошо.
А бывают проекты, когда бизнес меняется, фичи клепаются, 70% кода - мусор прошлых фич, простой стоит денег, место на винтах заканчивается. Если новая фича нарушает логики основных процессов - ее не запилить залпом в один заход.
Например, есть каталог, а тут сказали: "будем торговать оборудованием, и выводить список результатов, которые из него сделаны, а у объектов - список материалов". Картина Репина, все модели каталога и четверть CRM - на рефакторинг.
"Иногда доделать фичи" - это несколько десятков часов работы за год, и с такими темпами потери отсутствуют.
Вот как форум этот наш - работает себе 20 лет, 3 крупных обновления за всю жизнь, и все хорошо.
А бывают проекты, когда бизнес меняется, фичи клепаются, 70% кода - мусор прошлых фич, простой стоит денег, место на винтах заканчивается. Если новая фича нарушает логики основных процессов - ее не запилить залпом в один заход.
Например, есть каталог, а тут сказали: "будем торговать оборудованием, и выводить список результатов, которые из него сделаны, а у объектов - список материалов". Картина Репина, все модели каталога и четверть CRM - на рефакторинг.
Последнее редактирование:
whirlwind
TDD infected, paranoid
@grigori, ну бизнес же не одномоментно меняется. Форк надо вовремя делать
Я вот не большой спец по контейнерезации. Примерно знаю что докер это типа чрута. В принципе, как я понимаю эти технологии нацелены на изоляцию, то есть декомпозицию системы на компоненты со всеми вытекающими: микросервисы, легче тестировать, отдельные команды разработки и все такое прочее. Разве это не совпадает с тем, что у нас в коде? Правильная декомпозиция решает проблемы, неправильная - создает. Отсюда всякие ноги девопсов растут и прочих интеграционных подходов. Можно пример каким образом все это увеличивает конечную стоимость? Я прост давно не занимался, реально интересно.
Докер в своей идее очень удобен и упрощает работу. Но сейчас у нас в команде на пол ставки админ + пол ставки девопс, куча завязок на амазон, из-за чего только амазону уходит 1k5-3k$ в месяц, при этом разработчикам самим приходится частично копаться в конфигах докера. На макбуке, который хреново дружит с докером, переодически скрипты падают по 30 секундному таймауту, как только надо перегенерить кэш. 10 лет назад с этими задачами справлялся сам разработчик, один баш скрипт для билда, один баш скрипт для бэкапов и хостинг за 50 баксов.
а что запутано? у нас стандартная тема, докер контейнеры, в которых по фен шую хранятся сервисы, которые разворачиваются на облаке амазона с лябдами и т.д., из-за чего прайс скачет. В итоге оверхед от каждого инструмента накапливается в снежный ком.
напомнило
Вложения
минуту, докер и лямбды - это несвязанные вещи, лямбды нужны только чтобы не платить когда не пользуешься, а если у тебя нагрузка более-менее постоянная - это очень невыгодное решение
лямбды, конечно, из контейнеров деплоятся, но твои проблемы к докеру относятся как прокисшее молоко к тупому ножу, которым ты открывал пакет
докер сам по себе не виснет, виснут виртуалки на маке и винде, в которых он работает - поэтому его иногда надо перезапускать, помогает
лямбды, конечно, из контейнеров деплоятся, но твои проблемы к докеру относятся как прокисшее молоко к тупому ножу, которым ты открывал пакет
докер сам по себе не виснет, виснут виртуалки на маке и винде, в которых он работает - поэтому его иногда надо перезапускать, помогает
дальше, у хостинга за 50 баксов есть одна маленькая проблема: поломка винта или блока питания приводит к остановке всей системы на несколько суток,
чтобы обеспечить SLA на уровне AWS, нужно было, как минимум, 3 сервера по 200 долларов в разных датацентрах, настройка репликации и DNS ... короче, + системный администратор
нужно ли это - другой вопрос, но ценник там именно за пять девяток
копаться в конфигах 10 лет назад надо было точно так же, просто сейчас это docker-compose.yml, а в 2009 это были /etc/
чтобы обеспечить SLA на уровне AWS, нужно было, как минимум, 3 сервера по 200 долларов в разных датацентрах, настройка репликации и DNS ... короче, + системный администратор
нужно ли это - другой вопрос, но ценник там именно за пять девяток
копаться в конфигах 10 лет назад надо было точно так же, просто сейчас это docker-compose.yml, а в 2009 это были /etc/
Так я и цитировал в ответе пост не только о докере, а об общей декомпозиции системы.
Да, вот только с полетевшими винтами я один раз сталкивался и всё за пару минут откатили из бэкапа , и с заблокированным амазоном сталкивался и там проблем завязка на облака принесла гораздо больше. Как оказалось облака очень даже смертны.
Вурдалак
Продвинутый новичок
Процесс постоянного усложнения наших технологий абсолютно естественен по своей природе, потому что человечество ставит перед собой новые и более сложные задачи. Для решения таких задач приходится выходить на новый уровень понимания проблем, где задача становится более простой. Здесь точно также действует естественный отбор — либо ты решаешь задачи, либо ты теряешь позиции. Давай пожалуйся на современную физику, ведь раньше всё было так замечательно в рамках ньютоновской механики. Но тогда и задачи были на порядок проще.
Если ты работаешь в проектах, которые не ставят принципиально новые задачи, то, конечно, тебе достаточно всё делать по-старинке. Но подобные проекты не отражают направление развития. Они стоят на месте.
И неясно к кому именно ты направляешь своё брюзжание: к природным и естественным процессам типа естественного отбора, прогресса? По-моему, это бессмысленно. Устал наращивать новые нейронные связи в головному мозгу? Это твои проблемы.
Вот не надо подменять понятия и приплетать сюда физику и естественный отбор. Это ты занимаешься космическими технологиями, а я как и десять лет назад делаю круды и деплою проект на сервера. Потому сравниваю и пишу, что для моих задач многие модные современные решения не стали серебряной пулей, а кажутся избыточными.