Вообще, как мне кажется, оператор new является признаком явного императивного подхода. Оператора new вообще не должно быть в ядре моделирования для определения объектов – объекты задаются декларативно. Существование объекта декларируется, а фактический способ создания будет уточняться позже. Более того, инстанцироваться может не сам объект, а прокси к удалённому объекту.
Для этого используются dependency injection containers
Так это не "понятнворили" а "недонатворили". Это раз. Во-вторых, там есть инкапусуляция, в-третьих, это динамический язык со своими динамическими традициями (сравнивать с JS, ruby, lisp)
Первые начитываются книжек по паттернам и начинают пихать их куда ни попадя
Я думаю, люди, не испытывающие потребности называть других именно дураками, сказали бы, что это нормальный этап обучение чему бы то ни было — попробовать его в разных условиях.
Но справедливости ради, разве не недоучки — люди с незаконченным высшим, придумали т.н. паттерны ооп?
Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming – specifically pattern languages – and presented their results at the OOPSLA conference that year.[6][7] In the following years, Beck, Cunningham and others followed up on this work.
Beck attended the University of Oregon between 1979 and 1987, receiving B.S. and M.S. degrees in computer and information science.[3]
Cunningham was born in Michigan City, Indiana.[6] He received his Bachelor's degree in interdisciplinary engineering (electrical engineering and computer science) and his master's degree in computer science from Purdue University, graduating in 1978.[7]
От которых число дураков выросло даже експоненциально в нашей отрасли.
Мне кажется, не дураки от паттернов, а просто дураки применяют паттерны по-дурацки :)
Мне кажется у автора мысль движется в ту сторону, что и у всяких беков и фаулеров, когда говорят про agile maturity или engineering fluency, только он говорит в самобытно-эмоциональном стиле, что забавно в сочетании с понятиями "эмоциональный бред" и "эмоциональные листочки на стенках", которые он сам и применяет :)
В этом все и дело. Agile как концепция и Scrum как набор конкретных методик и практик это разные вещи.
Я бы сказал, что тут можно достаточно сильно варьировать методику в зависимости от того, как определять "Продукт" и "Команду" в конкретном случае. Грубо говоря, подставить в соответсвующие параметры адаптеры для каких-то вещей вне данного процесса.
Гибкость состоит не в том, чтобы вгонять коллектив в рамки, которые требует гибкая методика, а возможности выстраивать процесс с учетом специфики проекта и наиболее эффективного использования имеющихся ресурсов.
Я где-то встречал мысль, что чтобы узнать что-то новое надо постараться внедрить идею буквально ища смысл в ее деталях — тогда это заставит взглянуть на процесс с другой стороны и узнать что-то новое. Иначе просто человек отвергнет что-то значимое исходя из своих текущих стереотипов и останется при своих
Вопрос «может в принципе или не может» это уже давно не самый важный вопрос. В принципе этим может заниматься кто угодно, но специально подготовленные люди справляются лучше.
Тут возникает вопрос, окупает ли это что-то лучшее затраты на коммуникацию со специально подготовленным человеком. Например, почему мы не используем специальных завязывальщиков шнурков?
В каком-то конкретном случае может окупать, а в каком-то может и нет.
То есть у конкретного лендинга есть столько специфики, что разработчик не может взять рыбу и поменять конкретные места, ему проще как-то описать это техпису, что бы он потом описал это пользователям?
Вообще по моему опыту некоторую документацию писали разработчики, потом техписы доводили ее по стилю. И вообще был некий аджайл внутри команды разработчиков но во вне уже была некоторые процедуры управления зависимостями.
Если посмотреть внимательно на определения, то PO и перечисленные категории пересекающиеся множества — продюсер может быть как PO так и не PO, и PO может быть как продюсером так и нет. PO специфический термин в рамках именно скрама.
Я совершенно не знаю, требуют или не требуют отдельной роли функция "управление беклогом". Мне хотелось бы узнать, кто такой продюсер — нет ли у вас ссылки на описание такой же степени однозначности и понятности как в скрам гайде?
А факт остаётся тем же: взяли уже имеющуюся роль и обозвали по-другому
Это ваше суждние, я не факт. И судя по тому, что вы понимали под PO в первой версии, я ему не доверяю :)
В крайнем случае — взяли часть функций уже имеющейся роли и выделили в отдельную роль, дав ей иное название.
Мне кажется, что в формулировке процессов это одна из важных частей — выделить из уже имющегося существенное и потребовать его :). Это и есть новизна. А что вы ожидали — небывалого мегапрорыва от введения ровно одной роли?
Так какое старое название для PO я так и не понял. Продюсер-в-игровой-студии? Но даже если такой продюсер и был PO сам термин не эквивалентен. Он, возможно, более общий. Это как сказать, "зачем вы ввели понятие "хордовые", если собаки и рыбы нам давно известны.
И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.
Я не вебдев и не очень понимаю, зачем столько для лендинга. Например, зачем Tech Writer. Да, в скраме пропагандируют совмещение в рамках команды, T-shaped и М-shaped specialists.
Язык помогает — есть неймспейсы, слово internal и так далее
Для этого используются dependency injection containers
Именно в доменную модель, а не в Presentation|View Model?
Зачит ли это что им плевать, есть функционал или нет?
То есть им в любой точке времени T плевать, есть функционал или нет?
Ее принципиально нельзя использовать не по назначению :)?
Так это не "понятнворили" а "недонатворили". Это раз. Во-вторых, там есть инкапусуляция, в-третьих, это динамический язык со своими динамическими традициями (сравнивать с JS, ruby, lisp)
Я думаю, люди, не испытывающие потребности называть других именно дураками, сказали бы, что это нормальный этап обучение чему бы то ни было — попробовать его в разных условиях.
Думаю у Питона достаточно строгий дизайн или что вы имеете ввиду вообще?
Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming – specifically pattern languages – and presented their results at the OOPSLA conference that year.[6][7] In the following years, Beck, Cunningham and others followed up on this work.
Beck attended the University of Oregon between 1979 and 1987, receiving B.S. and M.S. degrees in computer and information science.[3]
Cunningham was born in Michigan City, Indiana.[6] He received his Bachelor's degree in interdisciplinary engineering (electrical engineering and computer science) and his master's degree in computer science from Purdue University, graduating in 1978.[7]
Мне кажется, не дураки от паттернов, а просто дураки применяют паттерны по-дурацки :)
Мне кажется у автора мысль движется в ту сторону, что и у всяких беков и фаулеров, когда говорят про agile maturity или engineering fluency, только он говорит в самобытно-эмоциональном стиле, что забавно в сочетании с понятиями "эмоциональный бред" и "эмоциональные листочки на стенках", которые он сам и применяет :)
Я бы сказал, что тут можно достаточно сильно варьировать методику в зависимости от того, как определять "Продукт" и "Команду" в конкретном случае. Грубо говоря, подставить в соответсвующие параметры адаптеры для каких-то вещей вне данного процесса.
Я где-то встречал мысль, что чтобы узнать что-то новое надо постараться внедрить идею буквально ища смысл в ее деталях — тогда это заставит взглянуть на процесс с другой стороны и узнать что-то новое. Иначе просто человек отвергнет что-то значимое исходя из своих текущих стереотипов и останется при своих
Тут возникает вопрос, окупает ли это что-то лучшее затраты на коммуникацию со специально подготовленным человеком. Например, почему мы не используем специальных завязывальщиков шнурков?
В каком-то конкретном случае может окупать, а в каком-то может и нет.
То есть у конкретного лендинга есть столько специфики, что разработчик не может взять рыбу и поменять конкретные места, ему проще как-то описать это техпису, что бы он потом описал это пользователям?
Вообще по моему опыту некоторую документацию писали разработчики, потом техписы доводили ее по стилю. И вообще был некий аджайл внутри команды разработчиков но во вне уже была некоторые процедуры управления зависимостями.
Если посмотреть внимательно на определения, то PO и перечисленные категории пересекающиеся множества — продюсер может быть как PO так и не PO, и PO может быть как продюсером так и нет. PO специфический термин в рамках именно скрама.
Вот для примера лендига — там столько специфики, что нужен специальный Tech Writer чтобы ее написать? Разработчик не может?
Я совершенно не знаю, требуют или не требуют отдельной роли функция "управление беклогом". Мне хотелось бы узнать, кто такой продюсер — нет ли у вас ссылки на описание такой же степени однозначности и понятности как в скрам гайде?
Это ваше суждние, я не факт. И судя по тому, что вы понимали под PO в первой версии, я ему не доверяю :)
Мне кажется, что в формулировке процессов это одна из важных частей — выделить из уже имющегося существенное и потребовать его :). Это и есть новизна. А что вы ожидали — небывалого мегапрорыва от введения ровно одной роли?
Так какое старое название для PO я так и не понял. Продюсер-в-игровой-студии? Но даже если такой продюсер и был PO сам термин не эквивалентен. Он, возможно, более общий. Это как сказать, "зачем вы ввели понятие "хордовые", если собаки и рыбы нам давно известны.
И я сомневаюсь, что продюсер-в-игровой-студии является PO если там не введен скрам.
В скраме у PO нет таких обязанностей. Он отвечает за беклог, но не обязан сам делать все это.
Я не вебдев и не очень понимаю, зачем столько для лендинга. Например, зачем Tech Writer. Да, в скраме пропагандируют совмещение в рамках команды, T-shaped и М-shaped specialists.