Довольно спорные утверждения, как мне кажется.

Эксплуатировать свой код должны инженеры
Если проект небольшой — то да, хорошая идея. Если же проект большой, то, к сожалению, это труднореализуемо. Для больших проектов люди придумали разделение труда. Поэтому-то есть product owner'ы, которые выступают теми-самыми-инженерами-которые-эксплутируют-и-хорошо-понимают-всё, и разработчики, QA, DevOps'ы, team lead'ы, PM-ы и т.п., которые по поручению product-owner'а выполняют различные работы. И коммуникации в больших командах можно настроить достаточно неплохо при должном старании.
Покупка почти всегда лучше создания
Пример противоположной ситуации. AWS продаёт сервис NAT gateway (что-то типа роутера). Аналогичный сервис можно реализовать на других сервисах и получится дешевле (в 10-100 раз). Единовременные затраты на разработку довольно быстро окупятся.
Упростите процесс деплоев
Двумя руками за. Как мне кажется, CI/CD как раз об этом. Должна быть одна кнопка, которая отправляет изменения в продакшн.
Доверяйте людям, которые ближе всего к практической работе
Можно и шире сформулировать — "доверяйте профессионалам" :) Если люди непосредственно работают с пользователями, им можно доверять по вопросам UI/UX. Но я бы не стал доверять им архитектуру обработки данных. В этом вопросе лучше доверять другим специалистам.
Меры QA снижают качество
Как мне кажется, здесь какая-то подмена терминов. QA — quality assurance — обеспечение качества. Так что получается оксюморон. Видимо, автор имеет в виду какое-то несовершенство процессов QA в его компании.
Ручному тестированию, конечно, нет места в цепочке CI/CD. Все необходимые тесты должны быть автоматизированы.
Идея "тестирования в продакшене" хорошо известна по соответствующему интернет-мему. Как мне кажется, не для всех проектов такая идея подходит. В случае, если product owner считает возможным пожертвовать частью пользователей, и сэкономить на других мерах QA, то это, наверное, его право. Ему, по-видимому, надо будет обосновать это решение перед заинтересованными лицами (stakeholder'ами).
Скучная технология — это отлично
Идти по проторённой дороге — это отличный способ снижения рисков. Если такая дорога есть — туда, вероятно, и надо идти большинству. Все грабли разложены в известных местах, остаётся только их аккуратно обходить.
Но, как говорится, кто не рискует, тот не пьёт шампанского. Если суть разработки как раз заключается в изменении этой проторённой дороги, поиске новых путей, то такой совет не очень подойдёт. Некоторые стартапы, изобретая свой велосипед, достигли впечатляющих результатов.
Простота всегда выигрывает
Ну, история знает и другие примеры. Например, автомобиль Жигули 2101, по-видимому, проще Tesla Model S. Но, как мне кажется, потребители склонны предпочесть что-то более сложное.
Или пример из области баз данных. DynamoDB — попроще чем Postgres. Там даже толком не поддерживается SQL. Но для многих задач архитекторы предпочитают RDBMS.
Видимо, есть какие-то преимущества в сложных решениях...
Среды вне продакшена имеют убывающие доходы
Здесь трудно даже понять, что имеется в виду.
Доход по определению приносит только конечный продукт. Это же не значит, что надо уволить отдел бэкенд, т.к. там самые высокие расходы?
staging/dev среды, несмотря на отличие от prod, позволяют
- проводить отладку в условиях, приближенных к prod,
- обнаруживать массу проблем без риска потери пользователей,
- свободно экспериментировать с новыми фичами,
- …
  Если бы они не были нужны, никто бы их не делал.
  По поводу трафика. (1) можно делать копию prod-базы на регулярной основе (с обфускацией, если это необходимо); (2) во многих случаях можно направлять копию входящих событий на параллельную систему (staging/dev) в какой-либо пропорции 0-100%. Так что вполне можно получить очень близкую к реальности картину.
Всё всегда ломается
С этим, пожалуй, соглашусь. Несмотря на то, что есть вещи, которые работают очень надёжно, мы всё-таки должны иметь планы и стратегии реакции на всевозможные отказы.

Your account

Sections

Information

Services