Есть же стандарт RFC 7807 там достаточно ясно описано как нужно возвращать ошибки.
HTTP/1.1 500 Internal Server Error
Content-Type: application/problem+json
Content-Language: en
{
"type": "https://www.thecodebuzz.com/probs/account-balance-low",
"title": "You do not have enough balance.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/checking-account/msgs/bd",
"balance": 30, //Add your custom fields
"accounts": ["/account/checking-account/0012"] // add your custom fields
}
Я пришел в го из джанги, по этому когда пришлось прописывать таблицу вручную впал в небольшой ступор) Иногда слышу что ОРМ не всегда оптимально создает эти миграции и хочется иметь возможность подкрутить узкие места. Не сталкивался в своей практике с таким. Если применял джангу то для создания MVP, а там ОРМ за глаза)
По-моему это спор о форме, а нужно сфокусироваться на содержании то есть суть бизнеса это количество заработанных денег.
И agile, waterfall или конвейер на заводе форда будет оцениваться только с этой позиции.
Если ваш операционный руководитель любит замыкать все на себе, то будьте готовы ему напоминать и ждать его визирование, если он склонен делегировать, то будьте готовы общаться с скрам мастерами.
Повторю, на мой взгляд это лишь форма процесса, надстройка над людьми которые пишут код, если они не могут самоорганизовываться они ищут себе pm-ов, а как их труд организовывается это лирика.
Что бы выяснить что лучше нужно решить, лучше это про что? «Лучше» - всегда в конечном итоге про деньги. Человеко часы это себестоимость продукта.
Все что до сих пор не реализовано, не запущено, не разработанно является таковым только по причине дороговизны. MVP показывает, что дорого и ваш проект кладут под сукно.
Может хороша та методика которая раньше позволит определить это «дорого».
И давайте для себя определимся наконец, за что нам платят деньги? На мой взгляд нам платят деньги чтобы с нашей помощью перетащить таску из in process в done. На этом все, нам как рядовым разработчикам больше ничего не нужно делать, нет задачи оценивать или критиковать. Может это звучит цинично, но мой личный опыт подсказывает мне именно это. Если ты закрываешь таски в срок, не нарушаешь трудовую дисциплину, ты идеальный сотрудник, ты получишь все! Возможно даже решат что раз ты так хорошо решаешь таски, то пора тебе самому эти таски назначать, тут скорей всего бизнес потеряет хорошего разраба и получит плохого менеджера )
Добрый день. Благодарю! Ссылка скопирована из оригинальной статьи, при проверке предположил, что блокировка связана с моей геолокацией. Все примеры и ссылки не менялись. В некоторых местах добавил комментарии
Есть же стандарт RFC 7807 там достаточно ясно описано как нужно возвращать ошибки.
Я пришел в го из джанги, по этому когда пришлось прописывать таблицу вручную впал в небольшой ступор) Иногда слышу что ОРМ не всегда оптимально создает эти миграции и хочется иметь возможность подкрутить узкие места. Не сталкивался в своей практике с таким. Если применял джангу то для создания MVP, а там ОРМ за глаза)
По-моему это спор о форме, а нужно сфокусироваться на содержании то есть суть бизнеса это количество заработанных денег.
И agile, waterfall или конвейер на заводе форда будет оцениваться только с этой позиции.
Если ваш операционный руководитель любит замыкать все на себе, то будьте готовы ему напоминать и ждать его визирование, если он склонен делегировать, то будьте готовы общаться с скрам мастерами.
Повторю, на мой взгляд это лишь форма процесса, надстройка над людьми которые пишут код, если они не могут самоорганизовываться они ищут себе pm-ов, а как их труд организовывается это лирика.
Что бы выяснить что лучше нужно решить, лучше это про что? «Лучше» - всегда в конечном итоге про деньги. Человеко часы это себестоимость продукта.
Все что до сих пор не реализовано, не запущено, не разработанно является таковым только по причине дороговизны. MVP показывает, что дорого и ваш проект кладут под сукно.
Может хороша та методика которая раньше позволит определить это «дорого».
И давайте для себя определимся наконец, за что нам платят деньги? На мой взгляд нам платят деньги чтобы с нашей помощью перетащить таску из in process в done. На этом все, нам как рядовым разработчикам больше ничего не нужно делать, нет задачи оценивать или критиковать. Может это звучит цинично, но мой личный опыт подсказывает мне именно это. Если ты закрываешь таски в срок, не нарушаешь трудовую дисциплину, ты идеальный сотрудник, ты получишь все! Возможно даже решат что раз ты так хорошо решаешь таски, то пора тебе самому эти таски назначать, тут скорей всего бизнес потеряет хорошего разраба и получит плохого менеджера )
Благодарю!
Добрый день. Благодарю! Ссылка скопирована из оригинальной статьи, при проверке предположил, что блокировка связана с моей геолокацией.
Все примеры и ссылки не менялись. В некоторых местах добавил комментарии