acerv

Это аспект, реализующий отличие номер 2) про ограничение возможностей доступа к делегату. Danov прав.

Не легче ли в этом случае свое резюме нафигачить, безо всяких моихкругов?:)

Дык а нафига его редактировать, если он в моем круге редактируется?:) типа, и там и там чтобы редактировать можно было?:)

Почему ворд, а не pdf?:)

Картинки там переведены.

В книжке рассмотрены приводимые вами ситуации. Вы бы почитали сначала, а потом умничали.

В общем, я вам объяснять не буду, вы просто не совсем четко понимаете, как это все работает.

Вам следует прочитать вот эту книгу:
scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf

Там всего 100 страниц и все на русском. Не поленитесь, это очень полезно.

Что-то вы усложняете. Какая еще средняя температура по больнице? Есть спринт в днях, есть задачи, есть их оценка в идеальных днях. Устанавливаете фокус-фактор, умножаете и отрезаете те задачи, которые не вмещаются в спринт. Если сделали все задачи — угадали с фокус-фактором, не сделали — значит, фокус фактор был ниже и на следующий спринт его надо скорректировать. Сделали больше — круто, значит, фокус-фактор на следующий спринт можно как-то увеличить.

Здесь квалификация отдельного человека не причем, идет оценка работы всей команды как единого целого.

>Ну, если менеджер — обезьяна, то тут и скрам не поможет.
Именно что поможет. Наша постоянно лезла в разработку, «управляла». Нейтрализовало на 100%.

>Что вы знаете про весь проект с этими данными?
Зависит от срока и размера проекта. Если проект мелкий — средний, то всю картину можно разбить на бизнес-задачи. Если он очень большой (как у нас сейчас, например), то берется некоторый актуальный зазор задач, определяемый на встречах с заказчиком — своего рода «мелкий» проект, без особых четко очерченных границ. В любом случае, я хочу сказать, что «знать» про проект — можно. Составление бэклога с последующей приоретизацией и межкомандным согласованием — это очень важная задача. Блин, да что я вам говорю, про это классики пишут в почти каждой книжке.

>когда надо, а что не успели — отрезать.
Вы знаете, получается что в канбане так — ВДРУГ всем стало ясно, что не успели. Работали работали, и не успели.
Итерация дает обратную связь, позволяет изменять процесс и делать его прозрачным.

>Контроль не хуже, чем в скраме — время выполнения задачи можно сравнивать и задача команды — сокращать это время. Если оно растет — что-то не так.

Вот этого я не понимаю. Спринт закончился — если остались задачи, спринт провалился, устраивается разбор полетов. В канбане задача может провисеть мертвой некоторое время, пока кто-нибудь не спохватится — «ой, что это у нас тут».

>и за временем выполнения одной задачи — из этого он делает выводы, сколько будет выполнено к дедлайну
По-моему, это некорректно. Задачи ведь неравномерны по времени своего исполнения!

>Если оно растет — что-то не так.
В статье писалось, что такого аспекта как замеры времени в процессе не существует:)))

Ладно, хватит придирок. Дело в том, что если сравнивать скрам с канбаном, если вы признаете последний набором методик, а не процессом разработки, некорректно. Если же брать канбан как процесс в том виде, в котором он приведен в статье — то канбан нежизнеспособен в жестких условиях поставки.

Статья поначалу вызывает, восторг, да. Пока думать не начинаешь:) Почитайте комменты оппонентов.

Что вы говорите. Одно из понятий скрама — фокус-фактор, который говорит, как эффективно работает команда и сколько она способна решить задач за квант! Квант здесь — измеримое понятие, т.е. бизнес-людям можно оценить сверху, будут ли реализованы все важные запланированные задачи к сроку поставки, или же нужно сокращать функционал.

В канбане я этого не вижу. Т.е. с первого взгляда — это такая текучка, очень хорошая для постоянного процесса (как непрерывное производство машин, например), но для производства ПО — это как-то оооооочень гибко.

Раз уж решили сравнивать скрам, то я вот что скажу — скрам хорош тем, что он защищает разработчиков от оголтелого произвола менеджеров, или же наоборот, позволяет менеджерам видеть, кто саботажник или просто плохо работает. Это позволяет скорректировать планы и той, и другой стороне.

В канбане этого нет. Что я менеджеру скажу? Я не могу ему сказать, что ему надо убрать пять задач, потому что мы их тупо не успеем сделать — у нас статистикой доказано, что средний фокус фактор, например, 48%. Менеджер от меня ждет оценку (от менеджера этого требуют заказчики) — мне нужно дать ему оценку, пусть даже вы правы насчет тем, кто решает успех проекта.

В канбане нет фокус фактора, весь процесс производства — постоянная текучка, стало быть менеджер будет скакать вокруг меня и орать, чтобы мы работали быстрее, будет пытаться впихнуть больше задач единовременно или увеличить емкость семафора с задачами. Говорить ему при этом «Дядя, че ты ко мне лезешь, неужели ты не знаешь, что от тебя в разработке проекта ничего не зависит?», как было заявлено в статье, это моветон, меня дядя в 24 часа уволит за некомпетентность.

жалко вы весь.нет у себя свернули. что-то у меня вся программерская жизнь рядом с вами :)

Вот тут все Фаулера рекомендуют, а я порекомендую Макконнела :)

Больше всего мне понравилась методика «чистый идеальный мир» — интерфейс — «ад», где он рекомендует определить интерфейс между грязным кодом и чистым идеальным кодом, и потихоньку переносить грязный код за «барьер».

Ну и вообще, цитата из книжки:
Значение слова «рефакторинг» довольно размыто: так называют исправление дефектов, реализацию новой функциональности, модификацию проекта — по сути любое изменение кода. Это неуместно. Целенаправленный процесс изменений может быть эффективной стратегией, обеспечивающей постепенное повышение качества программы при ее сопровождении и предотвращающей всем известную смертельную спираль энтропии ПО, но само по себе изменение достоинств не имеет.

а вы в сикужи работаете?:)

А не знаете, есть порт? Я бы поиграл, как щас помню — мне восемь лет тогда было, когда в нее гонял

Че-то не ушел мой комент. Отвечу еще раз.

1) Строить объекты доменной логики через фабрику-контейнер — практически моветон, месье. Практически — это потому, что оно моветон за исключением случая, когда доменные объекты строятся и наполняются данными через фабрику (как DTO объекты). В этом случае доменные объекты должны иметь публичные интерфейсы и, по всей видимости, должны быть read-only, чтобы можно было защититься от нарушения целостности данных. Еще минус в том, что вы должны явно следить за жизненным циклом создаваемых доменных объектов — удалять их из контейнера и диспоузить по требованию.

2) У меня в примере класс-модуль не инъецируется. Вы путаете с composite application library, там бутстраппер действительно делает инъекцию в модуль, а я всего лишь создаю это класс и вызываю его метод.

Понимаю ваши опасения в плане явного задания свойств-зависимостей. Для этого их нужно делать пабликами, что не всегда верно с точки зрения инкапсуляции. Делайте микросервисную архитектуру, где сервисы или нужные вам объекты инъектятся через конструктор.

Ну и вообще еще совет — используйте контейнер и инъектор как можно реже и только там, где он действительно нужен. Контейнер сам по себе представляет расшаренный ресурс между всеми участками кода, которые с ним работают. Через это нарушается концептуальная целостность и опять же, инкапсуляция, потому что работающие участки кода должны знать, что лежит в контейнере и в каком состоянии он находится, дабы не нарушить свою работоспособность.

Вот бляха, и правда из-за этой галки пост в ленту не попал.

Дело в том, что тебе каждый умник скажет, что да, разделить на слои это круто. Все аналитики тебе будут писать документы, где система будет разделена на слои, но вот о том, каким образом и как разработчики будут эти слои делать — сие неведомо.

Вот мы на своем проекте все в жопу запороли, хотя да, «слои» есть:)

Да вы знаете, здесь дело не в тех терминах, которые вы написали. Здесь дело в практической применимости. Все вышесказанное можно написать без Unity, на ServiceContainer например. Просто, кода будет немножко больше.

Ну и как, понял границы?:)

Устал, сори. Открыл всем. Но теперь уже в ленту не попадет, да?

:))) этапять

>Вопрос такой, в какой системе IoC контейнер может быть полезен при разработке бизнес приложений и на бою?

самое простое решение — архитектура черных ящиков, или «черных слоев», когда при пуске приложения контейнер проходит по всем слоям и регистрирует задаваемые слоями реализации. При этом в сборке реализацию можно скрыть от лишних глаз, т.е. добиться полной инкапсуляции в слое. А это очень круто.

>Чем IoC лучше?
Да ничем он не лучше. Это просто паттерн автоматического определения зависимостей. Он есть в контейнере Unity. Контейнер Юнити описывается автором только потому, что это типа «модное и современное» решение, хотя, судя по ответам на технические вопросы, автор только-только что-то прочитал. IoC можно вообще убрать, написав свой контейнер или взяв простой существующий. System.ComponentModel.Design.ServiceContainer, например (хотя, если вы джавист, то это вам ничего не скажет).

Фишка удобства тестирования не выходит из концепции Unity, а выходит из концепции построения классов, которые удовлетворяют шаблону определения зависимостей. Ты должен или проставить зависимость в конструкторе или в свойстве класса, причем, желательно определив интерфейс. Значит, очень легко настроить mock зависимостей (мок интерфейса очень легко сделать) и протестировать фукнционал класса. Unity контейнер здесь не причем. Он всего лишь вставляет зависимости.

>т.к. WinForms похожа на задницу, между прочим

я прям физически ощущаю вброс:)

да сам асп-нет тут не причем. Это тоже черный ящик. Фишка в низкой связности и (что очень важно), поняности этой низкой связности. Микросервисы, контейнер, блаблабла

Самое зло в жизненном цикле объектов:)

Извините, но вы профан. Вы просто не понимаете того, о чем вы говорите.

Круто%) Мне вот нужен был asp.net mvc, чтобы его можно было сынтегрировать с юнити. А это в свою очередь нужно для черных ящиков, которые пишут разные люди:)

А вот есть прикольная задачка уже не для начинающих — связать ASP.NET MVC с Unity. Требований в целом три:

— обеспечить связывание инфраструктуры контроллеров MVC с инъектором
— модульность
— уникальность контейнера в разрезе сессии

Я бы расписал все, но блин, не успеваю вообще ничего, кроме работы. А вам в рамках обучающих методик будет полезно, имхо.

Сенкс за совет. Зачем статью писали, если все в вебкасте есть?

Сори за брюзжание. Собственно, механизм связывания непонятен. Как постшарп интегрируется в приложение? Что нужно добавить, какие свойства прописать? Как это работает?:) Конечно, можно полезть на сайт и все выяснить, но вы же взялись статью писать, да?:)

Супер — намонстрячили кучу классов-аспектов. А как же все это дело заюзать — нипаняяяяяяяяяяяяяяятна

>> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
Я целиком и полностью согласен с Джоелем Спольским — спец может быть умным и может делать дела. Художник в вашем понимании по определению делать второе не в состоянии (читаем про рутину и баги в топике — обычный процесс любого программиста). Ему важно что-то сделать на модных рюшечках, «предоставить инфраструктуру», как они любят говорить (а дальше с багами вы сами ебитесь).

У меня есть такой художник в команде — собственно, написал доменную модель и слой данных на проекте. Баги искать не хочет, тестировать не хочет — правит что-то только после того, как мордой тыкнешь. Уходить тоже не хочет — обиделся, надулся на всех, сидит сычем в своем закутке, что-то налево делает. В общем, иметь таких художников на проекте — врагу не пожелаешь.

Вообще, с делением на два вида я бы не соглашался. Как минимум любого разработчика можно классифицировать на четыре типа:
1) те, кто умен, и кто может доводить дела до завершения
2) те, кто умен, но не может доводить дела до завершения
3) те, кто не умен, но может доводить дела до завершения
4) те, кто не умен, и не может доводить дела до завершения

Как правило, тип 3 и 4 не проходят испытательный срок. Но тип 3 был очень распространен в докизисные времена, и, судя по всему, раз автору удалось поработать в РБК-Софте, то таджики — как раз про них.

Вообще, как писал один мудрый человек тут:
По симптомам это типичная ошибка, увы. Наверное, чуть ли не каждый разработчик в своей карьере пытается написать какой-нибудь обобщенный управлятор. Из этого ничего не получается, после чего возможны два варианта — либо разработчик ничего не понимает и считает, например, что управлятор был недостаточно обобщенным, либо переходит на светлую сторону и становится хорошим программистом.
А вы сами, судя по всему, что вы тут пишете про баги и рутину, тип 2 — истинный творец или еще не написали свой управлятор:)

И еще совет — МакКоннела прочитайте. Ну честно, прочитайте МакКоннела. Если читали, перечитайте еще раз, более вдумчиво — там с цифрами, с толком, с расстановкой. Как раз про то, что вы тут говорите, но с совершенно другими выводами. Может, поймете что.

видимо, вас могут понимать только телепаты. удачи.

Я было вам начал что-то писать-строчить, да потом подумал, что горбатого могила исправит. Пока сами не докумекаете, что в любом бизнесе, основанном на законах нынешнего государства, первичны прежде всего деньги и все процессы разработки должны быть направлены именно на их получение, с вами бесполезно разговаривать. Можно только читать ваши «смотрите-какой-я-дартаньян» статейки, зычно ржать и показывать на вас пальцем.

В любом случае, желаю вам поумнеть поскорее.

>Работает? Ничего не трогай!
Вы — не айти-художник, вы баклан. Поставьте себя на место менеджера — у него есть проект, есть какое-то количество кода, более менее оттестированного и (что самое главное), работающего.

Тут приходите вы и все ломаете. Все что работало, и все, что уже было оттестировано. Творческая личность, ага.

Три-четыре года назад было -2.50. Сейчас -1.75. Ничего не делал специально:) За компом сижу постоянно.

Соглашусь:) Мы чертим фломиком на бумажке, которая прилеплена магнитом на доске. Гораздо нагляднее:)

Да я про burndown в редмайне и вообще все что с ним связано (с переводом багов в нужные статусы и т.п.). А что у вас за аджайл? Скрам?

Бюрократы :))

Плюсплюсплюсплюс:)

Во-первых, спасибо за статью — еду сегодня на собеседование где будет крутиться затронутая вами тема.
Во-вторых — за нами гоняются клиенты с ссаными тряпками :) Действительно, всто увеличивает время загрузки ворда, но я с вами не согласен, что на такое большое количество времени. Другое дело, что мы это разрабатываем в рамках госпроекта, поэтому тут еще примешивается стыд перед Родиной.
В-третьих, отчего-то имеется острое желание напоить вас пивом в целях потырить знаний и поделиться своими:)

По своей сути это ничем от Чехии не отличается. Шенген есть, живи где хочешь. Другое дело, качество этой жизни и перспективы.