Честно, я не осилил... Вы так много написали и в таком стиле, что это сложно читать и воспринимать. Возможно, я технарь и хочется видеть больше конкретики. И цитируя классиков - краткость, сестра таланта.
Я честно абсолютно не против того, что кто-то навайбкодит себе нужное ему приложение и будет им пользоваться, в этом нет проблем, они начинаются тогда, когда начинают все подряд вайбкодить для других особенно в коммерческих приложениях. Да, мне не посчастливилось работать в проектах с "индусским кодом", и ИИ часто генерит код "получше", но поддерживать потом такие проекты может быть одинаково больно. Когда хороший разработчик делает приложение, он не просто делает happy path, но продумывает edge cases, защиты, безопасность, совместимость, поддержку... да ключевое слово "хороший", но большинство всё таки старается быть хорошими (очень хочется верить, что процент людей с девизом "компилируется и отлично, протестирую на продакшене" всё таки небольшой), а вот ИИ просто делает, что ему сказали, и тут наверное аналогичное отличие вайбкодера от инженера-вайбкодера (второй сам код не пишет, но старается дать ИИ понять какие дополнительные условия нужно учесть). ИИ это инструмент, который хорошо работает в хороших руках.
Я могу ошибатся, но во время прочтения статьи закралось чувство, что изначальная цель была неправильной - переписать всё. Ну это как "Отбойный молоток работает быстро и бъёт сильно, выкидываем обычные молотки... Ой, что-то отбойным молотком неудобно дверные косяки подбивать, но вот мы нашли решение сложное и громозкое зато работает ...". Вы же делали вероятно переход из-за преимуществ gRPC - быстродействие (и ряд других), мне кажется было бы проще перевести только самые критические API, а остальное оставить как есть. Вот возьмём банк, есть API платежей супер критично, должно работать быстро, + обратная совместимость, + двунаправленность, а есть API отчётов, API открыть/посмотреть/редактировать/закрыть счёт, API проверки можно ли дать иппотеку/кредит/ссуду/рассрочку, и т.д. что используется на несколько порядков реже и не требует молниеносного ответа. И вот в итоге, могло оказаться, что для самых критичных API и не нужны nullable (да, связка значение и флаг), enum (константы), decimal (передаём деньги в центах), DateTime (используем тики/секунды от 01/01/1900 и т.д.), generic и наследования, и было бы достаточно примитивных типов. Конечно, как я писал - я могу ошибаться, так как не видел вашей системы и её кода, это просто мои рассуждения вслух. А в целом, статья написана и оформлена отлично, спасибо, что поделились опытом.
Буквально на днях столкнулся с интересным багом - у знакомого на Windows 11 не работал интернет по кабелю, в Настройках вроде всё правильно, включено автоматическое получение IP адреса, но вот он почему-то не назначался, в роутере LAN настроен правильно, и вот я решил залезть в Панель управления и глянуть как там сеть настроена - оказалось там уже было ручное получение IP адреса. Итог - два интерфейса и различное поведение, причём в новом неправильное значение.
А я бы добавил - соблюдайте одинаковый порядок кнопок во всем приложении/системе. Не как в Windows, то Печать/Отмена, то Ок/Справка, то Отмена/Ок, а то Да/Нет и главная кнопка, то слева, то справа. Я понимаю, что делали разные люди в разное время, но неужели так сложно это исправить... Примеров, к сожалению, не смогу привести с телефона.
Я вообще честно оптимист, но даже находясь в стационарном помещении меня и некоторых моих знакомых бывает от VR укачивает, а тут движущаяся машина... Нет, может ауди так плавно едет, поворачивает и тормозит, что пассажир ничего не почувствует. В общем, даже будучи оптимистом, я бы не разрешил пассажирам (а у меня это дети) на заднем сиденье играть VR по дороге в новенькой ауди. Мне кажется, хороший промышленный дизайн - это когда удобно и органично, а эта подборка о дизайне ради дизайна.
Спасибо за статью, было очень интересно почитать, вы очень подробно описали проект. Конечно у каждого проекта свои потребности, но ваши подходы и решения могут быть полезны начинающим архитекторам. Я бы даже сказал, что ваша статья лучше некоторых лекций и курсов, с которыми я сталкивался.
Заметил, что часто в коде над которым работают несколько разработчиков, возникает разница в порядке слов, например, mainDocument и documentMain в разных местах. В обоих случаях можно найти свои за и против, и единого стиля в итоге на проекте нет.
За статью спасибо, полезно бывает задуматься о таких базовых вещах.
Прошу прощения за полёт мысли, но статья кажется слишком фантастичной. Общие авто существуют и сегодня, они дешевле чем покупать себе собственную машину того же качества, но особой популярностью они не пользуются, как писали выше — очередная ниша около такси. Свой автомобиль может и дорого, но это как своя квартира и общежитие, в своём автомобиле мне уютно, а садясь в такси — я чувствую, что это чужая территория. Пока общество построенно на потреблении, производители стремятся поддерживать принцип — владеть чем-то это круто. Поэтому тезис про общие беспилотные авто считаю утопией. Про голос и мысли — красиво, но я с "Ок, Гугл" максимум погоду могу проверить и будильник поставить, в остальном проще пальцами. А мыслями можно так "Создать письмо начальнику. Готово. И, что писать этому старому козлу? Что-то нужно отправить? Готово, ваше письмо отправлено! Ааааа!!!".
А тут очень интересный вопрос, что вы подразумеваете под словом «эффективность»? Больше фич, лучше качество, меньше стресса, больше доход… Одновременно всё? Я, проработав в куче проектов по разным методологиям как разработчик, ни разу не видел эффективности всего. Бывает за счёт снижения качества и увеличения стресса поднимают показатели количества фич (количество попугаев за спринт). Иногда наоборот, приходит новый менеджер и начинает заботится о качестве, в итоге меньше багов, больше тестов, меньше инцидентов, но вот только фич тоже меньше. А бывает, что не все фичи реально нужны, и просто возрастает процент бесполезных фич. Или тот же «кнут и пряник» — всё будет замечательно, кроме постоянного поиска и обучения новых сотрудников. Очень часто и разработчики, и те кто ими управляют всего лишь наёмные сотрудники для которых методологии это просто «бурление» чтоб показать свою «важность». Да и вообще, методологии сами по себе можно по разному применять. Я это всё к тому, что реальное влияние на доходы (текущие и особенно будущие) сложно коррелировать с методологиями разработки, они несомненно нужны, но должны подбираться под конкретный проект и сложность этого экспоненциально растёт с ростом компании.
Согласен с lair, но добавил бы ещё, что можно использовать разные типы exceptions (как стандартные, так и свои) для разных мест в коде, чтоб потом «ориентироваться откуда оно появилось». И вообще решение автора смотрится достаточно громоздко, запутанно, в команде из нескольких человек — будет вызывать конфликты.
Возможно вы и правы, вам виднее, но мне просто понравилось почитать красивую выдумку, заставляющую читателя побыть в роли Коли, Феди, Иры… Как-то вспомнилась что-ли молодость, учёба. Почти 13 лет прошло, многое кануло в лета, и забылось, а тут вот автор мне напомнил, что кроме семьи и работы у меня была другая жизнь. Преподаватели разные были — мудрые, умные, «добрые», строгие и глупые, и соответственно экзамены по знаниям, по шпорам, с бомбами и с пересдачами… а раз я даже за другого студента другого курса устно сдавал и сдал. Сейчас, мне кажется для моей текущей жизни, условий, бизнеса и семьи, большую пользу дали эти навыки «выживания» на экзаменах, ты учишься изворачиваться, и находить выход из тупиковых ситуаций, искать альтернативы, использовать знания, те что есть, по полной, и не сдаваться на пересдачах (да уж, тогда это казалось проблемами).
Интересный в каком-то смысле материал, можно ещё Roslyn подключить и анализировать код сборок, но полезность сомнительная. Извините, я спрашиваю из любопытства, а зачем вообще засовывать сборки в базу и ещё в таком количестве, чтоб потом специальным образом их искать и просматривать? На ум приходит некая система плагинов для клиентского приложения.
Как программист работавший в разных компаниях разрабатывающих проприетарное ПО, скажу, что не всегда тесты пишутся действительно качественно, случается, что они пишутся «чтоб было». А как писали выше, у заказчика вряд ли будут специалисты, средства и время на то, чтоб провести анализ этих тестов (учитывая, что тесты могут использовать какие-то фреймворки, запутанные патерны, инициализации и т.д. и т.п.). Есть компании, например, медицинские, которые сами пишут приёмочные тесты, и не примут релиз пока каждый тест не пройдёт — им это критично, они готовы за это платить. А если для бизнеса поломка продукта не критична, то выбирая продукт бизнес будет ориентироваться на известность, количество существующих клиентов, функционал и цену, а уже потом на наличие тестов. Машины, самолёты, оружие, медицинское оборудование — открыто тестируется просто потому, что их выход из строя очень критичен.
Так как интуитивно мне тоже казалось, что строки «abc» и «aaa» равнозначны и верить автору никак не хотелось, то я написал свой вариант проверки на C# dotnetfiddle.net/Ice8sV (желательно запускать с большим количеством итераций на локальном компьютере). Прогонял несколько раз и практически всегда стока «abc» собирается чаще чем «aaa» — с теор.вером. сложно спорить. Спасибо автору за интересную головоломку!
Честно, я не осилил... Вы так много написали и в таком стиле, что это сложно читать и воспринимать. Возможно, я технарь и хочется видеть больше конкретики. И цитируя классиков - краткость, сестра таланта.
А самое главное, что в .Net 11 это перестаёт быть "синтаксическим сахаром" и становится "родной асинхроностью среды выполнения" (подробности тут https://learn.microsoft.com/ru-ru/dotnet/core/whats-new/dotnet-11/runtime#runtime-async или тут https://www.youtube.com/watch?v=8Gl2RmUV0hg), так что все эти сакральные знания "во что компилируется код async/await" перестают быть такими однозначными.
Я честно абсолютно не против того, что кто-то навайбкодит себе нужное ему приложение и будет им пользоваться, в этом нет проблем, они начинаются тогда, когда начинают все подряд вайбкодить для других особенно в коммерческих приложениях. Да, мне не посчастливилось работать в проектах с "индусским кодом", и ИИ часто генерит код "получше", но поддерживать потом такие проекты может быть одинаково больно. Когда хороший разработчик делает приложение, он не просто делает happy path, но продумывает edge cases, защиты, безопасность, совместимость, поддержку... да ключевое слово "хороший", но большинство всё таки старается быть хорошими (очень хочется верить, что процент людей с девизом "компилируется и отлично, протестирую на продакшене" всё таки небольшой), а вот ИИ просто делает, что ему сказали, и тут наверное аналогичное отличие вайбкодера от инженера-вайбкодера (второй сам код не пишет, но старается дать ИИ понять какие дополнительные условия нужно учесть). ИИ это инструмент, который хорошо работает в хороших руках.
Я могу ошибатся, но во время прочтения статьи закралось чувство, что изначальная цель была неправильной - переписать всё. Ну это как "Отбойный молоток работает быстро и бъёт сильно, выкидываем обычные молотки... Ой, что-то отбойным молотком неудобно дверные косяки подбивать, но вот мы нашли решение сложное и громозкое зато работает ...". Вы же делали вероятно переход из-за преимуществ gRPC - быстродействие (и ряд других), мне кажется было бы проще перевести только самые критические API, а остальное оставить как есть. Вот возьмём банк, есть API платежей супер критично, должно работать быстро, + обратная совместимость, + двунаправленность, а есть API отчётов, API открыть/посмотреть/редактировать/закрыть счёт, API проверки можно ли дать иппотеку/кредит/ссуду/рассрочку, и т.д. что используется на несколько порядков реже и не требует молниеносного ответа. И вот в итоге, могло оказаться, что для самых критичных API и не нужны nullable (да, связка значение и флаг), enum (константы), decimal (передаём деньги в центах), DateTime (используем тики/секунды от 01/01/1900 и т.д.), generic и наследования, и было бы достаточно примитивных типов. Конечно, как я писал - я могу ошибаться, так как не видел вашей системы и её кода, это просто мои рассуждения вслух.
А в целом, статья написана и оформлена отлично, спасибо, что поделились опытом.
Буквально на днях столкнулся с интересным багом - у знакомого на Windows 11 не работал интернет по кабелю, в Настройках вроде всё правильно, включено автоматическое получение IP адреса, но вот он почему-то не назначался, в роутере LAN настроен правильно, и вот я решил залезть в Панель управления и глянуть как там сеть настроена - оказалось там уже было ручное получение IP адреса. Итог - два интерфейса и различное поведение, причём в новом неправильное значение.
Бонус 2 - обе реализации работают одинаково в dotnetfiddle (.Net 9), так как '
needToStopEnumeration = true', а вот с false уже как вы и пишите.А я бы добавил - соблюдайте одинаковый порядок кнопок во всем приложении/системе. Не как в Windows, то Печать/Отмена, то Ок/Справка, то Отмена/Ок, а то Да/Нет и главная кнопка, то слева, то справа. Я понимаю, что делали разные люди в разное время, но неужели так сложно это исправить... Примеров, к сожалению, не смогу привести с телефона.
Я вообще честно оптимист, но даже находясь в стационарном помещении меня и некоторых моих знакомых бывает от VR укачивает, а тут движущаяся машина... Нет, может ауди так плавно едет, поворачивает и тормозит, что пассажир ничего не почувствует. В общем, даже будучи оптимистом, я бы не разрешил пассажирам (а у меня это дети) на заднем сиденье играть VR по дороге в новенькой ауди. Мне кажется, хороший промышленный дизайн - это когда удобно и органично, а эта подборка о дизайне ради дизайна.
Спасибо за статью, было очень интересно почитать, вы очень подробно описали проект. Конечно у каждого проекта свои потребности, но ваши подходы и решения могут быть полезны начинающим архитекторам. Я бы даже сказал, что ваша статья лучше некоторых лекций и курсов, с которыми я сталкивался.
За статью спасибо, полезно бывает задуматься о таких базовых вещах.
Прошу прощения за полёт мысли, но статья кажется слишком фантастичной. Общие авто существуют и сегодня, они дешевле чем покупать себе собственную машину того же качества, но особой популярностью они не пользуются, как писали выше — очередная ниша около такси. Свой автомобиль может и дорого, но это как своя квартира и общежитие, в своём автомобиле мне уютно, а садясь в такси — я чувствую, что это чужая территория. Пока общество построенно на потреблении, производители стремятся поддерживать принцип — владеть чем-то это круто. Поэтому тезис про общие беспилотные авто считаю утопией. Про голос и мысли — красиво, но я с "Ок, Гугл" максимум погоду могу проверить и будильник поставить, в остальном проще пальцами. А мыслями можно так "Создать письмо начальнику. Готово. И, что писать этому старому козлу? Что-то нужно отправить? Готово, ваше письмо отправлено! Ааааа!!!".
P.S. Извините, что много текста — наболело.