Переписывание со старого шила на новое мыло касается в основном небольших и относительно простых приложений. Остальные системы живут десятилетиями и "умирают" разве что из-за прекращения поддержки/ухода разработчиков.
Насчет одной строчки я иронизирую, конечно. "Гибкая" разработка, если под этим понимать аджайлы и прочий стыд-и-скрам не решают проблему, а переносят её на плечи заказчика (что не так уж и плохо). Попытки действительно решить задачу были в 1990-е, спиральные методики. Но для них нужен высокий уровень организации у самого подрядчика. В общем, все безрадостно пока.
Поводов много, например, сегодня даже маленькое предприятие может за пару часов накликать мышкой себе в облаке инфраструктуру, которую лет 20 назад использовали действительно крупные проекты с предварительным обоснованием и закупкой оборудования.
А разве так? Тогда прошу показать, где в девопсе находятся постановки задач, функциональная архитектура, спецификации, внутренняя и внешняя документации. По минимуму, без проверок требований на полноту и непротиворечивость и разработки методики испытаний.
Ну, вот, опять "девопс ненастоящий". Та же мантра с "ненастоящим аджайлом". Если вокруг в основном все "ненастоящее" - аджайлы со стендапами по часу и без рефакторинга и девопсы, увеличивающие REPL на порядок, то проблема в консерватории.
Прекрасная иллюстрация маркетинга девопса - проект, оказывается, умер из-за невозможности разобраться в трех скриптах на шелле, а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
Хорошо, что автор(ы) решили разобраться в этом непростом вопросе. Поэтому предложил бы почитать про классификацию моделей данных и типы соответствующих СУБД, например здесь (англ.) или здесь (рус). Уверен, даже после поверхностного ознакомления появится много вариантов улучшить и упростить статью.
Вы "опровергаете" повышенные требования к СУБД тем, что такие требования есть у вас, как пользователя, а неполное им соответствие вызывает у вас же проблемы эксплуатации?
Выглядит как подтверждение сказанного выше, спасибо.
На самом деле нет. Вопрос не в том, что можно делать, а в том, что нужно. Несмотря на.
Все системные продукты (ОС, СУБД, виртуализация, сервера приложений...), компиляторы, базовые библиотеки, фреймворки по умолчанию имеют повышенные требования к надежности, производительности, развертыванию, зависимостям и прочая. Для прикладных систем нужно дополнительное обоснование.
Не совсем понятна новизна ситуации. С 1960-х годов, когда были изобретены (но далеко не все внедрены) 80% используемый сейчас технологий, появилось разделение на системных и прикладных программистов. Для работы первых важна надежность и производительность программ. Прикладникам всегда важнее быстрее реализовать запрашиваемую функциональность. Тем более прикладникам "домашней" (in-house) разработки. Та, что раньше велась в отделах АСУ предприятий.
Поэтому всегда были рядом Фортран и Лисп, потом Си и Бейсик (Си++ и Вижал Бейсик), Ява и Ява-скрипт и т.д. и т.п. И было еще множество инструментов "посередине", таких как Паскаль-Дельфи. И появлялись культуры использования операционных систем, вместо их написания. Потом СУБД.
Питон - это прекрасный заменитель старого Бейсика с теми же целями: побыстрее реализовать небольшую по масштабам прикладную задачку. Побыстрее вставить свой кирпич в общую стену-плотину, затыкая потоки прорывающейся воды пользовательских историй.
Манипулировать рабочей БД через инструменты разработчика типа postman не очень хорошая идея. В инструментах администраторов обычно можно просто обозначить соединение как production, и тогда операции на запись или блокируются, или требуют дополнительных подтверждений.
Переписывание со старого шила на новое мыло касается в основном небольших и относительно простых приложений. Остальные системы живут десятилетиями и "умирают" разве что из-за прекращения поддержки/ухода разработчиков.
Насчет одной строчки я иронизирую, конечно. "Гибкая" разработка, если под этим понимать аджайлы и прочий стыд-и-скрам не решают проблему, а переносят её на плечи заказчика (что не так уж и плохо). Попытки действительно решить задачу были в 1990-е, спиральные методики. Но для них нужен высокий уровень организации у самого подрядчика. В общем, все безрадостно пока.
Итого: в ТЗ можно обойтись одной строчкой: "Система должна удовлетворять заказчика"
"Зачем учить географию, если есть извозчики?" (с) "Недоросль"
Поводов много, например, сегодня даже маленькое предприятие может за пару часов накликать мышкой себе в облаке инфраструктуру, которую лет 20 назад использовали действительно крупные проекты с предварительным обоснованием и закупкой оборудования.
В связи с распространением Devops, процедура интеграции нового разработчика стала занимать долгие недели даже в небольших фирмах.
Вы читали руководство по скраму? Там действительно есть чему обучаться более одного вечера?
Странный вывод: речь шла о причинах "смерти" проекта. Ведь не из-за скриптов же сборки-развертывания, если серьезно.
А разве так? Тогда прошу показать, где в девопсе находятся постановки задач, функциональная архитектура, спецификации, внутренняя и внешняя документации. По минимуму, без проверок требований на полноту и непротиворечивость и разработки методики испытаний.
>Когда поддерживать и чинить что-то руками стало дурным тоном
Разве девопсы не занимаются ручной поддержкой и починкой своих скриптов, ломающихся ежечасно при изменении одного из 100500 компонентов сборки?
Ну, вот, опять "девопс ненастоящий". Та же мантра с "ненастоящим аджайлом". Если вокруг в основном все "ненастоящее" - аджайлы со стендапами по часу и без рефакторинга и девопсы, увеличивающие REPL на порядок, то проблема в консерватории.
Прекрасная иллюстрация маркетинга девопса - проект, оказывается, умер из-за невозможности разобраться в трех скриптах на шелле, а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
Разработка и эксплуатация - два разных мира с противоречивыми целями существования.
Хорошо, что автор(ы) решили разобраться в этом непростом вопросе. Поэтому предложил бы почитать про классификацию моделей данных и типы соответствующих СУБД, например здесь (англ.) или здесь (рус). Уверен, даже после поверхностного ознакомления появится много вариантов улучшить и упростить статью.
Вы "опровергаете" повышенные требования к СУБД тем, что такие требования есть у вас, как пользователя, а неполное им соответствие вызывает у вас же проблемы эксплуатации?
Выглядит как подтверждение сказанного выше, спасибо.
На самом деле нет. Вопрос не в том, что можно делать, а в том, что нужно. Несмотря на.
Все системные продукты (ОС, СУБД, виртуализация, сервера приложений...), компиляторы, базовые библиотеки, фреймворки по умолчанию имеют повышенные требования к надежности, производительности, развертыванию, зависимостям и прочая. Для прикладных систем нужно дополнительное обоснование.
Конечно есть: технологический стек, круг задач, организация их реализации
Не совсем понятна новизна ситуации. С 1960-х годов, когда были изобретены (но далеко не все внедрены) 80% используемый сейчас технологий, появилось разделение на системных и прикладных программистов. Для работы первых важна надежность и производительность программ. Прикладникам всегда важнее быстрее реализовать запрашиваемую функциональность. Тем более прикладникам "домашней" (in-house) разработки. Та, что раньше велась в отделах АСУ предприятий.
Поэтому всегда были рядом Фортран и Лисп, потом Си и Бейсик (Си++ и Вижал Бейсик), Ява и Ява-скрипт и т.д. и т.п. И было еще множество инструментов "посередине", таких как Паскаль-Дельфи. И появлялись культуры использования операционных систем, вместо их написания. Потом СУБД.
Питон - это прекрасный заменитель старого Бейсика с теми же целями: побыстрее реализовать небольшую по масштабам прикладную задачку. Побыстрее вставить свой кирпич в общую стену-плотину, затыкая потоки прорывающейся воды пользовательских историй.
Речь не о культуре, а о специализации.
Манипулировать рабочей БД через инструменты разработчика типа postman не очень хорошая идея. В инструментах администраторов обычно можно просто обозначить соединение как production, и тогда операции на запись или блокируются, или требуют дополнительных подтверждений.