Да никто не отрицает, что один сеньор может сам все делать, просто обычно на такого человека наваливают столько в итоге, что ему уже не до деталей, а они нередко бывают важны.
Из своей практики могу сказать, что внедрить "правильный" процесс - вполне по силам, и "разделение труда" дает результат в виде возрастающего качества готового продукта.
При этом, если проект не сверхсложный (тут у каждого своя субъективная оценка), то схема "и чтец, и жнец, и на дуде игрец", конечно, будет работать.
Все стороны правы, а все потому, что и Минтруд, и читатели почему-то возлагают на разработчика слишком много. До разработчика должны поработать бизнес-аналитик, системный аналитик, архитекторы, а уже потом разработчик может просто следовать ТЗ (почти). Но, о чем это я, так же не принято и вообще где найти всех этих людей, правда это уже другой вопрос.
А про заказчиков справедливо следующее шуточное (но в каждой шутке есть доля шутки) утверждение и его нужно принять: "Заказчик никогда не говорит чего он хочет, а хочет он всегда не то, что ему нужно".
Пошаговый переход. Для начала можно взять серверы, которые отвечают за балансировку трафика, развернуть аналогичные при помощи IaC и подключить к системе CI/CD...
В противном случае можно потратить уйму времени на описание всей инфраструктуры, переехать на IaC и в одночасье понять, что новый подход не решает бизнес-задачи...
А почему нельзя описывать в конфигурации Terraform существующую инфраструктуру, условно говоря, по одной машине за раз, после импортировать ее в state с помощью
terraform import
И далее проверять результат на No changes используя
А MySQL и PostgreSQL уже нельзя использовать? Лицензии прекрасные там. Даже можно сделать форк и развивай себе суверенную СУБД если вот очень хочется. Обязательно нужно раздуть на словах "Масштабы этого замещения"?
Потому что это не закон и нельзя верить всем заголовкам, даже на Хабре. Информацию нужно перепроверять. Присмотритесь повнимательнее. Нормативный акт (приказ, например) != Закон.
Аналогично ситуации с адресами: количество вариаций имени и фамилии слишком велико, чтобы их четко различать.
А зачем их различать? Чтобы по имени обратиться? Практика показывает, что деление на first_name и last_name проблем больше приносит, чем удобств от обращения по имени. Например, когда вы приходите на азиатский рынок, а абстрактный пользователь сам не знает как поделить свое имя Trần Thị Mai Loan на ваши два (или что еще хуже — три) поля (или просто не хочет об этом думать). И в итоге вы получаете одно из двух:
1. Либо в first_name все равно оказывается не first name и вы не достигли цели.
2. Либо в first_name и last_name вы имеете абсолютно две одинаковых строки Trần Thị Mai Loan.
Так что, имхо, нужно писать:
Никогда не храните в разных полях части полного имени
А уж если захотелось, можно добавить дополнительное поле, где пользователь сам укажет как к нему обращаться и вы даже сможете увидеть, что кто-то захотел иметь в ваших email обращение «Доблестный Дон Кихот» — вам все равно, а пользователю приятно.
А почему это исследование хрень? Не было получено положительного результата? Или вы по каким-то причинам считаете, что это точно хрень независимо от результата?
А я вижу странным заголовок статьи в части анонса о том, куда он их потратит. Из статьи так и не получаешь ответ на этот вопрос (хотя надежды было мало, но все же обещания нужно выполнять). Речь в статье только о том, куда он уже потратил деньги до того, как «пробил» потолок.
Ага, вот прямо русскоязычные, например, русскоязычную версию AliExpress. А что это зарубежные хостинги не дают «отечественной промышленности» развиваться?
Да никто не отрицает, что один сеньор может сам все делать, просто обычно на такого человека наваливают столько в итоге, что ему уже не до деталей, а они нередко бывают важны.
Из своей практики могу сказать, что внедрить "правильный" процесс - вполне по силам, и "разделение труда" дает результат в виде возрастающего качества готового продукта.
При этом, если проект не сверхсложный (тут у каждого своя субъективная оценка), то схема "и чтец, и жнец, и на дуде игрец", конечно, будет работать.
Будьте осторожны, за такие мысли выше минусуют)
Все стороны правы, а все потому, что и Минтруд, и читатели почему-то возлагают на разработчика слишком много. До разработчика должны поработать бизнес-аналитик, системный аналитик, архитекторы, а уже потом разработчик может просто следовать ТЗ (почти). Но, о чем это я, так же не принято и вообще где найти всех этих людей, правда это уже другой вопрос.
А про заказчиков справедливо следующее шуточное (но в каждой шутке есть доля шутки) утверждение и его нужно принять: "Заказчик никогда не говорит чего он хочет, а хочет он всегда не то, что ему нужно".
А почему нельзя описывать в конфигурации Terraform существующую инфраструктуру, условно говоря, по одной машине за раз, после импортировать ее в state с помощью
И далее проверять результат на No changes используя
?
Гораздо более крутая, чем кататься со скидкой 80%? ?
А MySQL и PostgreSQL уже нельзя использовать? Лицензии прекрасные там. Даже можно сделать форк и развивай себе суверенную СУБД если вот очень хочется. Обязательно нужно раздуть на словах "Масштабы этого замещения"?
А зачем их различать? Чтобы по имени обратиться? Практика показывает, что деление на first_name и last_name проблем больше приносит, чем удобств от обращения по имени. Например, когда вы приходите на азиатский рынок, а абстрактный пользователь сам не знает как поделить свое имя Trần Thị Mai Loan на ваши два (или что еще хуже — три) поля (или просто не хочет об этом думать). И в итоге вы получаете одно из двух:
1. Либо в first_name все равно оказывается не first name и вы не достигли цели.
2. Либо в first_name и last_name вы имеете абсолютно две одинаковых строки Trần Thị Mai Loan.
Так что, имхо, нужно писать:
А уж если захотелось, можно добавить дополнительное поле, где пользователь сам укажет как к нему обращаться и вы даже сможете увидеть, что кто-то захотел иметь в ваших email обращение «Доблестный Дон Кихот» — вам все равно, а пользователю приятно.