Взял отсюда. history.wikireading.ru/8107
Честно говоря, в первую очередь про косы и серпы вспомнилось, но эти примеры показались более яркими. Хотя, статья, понимаю, совсем не академическая.
Да, денег там действительно много. Вопрос в другом, в том, что как-то бы поэффективнее принимались решения по этим кучам и консультантам-впаривателям. Хотя, для того и существуют кризисы, чтоб вот этот праздник жизни время от времени протрезвлять.
Все было бы так, если бы не напыщенность старожилов и чувство знания истины. Помноженные на полное непонимание МСА, они приводят только к ошибкам, стоимость которых миллионы.
Про то как оркестровать разные команды — тут ничего нового нет. Тезис был совсем о другом.
О том, что команда должна отвечать за бизнес-фукнцию. Как только вы разбиваете бизнес-функцию по разным командам, все, сама бизнес-функция становится никому не интересной хренью. И уже никто за нее не отвечает. И что будет в момент сбоя справочника, всем тоже становится плевать. Просто потому что это «не наша зона ответственности». И кто в итоге становится ответственным? Да, тот самый архитектор, который за жизнь не написал ни строчки кода. Или аналитик, который не предусмотрел.
Ну а доступ к боевым данным в правильно спроектированной системе с нормальым devOps не должен быть вообще ни у кого кроме пары сисадминов. Тут даже обсуждать нечего
На счет DevOps полностью согласен, но он же не только для микросервисной архитектуры актуален. Возможно я живу в мире розовых пони, но я считал, что его нужно строить в том числе и для монолита и для любой другой системы, которую нужно выводить в прод.
Ну, разрабы вообще за все отвечают. Тут трудно спорить.
Вопрос лишь в качестве разрабов. Если 99% кода на спринге превращается в спрингопомойку, в которой без поллитра не разобраться, то я понимаю, что это происходит только из-за того. что сам фреймворк мотивирует разрабов писать некачественный код.
Фреймворки бывают разные. Я видел такие, которые стимулировали в модель засовывать всю логику. Ну а спринг вот просто приучает к бардаку.
Вы знаете, я тоже уважаю Кутузова, Жукова, Королева, Курчатова. Но уже очень много лет после них прошло. Пора бы уже новые причины для гордости придумать. Дедам-то конечно же спасибо за Победу. А сами-то на что-то вообще годны кроме гордости за дедов?
Господа, о чем это здесь?
Применение микросервисов требует прокачать мозг? Ну так любые асинхронные, параллельные, многоядерные разработки требуют повышения квалификации персонала. А какая альтернатива? Линейное программирование в одном потоке с оператором goto? Кому этого достаточно, ну счастья вам. А мы пойдем упражнять мозг, ломать очередной раз свой майнд и строить крутые масштабируемые системы.
Спасибо за разъяснение. Нисколько не сомневаюсь в том, что Скала реально мощный язык и сыграл значительную роль в развитии рынка языков. Лично я сделал выбор после прочтения обзоров сравнения между Котлином и Скалой. Согласно этому обзору они очень близки, но все же Котлин несколько удобнее. Добило меня то, что попадались на глаза проекты, которые перешли со Скалы на Котлин (не помню какие).
Тайп хинты, позволяющие или нет null — фича php 5.0 (2004ый год).
В тайп хинтах ничего нового нет. Они сейчас есть и в Питоне и Яваскриптах. Только на практике мало кто их использует. Проверка на null в один оператор тоже древнее изобретение.
Под нал-сейфти сейчас понимается именно защит на уровне компилятора от присвоения нала значению, которое не предназначено принимать нал:
val hereWillBeError: String = null // вот такое не должно пропускаться.
val hereIsOk: String? = null // так нормально
По моему опыту, на KMP удобнее делать интерфейсную логику доступа к бэку для фронта. Удобно же когда один раз сделал ее и разные фронты пользуются одним кодом.
Менее очевидно и более спорно использовать его для генерации внутренних моделей, которые могут включать логику. Например, на транспортном DTO расчет ФИО из Ф, И, О будет избыточным, но для внутренней модели это вполне нормально.
Ну и еще одно применение. Фронт бывает не только SPA. SSR часто делают на ноде, но ничто не мешает делать его на Kotlin — какая разница на чем шаблоны заполнять? В этом случае логику действительно можно будет шарить между тем же Реактом и SSR-ным бэкендом.
А вообще, новые возможности могут значительно повлиять на применяемые практики программирования. Возможно, наш предыдущий опыт мешает увидеть какие-то новые подходы, которые могут стать преобладающими на рынке.
Это было не научное исследование :) Для себя проверяли.
Просто один и тот же разраб тупо сделал DTO на Java, потом на Kotlin.
Ну за сколько человек набивает 4 килобайта Явовского кода в сравнении с 300 байтами на Котлине?
Естественно, что когда идет более сложный код, там все хитрее и уже больше играет по времени сама проблема нежели язык.
Честно говоря, в первую очередь про косы и серпы вспомнилось, но эти примеры показались более яркими. Хотя, статья, понимаю, совсем не академическая.
О том, что команда должна отвечать за бизнес-фукнцию. Как только вы разбиваете бизнес-функцию по разным командам, все, сама бизнес-функция становится никому не интересной хренью. И уже никто за нее не отвечает. И что будет в момент сбоя справочника, всем тоже становится плевать. Просто потому что это «не наша зона ответственности». И кто в итоге становится ответственным? Да, тот самый архитектор, который за жизнь не написал ни строчки кода. Или аналитик, который не предусмотрел.
Ну а доступ к боевым данным в правильно спроектированной системе с нормальым devOps не должен быть вообще ни у кого кроме пары сисадминов. Тут даже обсуждать нечего
Вопрос лишь в качестве разрабов. Если 99% кода на спринге превращается в спрингопомойку, в которой без поллитра не разобраться, то я понимаю, что это происходит только из-за того. что сам фреймворк мотивирует разрабов писать некачественный код.
Фреймворки бывают разные. Я видел такие, которые стимулировали в модель засовывать всю логику. Ну а спринг вот просто приучает к бардаку.
Вы не поверите, не нужны они, ведь каменный топор надежнее.
Господа, о чем это здесь?
Применение микросервисов требует прокачать мозг? Ну так любые асинхронные, параллельные, многоядерные разработки требуют повышения квалификации персонала. А какая альтернатива? Линейное программирование в одном потоке с оператором goto? Кому этого достаточно, ну счастья вам. А мы пойдем упражнять мозг, ломать очередной раз свой майнд и строить крутые масштабируемые системы.
В тайп хинтах ничего нового нет. Они сейчас есть и в Питоне и Яваскриптах. Только на практике мало кто их использует. Проверка на null в один оператор тоже древнее изобретение.
Под нал-сейфти сейчас понимается именно защит на уровне компилятора от присвоения нала значению, которое не предназначено принимать нал:
Менее очевидно и более спорно использовать его для генерации внутренних моделей, которые могут включать логику. Например, на транспортном DTO расчет ФИО из Ф, И, О будет избыточным, но для внутренней модели это вполне нормально.
Ну и еще одно применение. Фронт бывает не только SPA. SSR часто делают на ноде, но ничто не мешает делать его на Kotlin — какая разница на чем шаблоны заполнять? В этом случае логику действительно можно будет шарить между тем же Реактом и SSR-ным бэкендом.
А вообще, новые возможности могут значительно повлиять на применяемые практики программирования. Возможно, наш предыдущий опыт мешает увидеть какие-то новые подходы, которые могут стать преобладающими на рынке.
Просто один и тот же разраб тупо сделал DTO на Java, потом на Kotlin.
Ну за сколько человек набивает 4 килобайта Явовского кода в сравнении с 300 байтами на Котлине?
Естественно, что когда идет более сложный код, там все хитрее и уже больше играет по времени сама проблема нежели язык.