Люди в конфлюенс выкладывают текстовые описания API например. Дифы, правки моделей описывают в комментариях к задачам. Документация может лежать в папочке на сетевом диске.
Как только не хранят контракты и договоренности!
Тут вопрос в организации процессов разработки, зрелости команды, наличия инструментов. Например, почти на каждом проекте мне дают почитать OpenAPI синхронную интеграцию (модели и методы) как таблицу на странице в конфлюенсе. И во многих компаниях это считается нормально.
Всё так, некоторые подходы по отдельности можно использовать с монолитом, можно комбинировать. Те же слои или DDD-части в монолите могут проектироваться по другой логике, спору нет.
Если отсылка к публикации контрактов, то скажу вот что: часть контрактов может быть платформенная или от СБ, она особо не меняется и обязана поддерживаться, там гибкость может вредить.
Публикация моделей не заставляет абсолютно всех абсолютно все модели использовать. Тут пространство для проектирования и выбора.
Лично мне на моём проекте это полезно.
Такую особенность можно включать и выключать, это не краеугольный камень слоистости, а доп. опция.
Да причём тут глуповатые или нет? Все действие и развитие в чётко очерченных рамках. Можно копать, можно не копать. А можно там, где ограничения чуть менее явно заданы, что-то налаживать и улучшать.
Да, большинство задач проксирование и крудостроение по заданным правилам. И часто используются стримы (без референса на тотхорошо или плохо). Но есть 10% нестандартных задач и, по ходу выкатки продуктов на прод, будет всё больше и больше задач ребусов поддержки. И вот там критически важно быстро и надёжно выявлять и править ошибки. Там и всякие SLA, и репутация, и прочее. В таких задачах почти никогда не прокатит отговорка "это всё сделает ORM". Как показывает опыт, почти все при выявлении ошибок в данных используют 100500 однострочных скриптов, копируя туда-сюда UUID'ы. Это, мягко говоря, неэффективно-- использовать непонятные селекты, магически комбинируя, вместо написания 1 запроса.
И реализация по интерфейсы - вовсе не олимпиадная задача. Похожее периодически встречается при разработке пользовательских историй, и на более сложных интерфейсах. Тем более, задача на live coding, как я писал пару раз, направлена не сколько на знание синтаксиса, а на другое.
Кажется, я двумя статьями так и не смог до всех донести мысль о том, что главное в интервью - слышать и говорить. Лично мне разговоры почти всегда дают понять заранее, какие результаты кодинга будут.
Если директор сказал искать стучальщиков красными молотками- мне надо выполнять или надо приводить абстрактные аргументы и вставать в позу "я самый умный"?
У конкретного бизнеса есть конкретные потребности и запросы, лучше удовлетворять их без оглядки что у кого-то абстрактного было в 2004. Я решаю задачи конкретного проекта, а не занимаюсь философией. Есть конкретный стек, конкретные библиотеки, конкретный продукт, и это никак не сыязано с Сибирью, хрущевской оттепелью, холодной войной или Жанной д'Арк. Таких параметров в этой задаче просто нет. И я не рассказываю, как в 1982 году искать программистов на Ruby.
Stateless?
Вместо БД кеш?
Разные варианты бывают. Не понятна суть вопроса.
Зачем переубеждать?
Один из вопросов вселенной и вообще всего:
Ясно только, что 1 - не половина (в контексте статьи).
Если обработать на слое хранения, до за свой слой она не выпадет никуда. Аналогично ошибки от условного RestTemplate.
Какая именно половина без кода? Можно поинтересоваться алгоритмом подсчета?
Люди в конфлюенс выкладывают текстовые описания API например.
Дифы, правки моделей описывают в комментариях к задачам.
Документация может лежать в папочке на сетевом диске.
Как только не хранят контракты и договоренности!
Тут вопрос в организации процессов разработки, зрелости команды, наличия инструментов. Например, почти на каждом проекте мне дают почитать
OpenAPIсинхронную интеграцию (модели и методы) как таблицу на странице в конфлюенсе. И во многих компаниях это считается нормально.Всё так, некоторые подходы по отдельности можно использовать с монолитом, можно комбинировать. Те же слои или DDD-части в монолите могут проектироваться по другой логике, спору нет.
Нет, надеюсь, до SOAPа не дойдёт, хотелось бы баланса.
Соблюдать договоренности QA заставят, частично они - тот барьер между разработкой и хаосом. Если нормальный коллектив и нормальные процессы.
А вообще "заставить соблюдать договоренности" - тема больная. Можно решать по-разному.
Да, можно пойти издалека и налить воды. Да, можно игнорировать NDA и описать предметную область. Это было бы втрое больше.
Да, можно было бы написать ADR и C4, но это была бы другая статья.
Да, можно было написать верхнеуровневые требования и спроектировать платформу. Но это тоже была бы другая статья.
У меня не было таких целей.
Предложенные решения можно применять к разным предметным областям в энтерпрайзе.
Я не описываю архитектуру всей системы, уровень абстракции гораздо ниже. Я не описываю продукт, и не хотел.
Зачем я буду писать, что выбирал джаву и мавен (не знаю, какую вы статью про мавен читали, не уверен, что эту), если я не выбирал это?
Если отсылка к публикации контрактов, то скажу вот что: часть контрактов может быть платформенная или от СБ, она особо не меняется и обязана поддерживаться, там гибкость может вредить.
Публикация моделей не заставляет абсолютно всех абсолютно все модели использовать. Тут пространство для проектирования и выбора.
Лично мне на моём проекте это полезно.
Такую особенность можно включать и выключать, это не краеугольный камень слоистости, а доп. опция.
SOAP, всё ж, строже намного.
Не напоминайте. Я же это видел.
Ну и SOAP придумали в другое время, когда еще яндекс не обучал всех подряд, а систем было на порядки меньше.
wsdl
Шаг влево или вправо - расстрел и тотальное падение. С большим количеством сервисов это пытка.
Думаю, это такая ирония.
Написал вторую часть статьи про интервью, как раз с технической конкретикой и большими листингами кода: https://habr.com/ru/articles/996296/
Написал вторую часть статьи про интервью, как раз с технической конкретикой и большими листингами кода: https://habr.com/ru/articles/996296/
Да причём тут глуповатые или нет? Все действие и развитие в чётко очерченных рамках. Можно копать, можно не копать. А можно там, где ограничения чуть менее явно заданы, что-то налаживать и улучшать.
Да, большинство задач проксирование и крудостроение по заданным правилам. И часто используются стримы (без референса на тотхорошо или плохо). Но есть 10% нестандартных задач и, по ходу выкатки продуктов на прод, будет всё больше и больше задач
ребусовподдержки. И вот там критически важно быстро и надёжно выявлять и править ошибки. Там и всякие SLA, и репутация, и прочее. В таких задачах почти никогда не прокатит отговорка "это всё сделает ORM". Как показывает опыт, почти все при выявлении ошибок в данных используют 100500 однострочных скриптов, копируя туда-сюда UUID'ы. Это, мягко говоря, неэффективно-- использовать непонятные селекты, магически комбинируя, вместо написания 1 запроса.И реализация по интерфейсы - вовсе не олимпиадная задача. Похожее периодически встречается при разработке пользовательских историй, и на более сложных интерфейсах. Тем более, задача на live coding, как я писал пару раз, направлена не сколько на знание синтаксиса, а на другое.
Кажется, я двумя статьями так и не смог до всех донести мысль о том, что главное в интервью - слышать и говорить. Лично мне разговоры почти всегда дают понять заранее, какие результаты кодинга будут.
Если директор сказал искать стучальщиков красными молотками- мне надо выполнять или надо приводить абстрактные аргументы и вставать в позу "я самый умный"?
У конкретного бизнеса есть конкретные потребности и запросы, лучше удовлетворять их без оглядки что у кого-то абстрактного было в 2004. Я решаю задачи конкретного проекта, а не занимаюсь философией. Есть конкретный стек, конкретные библиотеки, конкретный продукт, и это никак не сыязано с Сибирью, хрущевской оттепелью, холодной войной или Жанной д'Арк. Таких параметров в этой задаче просто нет. И я не рассказываю, как в 1982 году искать программистов на Ruby.
Эти требования спускаются выше. Глупость или не глупость я буду решать будучи CTO, но сейчас у меня другая должность.
Я не указываю вам как надо было искать, я не знаю нюансов вашего проекта. А вы не знаете всех требований моего проекта и холдинга.
Я не упустил, я набрал. Писал ранее. Вывод-догадка не верен.
Для стека джава не подходит. Буду собеседовать дельфиста - вспомню.