Здравствуйте, Sheridan, Вы писали:

vsb>>А что программист знать обязан?
S>Помимо программирования?
S>Ну, например то, как правильно установить и настроить его приложение, какими сервисами его обложить и как лучше эти сервисы настроить.

Нереально. Эти вещи знают разве что команды деливери, эксплуатации, тестировщики и тд.

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

Все что я могу как разработчик — запилить тот вариант, который подкинет мне архитектор. Могу сообщить архитектору о каких то проблемах найденых.
Архитектор может упростить вариант, и вместо <произвольный бесплатный мейлсервер> выбрать sendgrind или mailgun, в таком случае я могу написать тест, что моё приложение подымает транспорт для сендгрида, что туда пролезут корректные параметры, и что взаимодействие будет делаться именно через этот транспорт.

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

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

Здравствуйте, Sheridan, Вы писали:

vsb>>А что программист знать обязан?
S>Помимо программирования?
S>Ну, например то, как правильно установить и настроить его приложение, какими сервисами его обложить и как лучше эти сервисы настроить.

Нереально. Эти вещи знают разве что команды деливери, эксплуатации, тестировщики и тд.

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

Все что я могу как разработчик — запилить тот вариант, который подкинет мне архитектор. Могу сообщить архитектору о каких то проблемах найденых, например, что пишем в сторадж самое меньшее в 10 раз чаще, чем он рассчитывал.
Архитектор может упростить вариант, и вместо <произвольный бесплатный мейлсервер> выбрать sendgrind или mailgun который будет слать нужные вещи по адресам в конфиге, в таком случае я могу написать тест, что моё приложение подымает транспорт для сендгрида, что туда пролезут корректные параметры, и что взаимодействие будет делаться именно через этот транспорт.

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

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

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