По итогу эта штука ужасно тормозит при малейшей навигации по файлам и глючная, зайти в отладку тяжело.
Поэтому сейчас бы я пошел другим путем, если нужна именно кодо-генерация - отдельная консольная утилита, которой через конфиг указываешь что и где брать и куда складывать и запускать тупо на папке с проектом.
На ютубе все таки наглядней - открывают все сгенерированные приложения, тестят и закрывают те, которые не смогли. Вот например https://www.youtube.com/watch?v=OTyElhqkWOQ (в видео пару месяцев назад все было гораздо лучше, я даже был приятно удивлен)
Да там аналитики за всех думали. Это не хорошо и не плохо. С одной стороны для какого-нибудь сениора, которому интересно делать все самому, будет скучно. С другой - такой подход позволяет организовать процесс где каждый занимается своим делом и позволяет сглаживать ошибки более слабых участников команды.
А на самом деле - все это вилами по воде писано. Упасть может и откат очередного отката. И все равно дело будет в теории вероятности. При этом не все системы требуют лютой надежности и не нужно усложнять.
Так может проще подзабить на это дело? Максимально стремиться решать такие вещи в рамках одной базы, а если даже пришлось разнести - просто помечать записи/сущности после определенного тайм-аута как «несогласованно» и писать логи со сквозным ид, чтобы было понятно кто в цепочке сбойнул.
Можно еще немного поработать с выделением запросов в отдельный метод/класс (CQRS) и в них начинать с ORM, а потом, при необходимости, заменить на нативный SQL или хранимку внутри этого метода/класса.
Кстати однажды работал в проекте, где было четкое разделение по уровням - толпа фронт-ендищиков, толпа бэк-ендщиков и толпа программистов БД. Ну и толпа аналитиков проектировала все эти контракты. Я был на бэк-енде и просто вызывал подготовленные хранимки, как на получение данных, так и на обновление. Они были разного уровня абстракции. И все оптимизации проводились программистами БД. В целом ничего так, мне понравилось.
Их читать 5 минут. Мало того, хорошо бы иметь автотесты, чтобы читать реже пришлось, это не зависимо от используемого языка.
А вот размазать 100500 проверок ошибки на null по всему крупному проекту, как масло на хлеб - это уйма времени и неиллюзорный шанс где-нибудь забыть это сделать.
Централизованного перехвата ошибки я так понял нет. Но при этом с Яве / C#, если есть острая необходимость поманьячить - можно сделать как в Go.
Работал и в небольших компаниях и в московском системном интеграторе на 1000 чел. Самые лучшие процессы были вот как раз в интеграторе. Ни до, ни после я лучше не встречал. Как ни странно - мне очень зашел внешний waterfall (то есть у нас реально были объемные ТЗ, которые подписывались клиентами), но внутри шли по канбану или скраму.
С 2015 года я работаю удаленно в основном на зарубежные, продуктовые, компании, размеры до 100 человек. Ни в одной не было нормальных полноценных процессов. Обязательно были только программисты (куда уж без них, где-то больше, где-то меньше, бывало даже 2 программиста на 10 проектов по началу), где-то худо-бедно пытались наладить постановку задач, с тестированием вообще была беда, документация? А что это?
Еще есть разделение на заказную разработку и продуктовую.
Плюсы заказной - каждый раз новый проект и можно начать с чистого листа, набив шишки на предыдущем. Минусы - сделал проект и забыл, чаще всего ты не знаешь насколько хорошо сработала выбранная архитектура и технологии.
Продуктовая - если заговнокодил (а это неизбежно, потому что куда ветер дунул - туда и кодим), то и живи с этим следующие лет 10-15. Никто не будет в продуктовой компании переписывать продукт каждыe 2-3 года. Но зато получаешь громадный опыт поддержки того, что ты заложил. Когда оно начинает развалиться под весом недо-аджаила и новых противоречивых фич. Понимаешь цену минимализма, наличия авто тестов, поддерживаемости и расширямости.
Не могу согласиться, этот подход тоже не работает.
У меня был и есть проект, который был собран на коленке для менее чем 10 клиентов и до 1000 документов в месяц на всех. Не было никакого анализа, архитектура тоже на коленке, лишь бы работало. Это был придаток к другому продукту, который просто принимал json и перекладывал их в БД или отправлял дальше.
Сначала он был моим вторым проектом, где меня просили что-нибудь доработать по мелочи, поправить багу, или добавить какую-нибудь фичу. Я на протяжении двух лет не делал ничего лишнего. Вот как в статье написано. Каждая фича по отдельности была простой.
Через два года бахнуло. Его начали продавать, повалили клиенты, крупные клиенты (сотня-другая тысяч документов на одного клиента в месяц, а сейчас речь уже идет о 500 тыс - миллионе) и начались проблемы. И это оказался франкенштейн, который делает не то, что нужно, не выдерживает никакой нагрузки и в обработке фоновых задач клиенты мешают друг другу.
Ну и пришлось его переписывать на живую примерно год. И то не хватило времени. Не все было исправлено и сделано как надо. И все это время я выслушивал претензии, типа а как так вышло.
Так что нет, и еще раз нет. Сначала предварительный анализ, вот типа как на собесах по системному дизайну:
Вопрос: сколько потенциальных клиентов, ответ: ну как минимум все те, кто уже есть у компании и пользуются существующими продуктами компании
Вопрос: а какая нагрузка? Ответ: ну если посмотреть наши другие продукты, то вот тут например 500 000 документов (не запросов, один документ - это десятки-сотни запросов в базы данных и другие системы, пока он проходит весь воркфлоу) в день
Потом архитектура на основе этого (там тоже можно заложить точки роста, была даже книга Эволюционная архитектура).
И вот уже потом можно сколько угодно говорить о том, как писать простой код в рамках заданной архитектуры. Потому что менять архитектуру и подходы - это долго и сложно.
И в противовес есть два других продукта, которые были сделаны не тяп-ляп, а с анализом, архитектурой (подходящей архитектурой, второй из них был гораздо более простым и его не надо было интегрировать в ESB). И там, на удивление, и код получился более простым и понятным, не пришлось костылить.
ЗЫ: и в первую очередь надо закладывать логирование и телеметрию запросов (чтобы потом не гадать на кофейной гуще) и авто-тестирование (чтобы потом не было мучительно больно дорабатывать фичи).
Из личного опыта - в далеком 2012 году я устроился на новую работу, в один из московских системных интеграторов с обещанием дать мне возможность стать ведущим программистом. Руководитель обещание сдержал и в конце 2012 - начале 2013 назначил меня тех лидом. Команда на каждом проекте была от 2-4 до 5-7 человек. Я успел поучаствовать в двух проектах.
Кстати мне было 27-28 лет. Почти што 23 летний сениор 😅. Было ссыкотно. Интегратор работал в банковской сфере и я все ждал когда из банков наших клиентов ко мне придут матерые и лютые энтерпрайз архитекторы с вопросами "а почему ты выбрал такую архитектуру?" или "как ты собираешься интегрировать свои сервисы с нашей IBM Service Bus" и все вскроется, а меня уволят 😁
Я не настраивал процессы, не лез в душу к людям, не нанимал и не увольнял. Я делал каркас солюшена, выбирал технологии, закладывал подходы. И потом программисты пилили бизнес-логику уже без меня. Один из проектов был основным, где я участвовал в роли программиста и проводил код ревью. Изумительное время тогда было. Процессы были самые лучшие из всех, когда я либо видел до и после. Я работал с людьми, кто впоследствии стали лидами/сениорами во всяких Швециях, Испаниях, Германиях и Канадах.
Но приходилось распределять задачи, и было пару моментов с людьми..., без конфликтов. Типа чел не любил делать отчеты (UI часть), а я пытался показать ему другую точку зрения. Я понимал, что это обязанности тим-лида. И у меня довольно долго в резюме был указан опыт тим-лидерства. И однажды мне стали писать с вакансиями именно тим-лидов, без кодинга, без технологий. Вот именно тогда я понял, что тим-лид это совершенно другая роль. В тех вакансиях были усложненные требования и обязанности, которых я не приобрел. И я убрал тим-лидерство из своего резюме.
Как всегда - каждая компания под лычкой лида понимает что-то свое. Но я не ожидал такого от Альфа-Банка. В описании мешанина тим-лида и тех-лида + вешают обязанности продукт овнера. А это значит вы, автор, работаете за двоих или даже троих, а зарплату получаете за одного.
Тех лид - это
Техническое виденье продуктов, технологии, технические подходы в решении задач. Примерами могут являться - курирование разработки единой платформы для всех продуктов, R&D для оценки внедрения очередной технологии (колоночная БД, какой-нибудь новый брокер, тарантул, замена джунов внедрение ИИ и тому подобное)
Я бы сказал, что он делит обязанности улучшения процессов (наравне с тим-лидом, руководителем отдела, CTO). Например внедрение метрик качества архитектуры, ревью кода и тому подобное
Тех-лид НЕ решает межличностные конфликты. Не является единственным или главным ЛПР при найме в команду или увольнении. Тех-лид не распределяет задачи и не является ведущим дейликов
Тех-лид обязан работать с кодом и технологиями, иначе со временем его знания и кругозор устареет. Поэтому, если на него вешать еще и пункты 2 и 3 в полной мере - у такого человека не будет времени поддерживать техническую экспертизу
Тех-лид обязан читать техническую литературу
Тим-лид - а вот этот чувак перформит команду:
Решает конфликты, строит планы обучения и развития карьеры
Принимает на работу с (совместно руководителем отдела, CTO), проводит ежегодную оценку, увольняет
Больше участвует в улучшении процессов. Потому что процессы - это в основном для людей. С командой доброжелательных сениоров можно местами и подзабить на процессы. А вот джунов и зуммеров надо регулярно пинать, чтобы они нормально работали
Тим-лид читает литературу по управлению людьми, психологии.
И если пройтись по этим пунктам
Разработчик 1: «О чёрт, все пропало! Помнишь, я вливал в релиз свою доработку? Кажется, она сломала нам прод».
Ну так иди и чини ее. Но на самом деле это больше к руководителю отдела / CTO, потому что проблема в отсутствии тестирования / сбой в процессах. Тех-лид может посоветовать какую технологию или подход использовать для тестирования. Или посоветовать с настройкой человеческих процессов.
Разработчик 2: «Блин, да этот разработчик N вечно придирается ко мне на ревью, так и хочется пойти поругаться с ним»
Это чисто работа тим-лида.
Продукт овнер: «У нас тут такая интересная идея: хотим пользователю после негативного отзыва на наше приложение блокировать использование телефона. Чтобы ему неповадно было нам плохие отзывы оставлять. Крутая идея?»
Почему продукт овнер перекладывает свою работу на тех-лида? Оценка идей - это не работа тех-лида. У него можно спросить "а можно ли в телефоне заблокировать звонки" и только.
Дизайнер: «Прикинь, что придумали для нашего Android-приложения: сделаем градиентный экран, который начнет проигрывать популярные хиты 90-х годов и главное, чтобы экран выглядел точь-в-точь как на iOS»
Аналогично - с такими вопросами и предложениями к продукт овнеру, пускай сами там разбираются.
Специалист сопровождения: «У нас тут критичный баг, неизвестно какая команда, нужно срочно починить».
Пожалуй единственный более-менее подходящий пример. Если много компонентов и много команд. Тут как раз нужна оценка технических глубин, чтобы примерно понять - баг это или фича и где он примерно может быть.
Если что - я вот
паручетыре лет назад исследовал кодогенерацию через source generator - https://habr.com/ru/articles/542300/По итогу эта штука ужасно тормозит при малейшей навигации по файлам и глючная, зайти в отладку тяжело.
Поэтому сейчас бы я пошел другим путем, если нужна именно кодо-генерация - отдельная консольная утилита, которой через конфиг указываешь что и где брать и куда складывать и запускать тупо на папке с проектом.
Точно 😅
Интересно стало - кого больше - кто не любит алгоритмы на собесах или систем дизайн 😅
На ютубе все таки наглядней - открывают все сгенерированные приложения, тестят и закрывают те, которые не смогли. Вот например https://www.youtube.com/watch?v=OTyElhqkWOQ (в видео пару месяцев назад все было гораздо лучше, я даже был приятно удивлен)
Да там аналитики за всех думали. Это не хорошо и не плохо. С одной стороны для какого-нибудь сениора, которому интересно делать все самому, будет скучно. С другой - такой подход позволяет организовать процесс где каждый занимается своим делом и позволяет сглаживать ошибки более слабых участников команды.
А на самом деле - все это вилами по воде писано. Упасть может и откат очередного отката. И все равно дело будет в теории вероятности. При этом не все системы требуют лютой надежности и не нужно усложнять.
Так может проще подзабить на это дело? Максимально стремиться решать такие вещи в рамках одной базы, а если даже пришлось разнести - просто помечать записи/сущности после определенного тайм-аута как «несогласованно» и писать логи со сквозным ид, чтобы было понятно кто в цепочке сбойнул.
Можно еще немного поработать с выделением запросов в отдельный метод/класс (CQRS) и в них начинать с ORM, а потом, при необходимости, заменить на нативный SQL или хранимку внутри этого метода/класса.
Кстати однажды работал в проекте, где было четкое разделение по уровням - толпа фронт-ендищиков, толпа бэк-ендщиков и толпа программистов БД. Ну и толпа аналитиков проектировала все эти контракты. Я был на бэк-енде и просто вызывал подготовленные хранимки, как на получение данных, так и на обновление. Они были разного уровня абстракции. И все оптимизации проводились программистами БД. В целом ничего так, мне понравилось.
Пара вопросов:
Как в итоге переносите шарды между серверами?
И как автомасштабируете консьюмеров для кафки?
Пускай даже бокс это не ИТ, но почитать было интересно.
Их читать 5 минут. Мало того, хорошо бы иметь автотесты, чтобы читать реже пришлось, это не зависимо от используемого языка.
А вот размазать 100500 проверок ошибки на null по всему крупному проекту, как масло на хлеб - это уйма времени и неиллюзорный шанс где-нибудь забыть это сделать.
Централизованного перехвата ошибки я так понял нет. Но при этом с Яве / C#, если есть острая необходимость поманьячить - можно сделать как в Go.
Не, ладно, дженерики, но когда я узнал, что в Go надо после каждой строчки кода проверять err != null - это ж застрелиться можно
Статьи когда все хорошо набирают на порядок меньше лайков, чем статьи, когда все плохо https://habr.com/ru/articles/820463 xD
Как же тяжко живется зуммерам и насколько терпеливый оказался работодатель - два собеса терпеть проблемы с интернетом.
Работал и в небольших компаниях и в московском системном интеграторе на 1000 чел. Самые лучшие процессы были вот как раз в интеграторе. Ни до, ни после я лучше не встречал. Как ни странно - мне очень зашел внешний waterfall (то есть у нас реально были объемные ТЗ, которые подписывались клиентами), но внутри шли по канбану или скраму.
С 2015 года я работаю удаленно в основном на зарубежные, продуктовые, компании, размеры до 100 человек. Ни в одной не было нормальных полноценных процессов. Обязательно были только программисты (куда уж без них, где-то больше, где-то меньше, бывало даже 2 программиста на 10 проектов по началу), где-то худо-бедно пытались наладить постановку задач, с тестированием вообще была беда, документация? А что это?
Еще есть разделение на заказную разработку и продуктовую.
Плюсы заказной - каждый раз новый проект и можно начать с чистого листа, набив шишки на предыдущем. Минусы - сделал проект и забыл, чаще всего ты не знаешь насколько хорошо сработала выбранная архитектура и технологии.
Продуктовая - если заговнокодил (а это неизбежно, потому что куда ветер дунул - туда и кодим), то и живи с этим следующие лет 10-15. Никто не будет в продуктовой компании переписывать продукт каждыe 2-3 года. Но зато получаешь громадный опыт поддержки того, что ты заложил. Когда оно начинает развалиться под весом недо-аджаила и новых противоречивых фич. Понимаешь цену минимализма, наличия авто тестов, поддерживаемости и расширямости.
Не могу согласиться, этот подход тоже не работает.
У меня был и есть проект, который был собран на коленке для менее чем 10 клиентов и до 1000 документов в месяц на всех. Не было никакого анализа, архитектура тоже на коленке, лишь бы работало. Это был придаток к другому продукту, который просто принимал json и перекладывал их в БД или отправлял дальше.
Сначала он был моим вторым проектом, где меня просили что-нибудь доработать по мелочи, поправить багу, или добавить какую-нибудь фичу. Я на протяжении двух лет не делал ничего лишнего. Вот как в статье написано. Каждая фича по отдельности была простой.
Через два года бахнуло. Его начали продавать, повалили клиенты, крупные клиенты (сотня-другая тысяч документов на одного клиента в месяц, а сейчас речь уже идет о 500 тыс - миллионе) и начались проблемы. И это оказался франкенштейн, который делает не то, что нужно, не выдерживает никакой нагрузки и в обработке фоновых задач клиенты мешают друг другу.
Ну и пришлось его переписывать на живую примерно год. И то не хватило времени. Не все было исправлено и сделано как надо. И все это время я выслушивал претензии, типа а как так вышло.
Так что нет, и еще раз нет. Сначала предварительный анализ, вот типа как на собесах по системному дизайну:
Вопрос: сколько потенциальных клиентов, ответ: ну как минимум все те, кто уже есть у компании и пользуются существующими продуктами компании
Вопрос: а какая нагрузка? Ответ: ну если посмотреть наши другие продукты, то вот тут например 500 000 документов (не запросов, один документ - это десятки-сотни запросов в базы данных и другие системы, пока он проходит весь воркфлоу) в день
Потом архитектура на основе этого (там тоже можно заложить точки роста, была даже книга Эволюционная архитектура).
И вот уже потом можно сколько угодно говорить о том, как писать простой код в рамках заданной архитектуры. Потому что менять архитектуру и подходы - это долго и сложно.
И в противовес есть два других продукта, которые были сделаны не тяп-ляп, а с анализом, архитектурой (подходящей архитектурой, второй из них был гораздо более простым и его не надо было интегрировать в ESB). И там, на удивление, и код получился более простым и понятным, не пришлось костылить.
ЗЫ: и в первую очередь надо закладывать логирование и телеметрию запросов (чтобы потом не гадать на кофейной гуще) и авто-тестирование (чтобы потом не было мучительно больно дорабатывать фичи).
Да, надоело.
Поэтому купил красную машину, и летом ношу ярко оранжевую, салатную или бордовую рубашку.
Да, мир не идеален.
Из личного опыта - в далеком 2012 году я устроился на новую работу, в один из московских системных интеграторов с обещанием дать мне возможность стать ведущим программистом. Руководитель обещание сдержал и в конце 2012 - начале 2013 назначил меня тех лидом. Команда на каждом проекте была от 2-4 до 5-7 человек. Я успел поучаствовать в двух проектах.
Кстати мне было 27-28 лет. Почти што 23 летний сениор 😅. Было ссыкотно. Интегратор работал в банковской сфере и я все ждал когда из банков наших клиентов ко мне придут матерые и лютые энтерпрайз архитекторы с вопросами "а почему ты выбрал такую архитектуру?" или "как ты собираешься интегрировать свои сервисы с нашей IBM Service Bus" и все вскроется, а меня уволят 😁
Я не настраивал процессы, не лез в душу к людям, не нанимал и не увольнял. Я делал каркас солюшена, выбирал технологии, закладывал подходы. И потом программисты пилили бизнес-логику уже без меня. Один из проектов был основным, где я участвовал в роли программиста и проводил код ревью. Изумительное время тогда было. Процессы были самые лучшие из всех, когда я либо видел до и после. Я работал с людьми, кто впоследствии стали лидами/сениорами во всяких Швециях, Испаниях, Германиях и Канадах.
Но приходилось распределять задачи, и было пару моментов с людьми..., без конфликтов. Типа чел не любил делать отчеты (UI часть), а я пытался показать ему другую точку зрения. Я понимал, что это обязанности тим-лида. И у меня довольно долго в резюме был указан опыт тим-лидерства. И однажды мне стали писать с вакансиями именно тим-лидов, без кодинга, без технологий. Вот именно тогда я понял, что тим-лид это совершенно другая роль. В тех вакансиях были усложненные требования и обязанности, которых я не приобрел. И я убрал тим-лидерство из своего резюме.
Тут можно писать в отчет что-то типа
10:00-10:01 запустил комп и открыл отчет за день
10:01-10:02 писал в отчет что делал в предыдущую минуту с 10:00 по 10:01
10:02-10:03 писал в отчет что делал в предыдущую минуту с 10:01 по 10:02
Как всегда - каждая компания под лычкой лида понимает что-то свое. Но я не ожидал такого от Альфа-Банка. В описании мешанина тим-лида и тех-лида + вешают обязанности продукт овнера. А это значит вы, автор, работаете за двоих или даже троих, а зарплату получаете за одного.
Тех лид - это
Техническое виденье продуктов, технологии, технические подходы в решении задач. Примерами могут являться - курирование разработки единой платформы для всех продуктов, R&D для оценки внедрения очередной технологии (колоночная БД, какой-нибудь новый брокер, тарантул,
замена джуноввнедрение ИИ и тому подобное)Я бы сказал, что он делит обязанности улучшения процессов (наравне с тим-лидом, руководителем отдела, CTO). Например внедрение метрик качества архитектуры, ревью кода и тому подобное
Тех-лид НЕ решает межличностные конфликты. Не является единственным или главным ЛПР при найме в команду или увольнении. Тех-лид не распределяет задачи и не является ведущим дейликов
Тех-лид обязан работать с кодом и технологиями, иначе со временем его знания и кругозор устареет. Поэтому, если на него вешать еще и пункты 2 и 3 в полной мере - у такого человека не будет времени поддерживать техническую экспертизу
Тех-лид обязан читать техническую литературу
Тим-лид - а вот этот чувак перформит команду:
Решает конфликты, строит планы обучения и развития карьеры
Принимает на работу с (совместно руководителем отдела, CTO), проводит ежегодную оценку, увольняет
Больше участвует в улучшении процессов. Потому что процессы - это в основном для людей. С командой доброжелательных сениоров можно местами и подзабить на процессы. А вот джунов и зуммеров надо регулярно пинать, чтобы они нормально работали
Тим-лид читает литературу по управлению людьми, психологии.
И если пройтись по этим пунктам
Ну так иди и чини ее. Но на самом деле это больше к руководителю отдела / CTO, потому что проблема в отсутствии тестирования / сбой в процессах. Тех-лид может посоветовать какую технологию или подход использовать для тестирования. Или посоветовать с настройкой человеческих процессов.
Это чисто работа тим-лида.
Почему продукт овнер перекладывает свою работу на тех-лида? Оценка идей - это не работа тех-лида. У него можно спросить "а можно ли в телефоне заблокировать звонки" и только.
Аналогично - с такими вопросами и предложениями к продукт овнеру, пускай сами там разбираются.
Пожалуй единственный более-менее подходящий пример. Если много компонентов и много команд. Тут как раз нужна оценка технических глубин, чтобы примерно понять - баг это или фича и где он примерно может быть.