Алгоритмы, это очень важная состовляющая ПО. Плохой алгоритм не компенсирует ни одна хорошая архитектура и дизайн кода. Но справедливо и обратное. Если код плохо оформлен, не правильно спроектирован, имеет высокую связность и т.д. его трудно будет изменять. Если код трудно изменять, значит новые требования будут реализовываться дольше и поддержка такого продукта будет неумолимо увеличиваться. Соответственно, будет сложно успеть за рынком.
Поэтому, считаю, что не нужно алгоритмы противопостовлять архитектуре. Они одинаково важны и задача разработчика удержать баланс этих состовляющих. В зависимости от специфики и нефункциональных требований приложения, чаша весов может отклонятся в сторону алгоритмов или архитектуры.
что в большинстве случаев разработчик-фрилансер далек от "полноправного участника бизнеса"
противостояние происходит на разных уровнях, но поле боя одно.
Даже в большинстве крупных корпораций есть специальные люди, которые следят за тем, чтобы bus factor не обрушил проект, и сохранялась взаимозаменяемость людей и преемственность архитектуры. Там тоже "полноправность" для большинства условна
понятно что есть некоторая иерерхия разработчиков в крупных компаниях. Я же, во-первых, имею ввиду некий собирательный образ разработчика, во-вторых, это зависит от того, как разработчик себя позиционирует в рамках своей команды и компании в целом. Разработчик, который на стороне тех кто про "лишь бы платили" вероятно так и не выростет до того, кто, все же, принимает решения. И, вероятно, уйдет из компании фрилансить. А тех фрилансеров, которые на другой стороне, с высокой долей вероятности заберут в штат.
"Чистая архитектура" стр. 39. "Битва за архитектуру".
Не сомневаюсь, что вы умеете читать между строк
ЗЫ: Добавлю для читателей, чтобы не пришлось качать книжку
Эффективные команды разработчиков часто выходят победителями в этой борьбе. Они открыто и на равных вступают в конфликт со всеми другими заинтересованными сторонами. Помните: как разработчик программного обеспечения вы тоже являетесь заинтересованной стороной. У вас есть свой интерес в программном обеспечении, который вы должны защищать. Это часть вашей роли и ваших обязанностей. И одна из основных причин, почему вас наняли.
В целом, я с Вами согласен. Возможны варианты. Но тут уже виднеется территория противостояния двух философий или отношений к своей профессии. На одной стороне люди, которые "лишь бы платили", а с другой полноправные участники бизнеса. А разработчик это полноправный участник бизнеса (по Мартину). И если я ответственный участник этих процессов, то стратегию я строю для себя, а не для нанимателя. Нанемателю, т.е. бизнесу, в подовляющем большенстве случаев(возможно ошибаюсь), глубоко плевать на структуру и архитектуру проекта, ему важно value которое приносит продукт.
Поэтому, да, варианты возможны, но нужно отдавать себе отчет на чьей ты стороне)
Все круто, но не стоит забывать о том, за что мы любим Django. Это не только DjangoORM(хотя, конечно это в большей степени), миграции и механизм конфигов из под капота и т.д. Мы любим ее еще и за то, а многие ровно за это же ее нелюбят, что она рекомендует свою, стандартную структуру проекта.
Возмем тот же Flask, что не проект, то униакльная структура и хорошо если она логична. Вхождение нового разработчика в проект на Flask это всегда вызов. В Django же все по другому. Если разработчик читал документацию Django и структура проекта этой документации соответствует, то он уже на старте много чего знает и сможет в кратчайшие сроки ориентироваться по кодовой базе. А для некоторых информация о том, что проект на Django, формирует ожидание к структуре и в целом кодовой базе. И разработчик будет испытывать негатив, когда его ожидания не будут оправдываться.
Если выбрали Django, то хорошей стратегией на перспективу будет, как можно строже, придерживаться документации. Каждое отклонение удорожает поддержку и вход новых разработчиков. Поэтому, небольшая рекомендация для тех кто только входит в индустрию и тех, кто еще не строит планов по развитию и ведению кодовой базы на дистанции, прежде чем вносить изменение в структуру проекта, отличное от рекомендаций Django, посоветуйтесть с тех.лидом или тем, кто эту роль выполняет у вас в команде/компании.
Стоит отметить, что ни бизнес логика, ни слой приложения, ни инфраструктурный слой и ни какой другой слой вашего приложения, не должны знать о том, в каком окружении они запущены. Это все конфигурируется конфигами перед запуском (переменные окружения, механизм конфигов и т.д.). Об этом также явно говорят все те же 12factor. Поэтому ваш костыль делает архитектуру менее гибкой, плодит "особые" знания для новых разработчиков проекта или, если сказать проще, удорожает поддержку и развитие кодовой базы. На старте проекта это не критично, но "теорию разбитых стекл" никто не отменял и вскоре кодовая база может обрасти такими костылями по самое немогу. В вашем случае, нужно не просто делать одинаково, а вынести эти костыли в одно место и попытаться соблюсти наш любимый DRY.
Что касается миграций, то это механизмы другого порядка и никакого отношения к приложению не имеют. Приложение ожидает уже готовую к использованию БД со всеми индексами, таблицами и т.д. Это справедливо и для unit-тестов. Механизмы миграции лучше разрабатывать и тестировать отдельно от приложения, если вы не хотите использовать сторонние, готовые, протестированные решения. Миграции накатываются перед запуском приложения. Отмечу, что код таких механизмов может храниться и рядом с приложением, но не быть его частью. Т.е. миграции не должны влиять на работу приложения напрямую.
Про одинаковое окружение говорят в тех же 12factor, но, понимать это требование буквально, такое себе занятие ИМХО. Есть важные дядьки, такие как Бек, Мартин, Фаулер. Они в унисон твердят о том, что тетсирование это основа разработки ПО и тесты должны запускаться максимально быстро и просто и проходить должны тоже максимально быстро. Для этого мы(разработчики) выстраиваем пирамиды тестирования, мокаем не важные для конкретного теста зависимости и т.д.
Если для запусков тестов у вас должны быть запущены контейнеры с MySQL/PostgreSQL, Redis и проими, то это не то, о чем говорят вышеперечисленные дядечьки. На Apple M1, например, докер работает в 3-5 раз медленнее и те же 1000 тестов будут гнаться пол минуты минимум.. а с учетом того, что в обычном режиме тесты запускаются минимум раз в минуту (привет TDD), то скорость разработки будет оставлять желать лучшего.
Я для себя нашел одно решение и пока оно меня не подводит. При локальной разработке гоняю тесты на SQLite. Но в CI/CD при каждом пуше в remote, прогоняются тесты на той БД, которая в проде. Таким образом тесты гоняются быстро при разработке и требование 12factor удовлетворяется.
Это решение справедливо, когда вы не используете чистый SQL, а используете какую либо ORM которая прячет особенности каждой БД за одним интерфейсом.
Алгоритмы, это очень важная состовляющая ПО. Плохой алгоритм не компенсирует ни одна хорошая архитектура и дизайн кода. Но справедливо и обратное. Если код плохо оформлен, не правильно спроектирован, имеет высокую связность и т.д. его трудно будет изменять. Если код трудно изменять, значит новые требования будут реализовываться дольше и поддержка такого продукта будет неумолимо увеличиваться. Соответственно, будет сложно успеть за рынком.
Поэтому, считаю, что не нужно алгоритмы противопостовлять архитектуре. Они одинаково важны и задача разработчика удержать баланс этих состовляющих. В зависимости от специфики и нефункциональных требований приложения, чаша весов может отклонятся в сторону алгоритмов или архитектуры.
Даже так? Все встало на свои места. Спасибо за дискуссию!
противостояние происходит на разных уровнях, но поле боя одно.
понятно что есть некоторая иерерхия разработчиков в крупных компаниях. Я же, во-первых, имею ввиду некий собирательный образ разработчика, во-вторых, это зависит от того, как разработчик себя позиционирует в рамках своей команды и компании в целом. Разработчик, который на стороне тех кто про "лишь бы платили" вероятно так и не выростет до того, кто, все же, принимает решения. И, вероятно, уйдет из компании фрилансить. А тех фрилансеров, которые на другой стороне, с высокой долей вероятности заберут в штат.
"Чистая архитектура" стр. 39. "Битва за архитектуру".
Не сомневаюсь, что вы умеете читать между строк
ЗЫ:
Добавлю для читателей, чтобы не пришлось качать книжку
В целом, я с Вами согласен. Возможны варианты. Но тут уже виднеется территория противостояния двух философий или отношений к своей профессии. На одной стороне люди, которые "лишь бы платили", а с другой полноправные участники бизнеса. А разработчик это полноправный участник бизнеса (по Мартину). И если я ответственный участник этих процессов, то стратегию я строю для себя, а не для нанимателя. Нанемателю, т.е. бизнесу, в подовляющем большенстве случаев(возможно ошибаюсь), глубоко плевать на структуру и архитектуру проекта, ему важно value которое приносит продукт.
Поэтому, да, варианты возможны, но нужно отдавать себе отчет на чьей ты стороне)
Все круто, но не стоит забывать о том, за что мы любим Django. Это не только DjangoORM(хотя, конечно это в большей степени), миграции и механизм конфигов из под капота и т.д. Мы любим ее еще и за то, а многие ровно за это же ее нелюбят, что она рекомендует свою, стандартную структуру проекта.
Возмем тот же Flask, что не проект, то униакльная структура и хорошо если она логична. Вхождение нового разработчика в проект на Flask это всегда вызов. В Django же все по другому. Если разработчик читал документацию Django и структура проекта этой документации соответствует, то он уже на старте много чего знает и сможет в кратчайшие сроки ориентироваться по кодовой базе. А для некоторых информация о том, что проект на Django, формирует ожидание к структуре и в целом кодовой базе. И разработчик будет испытывать негатив, когда его ожидания не будут оправдываться.
Если выбрали Django, то хорошей стратегией на перспективу будет, как можно строже, придерживаться документации. Каждое отклонение удорожает поддержку и вход новых разработчиков. Поэтому, небольшая рекомендация для тех кто только входит в индустрию и тех, кто еще не строит планов по развитию и ведению кодовой базы на дистанции, прежде чем вносить изменение в структуру проекта, отличное от рекомендаций Django, посоветуйтесть с тех.лидом или тем, кто эту роль выполняет у вас в команде/компании.
Стоит отметить, что ни бизнес логика, ни слой приложения, ни инфраструктурный слой и ни какой другой слой вашего приложения, не должны знать о том, в каком окружении они запущены. Это все конфигурируется конфигами перед запуском (переменные окружения, механизм конфигов и т.д.). Об этом также явно говорят все те же 12factor. Поэтому ваш костыль делает архитектуру менее гибкой, плодит "особые" знания для новых разработчиков проекта или, если сказать проще, удорожает поддержку и развитие кодовой базы. На старте проекта это не критично, но "теорию разбитых стекл" никто не отменял и вскоре кодовая база может обрасти такими костылями по самое немогу. В вашем случае, нужно не просто делать одинаково, а вынести эти костыли в одно место и попытаться соблюсти наш любимый DRY.
Что касается миграций, то это механизмы другого порядка и никакого отношения к приложению не имеют. Приложение ожидает уже готовую к использованию БД со всеми индексами, таблицами и т.д. Это справедливо и для unit-тестов. Механизмы миграции лучше разрабатывать и тестировать отдельно от приложения, если вы не хотите использовать сторонние, готовые, протестированные решения. Миграции накатываются перед запуском приложения. Отмечу, что код таких механизмов может храниться и рядом с приложением, но не быть его частью. Т.е. миграции не должны влиять на работу приложения напрямую.
Про одинаковое окружение говорят в тех же 12factor, но, понимать это требование буквально, такое себе занятие ИМХО. Есть важные дядьки, такие как Бек, Мартин, Фаулер. Они в унисон твердят о том, что тетсирование это основа разработки ПО и тесты должны запускаться максимально быстро и просто и проходить должны тоже максимально быстро. Для этого мы(разработчики) выстраиваем пирамиды тестирования, мокаем не важные для конкретного теста зависимости и т.д.
Если для запусков тестов у вас должны быть запущены контейнеры с MySQL/PostgreSQL, Redis и проими, то это не то, о чем говорят вышеперечисленные дядечьки. На Apple M1, например, докер работает в 3-5 раз медленнее и те же 1000 тестов будут гнаться пол минуты минимум.. а с учетом того, что в обычном режиме тесты запускаются минимум раз в минуту (привет TDD), то скорость разработки будет оставлять желать лучшего.
Я для себя нашел одно решение и пока оно меня не подводит. При локальной разработке гоняю тесты на SQLite. Но в CI/CD при каждом пуше в remote, прогоняются тесты на той БД, которая в проде. Таким образом тесты гоняются быстро при разработке и требование 12factor удовлетворяется.
Это решение справедливо, когда вы не используете чистый SQL, а используете какую либо ORM которая прячет особенности каждой БД за одним интерфейсом.