Странная статья. Мне всегда казалось, что машину выбирают под задачи. Есть задачи, которые можно решить как на маке, так и на Линуксе, в целом одинаково комфортно, есть где одно удобнее другого, а есть, где одно подходит, а другое - нет, и тут уже "фи" не работает, потому что по-другому никак или очень неэффективно. А в статье описывается алюминий, ссд и ещё всякое, что очень косвенно влияет на решение рабочих задач. Холиварная статья на мой взгляд
Это в том случае, если начальство не умеет признавать свои ошибки. Но мы же все люди. Поэтому начальство начальству - рознь. Нормальный начальник как раз попытается разобраться в реальной проблеме. Потом исправить ситуацию всеми возможными способами, если это в его силах. А то, что вы описали - на мой взгляд ненормально. Потому что все мы люди, и все мы ошибаемся. И мудрый человек понимает это.
В целом конечно, в статье очень много утверждений, не подкрепленные каким-либо доказательством.
Идея проста и элегантна: код, который легко и удобно тестировать, — это хорошо спроектированный код.
Откуда это следует? Я вот совсем связи не прослеживаю. Код, который легко и удобно тестировать - легко и удобно тестируемый, но это не делает его автоматически хорошо спроектированным. Да, он может быть лучше спроектирован, чем код, который писался без оглядки на тесты, но до "хорошо" ему монет быть как до луны.
Представьте, что вы строите дом и в первую очередь думаете о том, как его будут проверять на прочность, безопасность и удобство. Логично, что такой дом получится качественным.
Так себе аналогия. В отличие от дома более-менее средний проект (если это не мвп или проект одной задачи) постоянно эволюционирует. И требования могут меняться, что может потребовать различных твистов, вплоть до переписывания большей части проекта. С домом такое редко бывает, разве что вы изначально не знаете, что вам нужно и дом постоянно перестраивается и стройка никогда не закончится.
Очень спорная статья. Я бы сказал, что хорошо спроектированным код - это код, который легко понимать и изменять под новые требования, само собой не ломая существующий функционал. А как этого достичь, это обширная тема, причем на только технического характера, но и организационная часть имеет тут немалое значение
Статья от фронтенд-разработчика. Там специфика такова, что в большинстве проектов большими объемами данных приходится оперировать очень редко. Отчасти из-за того, что хранить состояние на клиенте - моветон. Отчасти из-за того, что а этом просто нет необходимости, потому что можно получать данные частями и работать с такими банками вполне нормально без ограничения в функциональности для конечного пользователя. Поэтому и статья написана с таким учётом, хотя явно не указано. А стоило бы. Часть вещей фреймворко и языкозависимая.
У FastAPI есть какие-то серьезные отличия в процессе развертывания от других веб-проектов на Python, что для него требуется целый отдельной сервис? Инфраструктурные ж вещи вроде докера и кубера не делаются специально под конкретные библиотеки, поскольку очевидно, что это независимая часть. Или в этом сервисе чисто пару скриптов, да докер файл для сборки, все остальное к питону не имеет прямого отношения?
Ну вообще питон - язык общего назначения, а не только для обработки данных. Хоть он и не может похвастаться легковесностью для десктопа, но зато у него есть другое преимущество - скорость разработки и прототипирования сильно выше, чем у того же с++ за счёт более высокой абстракции кода и большой библиотеки (не только стандартной) для решения различных типовых задач. Популярность этого языка кстати не только в сфере обработки данных, его успешно применяют и для веб-разработки, и для машинного обучения.
Умеет ли пип правильно находить совместимые версии подзависимостей основных зависимостей? Когда я последний раз его использовал, он просто писал, что не может установить нужную версию, потому что конфликт версий. При этом поетри сам находил совместимую версию подзависимости, которая подходит для нескольких зависимостей одновременно.
Помилуйте , одним диктом все конфинурируется через dictConfig. Если хочется прям совсем просто, то basicConfig одной строчкой. Но если вам прям совсем лень даже доку прочитать на 15 минут, ну тогда наверное loguru для вас. До момента, когда понадобится понимать, как оно работает
Ну я больше в веб-разработке и больше в стартапах. Таких продуктов, как у вас, у меня в портфолио нет. Банковский софт - это вообще отдельная категория. Специфическая, я бы сказал. Поэтому я и не работал в банках, потому что там по понятным причинам все очень зарегулировано. И ни вдохнуть ни ... без разрешения кучи начальников и сб. Поэтому тут вы правы, признаю. В вашей сфере по-другому никак.
Я не писал про рефакторинг ради рефакторинга. Где вы это прочитали? Или в вашей картине мира есть либо крупный рефакторинг, либо нет никакого. У вас либо с планированием беда, либо с коммуникацией с вашим руководством, если вы не можете донести до него, что уборку тоже нужно включать в планы. Ну, либо вы работаете в структуре, где "я начальник, я лучше знаю". В таких условиях донести что-то до руководства очень сложно.
Вы же в квартире уборку делаете регулярно? Или как стало грязно, сразу ремонт планируете? Вот тут то же самое. Если планировать только глобальный рефакторинг, то он на моей практике наступал очень редко. Просто потому, чтобы выделить столько времени - будет страдать доставка функционала. А это психологически сложнее сделать, чем выделять время в задачах, в которых без причесывание придется костыли ставить. Ну и сама необходимость "большого" рефакторинга говорит о том, что либо изначально была негибкая архитектура, либо не выделяли времени вовремя, вот и накопилось, что нужно прям много переделывать.
На моей практике "причесывние* поэтапно намного эффективнее, чем глобальный рефакторинг в ущерб доставке функционала.
Ещё как зависит) Если, допустим, надо написать скрипт, обрабатывающий файл, который после обработки больше не понадобится, будет совсем неразумно тратить время на проектирование архитектуры и подбор фреймворка., который тут не нужен априори. Если же проект - что-то чуть большее чем одностраничное веб приложение или калькулятор, то конечно, имеет смысл посмотреть и в сторону фреймворков и паттернов и других умных слов, которые вы написали)
Ну, фреймворк как правило берут потому, что в нем уже реализовано большинство функционала, который вам надо будет реализовывать самостоятельно. И напишите ли вы лучшее - большой вопрос, все зависит от вашего опыта. Но у такого подхода есть как минимум 2 больших недостатка: уйма потраченного времени на написание велосипеда и время, которое будут тратить новички, в проекте, чтобы разобраться, что вы написали.
А чтобы условное устаревание используемого фреймворка вас на сильно беспокоило, слой бизнес логики надо делать независимым от фреймворка, чтобы переезд на другой фреймворк не съедал много времени. Ну и обновляться надо вовремя. И выбирать фреймворк стоит как жену, то есть тщательно и надолго.
Если у вас строго типизированный язык, то могу предположить, что с интерфейсами проще тестировать. Например, используя dependency injection. Но у меня контекста мало, поэтому это только предложение)
Такое часто бывает, если сроки диктуются сверху без учёта мнения и реальных возможностей исполнителей. Либо исполнители идут на поводу у руководства из-за боязни быть уволенными. Если убрать эти 2 фактора и считать, что у нас нормальные ребята, которые любят свою работу и стараются делать ее хорошо, всегда можно взять больше времени на причесывание кода. Больше скажу, адекватное руководство идёт навстречу, если уметь правильно обосновать затраты, а не в духе "у нас будет меньше Легаси". Все в ваших руках.
Статья про то, как ребята не осилили в нормальную архитектуру со слабой связностью, но решили, что микросеовисы решат все проблемы. Чтобы идти в микросеовисы, надо хорошо понимать, какие преимущества и недостатки принесет с собой эта архитектура. И два, а лучше 3 раза взвесить, реально ли вы хотите туда идти, учитывая ту сложность, которую она добавляет и какие усилия нужно приложить, чтобы туда прийти и потом это все поддерживать. Ну и как? Теперь прод не падает?
Странная статья. Мне всегда казалось, что машину выбирают под задачи. Есть задачи, которые можно решить как на маке, так и на Линуксе, в целом одинаково комфортно, есть где одно удобнее другого, а есть, где одно подходит, а другое - нет, и тут уже "фи" не работает, потому что по-другому никак или очень неэффективно. А в статье описывается алюминий, ссд и ещё всякое, что очень косвенно влияет на решение рабочих задач. Холиварная статья на мой взгляд
У тс другие задачи, ему кроссплатформенная разработка не нужна. Была бы нужна, статьи бы не было)
И что же они умеют? Из заголовка ожидаешь какого-то сравнивая что-ли .
Это в том случае, если начальство не умеет признавать свои ошибки. Но мы же все люди. Поэтому начальство начальству - рознь. Нормальный начальник как раз попытается разобраться в реальной проблеме. Потом исправить ситуацию всеми возможными способами, если это в его силах. А то, что вы описали - на мой взгляд ненормально. Потому что все мы люди, и все мы ошибаемся. И мудрый человек понимает это.
В целом конечно, в статье очень много утверждений, не подкрепленные каким-либо доказательством.
Откуда это следует? Я вот совсем связи не прослеживаю. Код, который легко и удобно тестировать - легко и удобно тестируемый, но это не делает его автоматически хорошо спроектированным. Да, он может быть лучше спроектирован, чем код, который писался без оглядки на тесты, но до "хорошо" ему монет быть как до луны.
Так себе аналогия. В отличие от дома более-менее средний проект (если это не мвп или проект одной задачи) постоянно эволюционирует. И требования могут меняться, что может потребовать различных твистов, вплоть до переписывания большей части проекта. С домом такое редко бывает, разве что вы изначально не знаете, что вам нужно и дом постоянно перестраивается и стройка никогда не закончится.
Очень спорная статья. Я бы сказал, что хорошо спроектированным код - это код, который легко понимать и изменять под новые требования, само собой не ломая существующий функционал. А как этого достичь, это обширная тема, причем на только технического характера, но и организационная часть имеет тут немалое значение
Статья от фронтенд-разработчика. Там специфика такова, что в большинстве проектов большими объемами данных приходится оперировать очень редко. Отчасти из-за того, что хранить состояние на клиенте - моветон. Отчасти из-за того, что а этом просто нет необходимости, потому что можно получать данные частями и работать с такими банками вполне нормально без ограничения в функциональности для конечного пользователя. Поэтому и статья написана с таким учётом, хотя явно не указано. А стоило бы. Часть вещей фреймворко и языкозависимая.
У FastAPI есть какие-то серьезные отличия в процессе развертывания от других веб-проектов на Python, что для него требуется целый отдельной сервис? Инфраструктурные ж вещи вроде докера и кубера не делаются специально под конкретные библиотеки, поскольку очевидно, что это независимая часть. Или в этом сервисе чисто пару скриптов, да докер файл для сборки, все остальное к питону не имеет прямого отношения?
Ну вообще питон - язык общего назначения, а не только для обработки данных. Хоть он и не может похвастаться легковесностью для десктопа, но зато у него есть другое преимущество - скорость разработки и прототипирования сильно выше, чем у того же с++ за счёт более высокой абстракции кода и большой библиотеки (не только стандартной) для решения различных типовых задач. Популярность этого языка кстати не только в сфере обработки данных, его успешно применяют и для веб-разработки, и для машинного обучения.
Умеет ли пип правильно находить совместимые версии подзависимостей основных зависимостей? Когда я последний раз его использовал, он просто писал, что не может установить нужную версию, потому что конфликт версий. При этом поетри сам находил совместимую версию подзависимости, которая подходит для нескольких зависимостей одновременно.
Посмотрите в сторону uv, он позволяет несколько версий питона держать, разные виртуальные окружения на их основе.
Помилуйте , одним диктом все конфинурируется через dictConfig. Если хочется прям совсем просто, то basicConfig одной строчкой. Но если вам прям совсем лень даже доку прочитать на 15 минут, ну тогда наверное loguru для вас. До момента, когда понадобится понимать, как оно работает
В офф. документации есть пара способов) Не поленитесь зайти и почитать, если действительно интересно
Ну я больше в веб-разработке и больше в стартапах. Таких продуктов, как у вас, у меня в портфолио нет. Банковский софт - это вообще отдельная категория. Специфическая, я бы сказал. Поэтому я и не работал в банках, потому что там по понятным причинам все очень зарегулировано. И ни вдохнуть ни ... без разрешения кучи начальников и сб. Поэтому тут вы правы, признаю. В вашей сфере по-другому никак.
Я не писал про рефакторинг ради рефакторинга. Где вы это прочитали? Или в вашей картине мира есть либо крупный рефакторинг, либо нет никакого. У вас либо с планированием беда, либо с коммуникацией с вашим руководством, если вы не можете донести до него, что уборку тоже нужно включать в планы. Ну, либо вы работаете в структуре, где "я начальник, я лучше знаю". В таких условиях донести что-то до руководства очень сложно.
Вы же в квартире уборку делаете регулярно? Или как стало грязно, сразу ремонт планируете? Вот тут то же самое. Если планировать только глобальный рефакторинг, то он на моей практике наступал очень редко. Просто потому, чтобы выделить столько времени - будет страдать доставка функционала. А это психологически сложнее сделать, чем выделять время в задачах, в которых без причесывание придется костыли ставить. Ну и сама необходимость "большого" рефакторинга говорит о том, что либо изначально была негибкая архитектура, либо не выделяли времени вовремя, вот и накопилось, что нужно прям много переделывать.
На моей практике "причесывние* поэтапно намного эффективнее, чем глобальный рефакторинг в ущерб доставке функционала.
Ещё как зависит) Если, допустим, надо написать скрипт, обрабатывающий файл, который после обработки больше не понадобится, будет совсем неразумно тратить время на проектирование архитектуры и подбор фреймворка., который тут не нужен априори. Если же проект - что-то чуть большее чем одностраничное веб приложение или калькулятор, то конечно, имеет смысл посмотреть и в сторону фреймворков и паттернов и других умных слов, которые вы написали)
Ну, фреймворк как правило берут потому, что в нем уже реализовано большинство функционала, который вам надо будет реализовывать самостоятельно. И напишите ли вы лучшее - большой вопрос, все зависит от вашего опыта. Но у такого подхода есть как минимум 2 больших недостатка: уйма потраченного времени на написание велосипеда и время, которое будут тратить новички, в проекте, чтобы разобраться, что вы написали.
А чтобы условное устаревание используемого фреймворка вас на сильно беспокоило, слой бизнес логики надо делать независимым от фреймворка, чтобы переезд на другой фреймворк не съедал много времени. Ну и обновляться надо вовремя. И выбирать фреймворк стоит как жену, то есть тщательно и надолго.
Все зависит от проекта. Чтобы построить сарай, не нужен Гауди.
Если у вас строго типизированный язык, то могу предположить, что с интерфейсами проще тестировать. Например, используя dependency injection. Но у меня контекста мало, поэтому это только предложение)
Такое часто бывает, если сроки диктуются сверху без учёта мнения и реальных возможностей исполнителей. Либо исполнители идут на поводу у руководства из-за боязни быть уволенными. Если убрать эти 2 фактора и считать, что у нас нормальные ребята, которые любят свою работу и стараются делать ее хорошо, всегда можно взять больше времени на причесывание кода. Больше скажу, адекватное руководство идёт навстречу, если уметь правильно обосновать затраты, а не в духе "у нас будет меньше Легаси". Все в ваших руках.
Статья про то, как ребята не осилили в нормальную архитектуру со слабой связностью, но решили, что микросеовисы решат все проблемы. Чтобы идти в микросеовисы, надо хорошо понимать, какие преимущества и недостатки принесет с собой эта архитектура. И два, а лучше 3 раза взвесить, реально ли вы хотите туда идти, учитывая ту сложность, которую она добавляет и какие усилия нужно приложить, чтобы туда прийти и потом это все поддерживать. Ну и как? Теперь прод не падает?