Comments 15
Следующий логичный шаг – написать свой cookiecutter.
В Pycharm также django доступна как framework в настройках
Можете подробнее раскрыть уточнение? Вроде бы в п.6 я раскрываю этот момент, или вы имеете в виду, что можно в PyCharm сразу создать проект Django?
Если указывать настройку django в pycharm, то вот хороший пример того, что можно сделать https://www.jetbrains.com/help/pycharm/django-support7.html
Все круто, но не стоит забывать о том, за что мы любим Django. Это не только DjangoORM(хотя, конечно это в большей степени), миграции и механизм конфигов из под капота и т.д. Мы любим ее еще и за то, а многие ровно за это же ее нелюбят, что она рекомендует свою, стандартную структуру проекта.
Возмем тот же Flask, что не проект, то униакльная структура и хорошо если она логична. Вхождение нового разработчика в проект на Flask это всегда вызов. В Django же все по другому. Если разработчик читал документацию Django и структура проекта этой документации соответствует, то он уже на старте много чего знает и сможет в кратчайшие сроки ориентироваться по кодовой базе. А для некоторых информация о том, что проект на Django, формирует ожидание к структуре и в целом кодовой базе. И разработчик будет испытывать негатив, когда его ожидания не будут оправдываться.
Если выбрали Django, то хорошей стратегией на перспективу будет, как можно строже, придерживаться документации. Каждое отклонение удорожает поддержку и вход новых разработчиков. Поэтому, небольшая рекомендация для тех кто только входит в индустрию и тех, кто еще не строит планов по развитию и ведению кодовой базы на дистанции, прежде чем вносить изменение в структуру проекта, отличное от рекомендаций Django, посоветуйтесть с тех.лидом или тем, кто эту роль выполняет у вас в команде/компании.
"Хорошей стратегией на перспективу" >> для вашего нанимателя. А если разработчик работает ИП, то он, скорее, заинтересован, чтобы с правками опять обратились к нему. Так что возможны варианты.
В целом, я с Вами согласен. Возможны варианты. Но тут уже виднеется территория противостояния двух философий или отношений к своей профессии. На одной стороне люди, которые "лишь бы платили", а с другой полноправные участники бизнеса. А разработчик это полноправный участник бизнеса (по Мартину). И если я ответственный участник этих процессов, то стратегию я строю для себя, а не для нанимателя. Нанемателю, т.е. бизнесу, в подовляющем большенстве случаев(возможно ошибаюсь), глубоко плевать на структуру и архитектуру проекта, ему важно value которое приносит продукт.
Поэтому, да, варианты возможны, но нужно отдавать себе отчет на чьей ты стороне)
О! " А разработчик это полноправный участник бизнеса (по Мартину)." Ссылку не дадите? Я не знаком с источником...
Здравый же смысл подсказывает, что в большинстве случаев разработчик-фрилансер далек от "полноправного участника бизнеса". Даже в большинстве крупных корпораций есть специальные люди, которые следят за тем, чтобы bus factor не обрушил проект, и сохранялась взаимозаменяемость людей и преемственность архитектуры. Там тоже "полноправность" для большинства условна. А дословное следование документации просто прописано в инструкции. Для индивидуалов следование стандартам целиком лежит в поле ответственности заказчика. И, если честно, мне не очень понятно, что значит "полноценный участник бизнеса" для ИП.
"Чистая архитектура" стр. 39. "Битва за архитектуру".
Не сомневаюсь, что вы умеете читать между строк
ЗЫ:
Добавлю для читателей, чтобы не пришлось качать книжку
Эффективные команды разработчиков часто выходят победителями в этой борьбе. Они открыто и на равных вступают в конфликт со всеми другими заинтересованными сторонами. Помните: как разработчик программного обеспечения вы тоже являетесь заинтересованной стороной. У вас есть свой интерес в программном обеспечении, который вы должны защищать. Это часть вашей роли и ваших обязанностей. И одна из основных причин, почему вас наняли.
Uncle Bob это про AGILE, а не про реальную жизнь
Даже так? Все встало на свои места. Спасибо за дискуссию!
Не смотря на то что Вы закрыли дискуссию, я, подумав, решил уточнить, чтобы не было недосказанности:
Я считаю отход от документации антипатерном. Но видел агентства, которые практиковали его. Потому что выгодно и удобно.
AGILE работает в реальной жизни, тогда и только тогда когда выполняется 100500 условий. Перечисленных, например, в статье Agile без идеализма. И, главное, Agile снизу не строится. И значит утверждение " разработчик - полноправные участники бизнеса" подтверждается авторитетом Мартина, тогда и только тогда, когда отношения выстроены уже по Agile. А в реале это встречается, право, не так часто, как бы хотелось.
Действительно этот холивар в этой статье про Django явно лишний. Поэтому Вам тоже "Спасибо за дискуссию"
что в большинстве случаев разработчик-фрилансер далек от "полноправного участника бизнеса"
противостояние происходит на разных уровнях, но поле боя одно.
Даже в большинстве крупных корпораций есть специальные люди, которые следят за тем, чтобы bus factor не обрушил проект, и сохранялась взаимозаменяемость людей и преемственность архитектуры. Там тоже "полноправность" для большинства условна
понятно что есть некоторая иерерхия разработчиков в крупных компаниях. Я же, во-первых, имею ввиду некий собирательный образ разработчика, во-вторых, это зависит от того, как разработчик себя позиционирует в рамках своей команды и компании в целом. Разработчик, который на стороне тех кто про "лишь бы платили" вероятно так и не выростет до того, кто, все же, принимает решения. И, вероятно, уйдет из компании фрилансить. А тех фрилансеров, которые на другой стороне, с высокой долей вероятности заберут в штат.
Архитектура универсального проекта Django