вот у меня сейчас замечательная ситуация:
проект идет один год
пишут его два программера — гуру супермозга, кучу проектов сделали
вышел один релиз который показал что проект сырой:
— все время новые баги лезут.
— локализовывать их сложно
— окружение быстро меняется и повторить ошибку по логам практически невозможно
сейлзы отказываются его дальше продавать.
теперь еще и мой супермоск добавили к проекту чтобы помог баги пофиксить
причем задача именно баги фиксить а не фреймворк там оптимизировать или инструмент для тестирования улучшить.
вот не знаю что лучше — тупо баги фиксить или пойти начальника программировать…
а если оценка задачи сама по себе ресурсоемкая штука и может потянуть на отдельный проект а контракт уже за вас подписали?
да в нем еще и стоимость и объем работ и этапы с датами проставили.
сколько раз наблюдал — когда приходит время расплаты начальники предпочитают забыть о теории и просят попедалить основательно, забить на процессы, добавить новичков в последний день проекта не взирая ни на каких Макконнелов и же с ними.
так что не расстраивайтесь, чаще всего никто за вас думать не будет.
а даже если и так, считайте это случайным бонусом.
да и теперь вы точно знаете что нужно делать в такой ситуации, а так бы жили себе в аквариуме.
стресс заставляет быстрее двигаться, кто быстрее двигается тот больше знает и умеет.
а если надо выбирать из двух задач я выберу ту что посложнее, пусть может там и жопа встретится.
зато потом будет что вспомнить
к сожалению, когда идешь по улице не вседа смотришь под ноги.
особенно на ярко освещенных центральных городских улицах.
но иногда и там собак выгуливают и лошади бродют.
а еще бывает что и небо чистое и прогнозы хорошие, а домой мокрым возвращаешься.
вот как потом в рабочее состояние приходить, вот вопрос интересный.
потому как восстанавливаться после таких неприятностей приходится.
ну так и почему бы не делать скрам/стендап/утреннее собрание как раз в 11:30.
а может попробовать еще какой-то вариант?
есть много проектов в которых команда распределенная и им как-то удается эффективно обмениваться информацией.
ведь бардак — это совсем не то что все делают работу когда им удобно.
бардак — это когда нет согласованности и ожидаемого результата.
затягивая гайки вы лишаете себя радужного чувства свободы.
оно конечно будет работать и даже хорошо, но не будет так привлекательно для людей.
в управлении есть такая штука — что контролируем, то и получаем.
введением обязательных часов на рабочем месте вы решаете вопрос согласования работ и обмена информацией внутри команды.
перед тем как принимать такие жесткие меры как ограничение свободы своих сотрудников попробуйте поставить задачу команде решить эту проблему.
возможно самое удобное время для этого — ретроспектива.
контролируйте принятые договоренности и отслеживайте результат чтобы дать обратную связь о том как все идет.
а лучше чтобы ребята сами контролировали свои обязательства.
это как-то вроде по взрослому и профессионально — отвечать за свои слова.
ну и уж если все-таки это не удалось, принимайте личное решение (но тогда это уже точно не agile :)
кстати, может получитья и так что команда сама решит ограничить себя обязательными часами.
agile он не о практиках, он о качественном продукте и эффективном взаимодействии.
поэтому если у вас не выходят стендапы или не работают итерации, может вам они и не нужны.
и цели которые достигаются этими практиками нужно решать как-то по другому.
Можно и WCF, но если нужен только REST, то все прибамбасы с WCF атрибутами, интерфейсами и его настройкой будут дополнительной нагрузкой.
А так — минимальные изменения в окружении и REST сервис для нужд сайта готов.
За 15 минут объяснил подход всем участникам команды.
С WCF такой трюк боюсь что не прошел бы.
А команда у нас еще и распределенная.
Да, согласен, нативная авторизация лучше, но там пока тоже не все так просто.
Поэтому при выборе подхода надо хорошенько подумать.
Кстати, очень интересная темя для статьи.
API используется только самим сайтом, авторизируемся используя стандартные механизмы ASP.NET — страничка с Form аутентификацией.
В конечном счете в ASP.NET все должно сводиться к стандартным механизмам — сессия, IPrincipal и декларативная или императивная модель безопасности кода. msdn.microsoft.com/en-us/library/a95batfc.aspx
и я бы хотел эту логику вынести из code-behind и структурировать ее так чтобы можно было части этой страницы использовать повторно.
предложите Ваше решение пожалуйста.
я хочу отделить логику страницы от событий и биндинга данных.
хочу видеть в codebehind только DataBind и обработку событий.
логику страницы хочу видеть отдельно.
под логикой страницы я понимаю:
— загрузку словарей
— подготовку данных для вывода пользователю
— хранение используемых моделей
— вызовы методов бизнес логики
— логика настройки отображения
например: если эта модель заполнена, то подгрузить зависимую
— взаимодействие между составными частями страницы
например: заполнен фильтр -> нажата кнопка поиска -> передаем данные в блок получения результата
Для меня это насущная проблема, как и для Eltaron и elw00d
Если не использовать подобный описанному подход, то как?
Если Вы не видите в этом разделении смысла, можно не отвечать.
почему же, я могу себе даже представить довольно сложную страницу которая объединяет в себе несколько бизнес сущностей и эта логика специфична для страницы. т.е. не должна быть в доменной области приложения.
и я бы хотел эту логику вынести из code-behind и структурировать ее так чтобы можно было части этой страницы использовать повторно.
предложите Ваше решение пожалуйста.
что касаемо инверсии управления между вьюшкой и презентером — я пробовал строить такую схему, получается сложнее для понимания и поддержки.
надо сравнить затраты на изменение презентера и вьюшек под него заточенных с затратами на реализацию и поддержку независимых вьюшек. в моем случае дешевле было первое.
посмотрю Ваш пример, возможно я до чего-то не догадался.
возможно мы несколько по разному понимаем назначение презентера. в моей схеме он выполняет всю работу по подготовке данных для вьюшки, также как и обработку данных поступающих от вьюшки.
тут есть ошибка не верно выставлять модель напрямую, правильно будет использовать для этого свойства презентера.
основная задача этого подхода отделить события и биндинги от логики страницы — избежать мешанины из этого всего.
потому как часто хватает сложностей связанных с жизненным циклом страницы, а если туда примешивается стейт сохраненный в контролах и ViewState, то становится совсем тяжко.
на счет переписать все я высказал свои аргументы выше. есть еще варианты?
опыт есть - двойное решение существует уже два года. переписываем по мере необходимости.
как Вы знаете WebForms — инструмент достаточно гибкий и позволяет написать одно и тоже многими способами. после внедрения этого шаблона программисты стали писать код единообразно. он прост и доступен даже новичку, ему легко следовать, код легче проверять.
на большом количестве проектов в течении, наверное, лет 15 возникало желание отделить логику страницы от событий и биндингов. применялись различные подходы, но все они, в итоге, сводятся к подобным решениям.
Вы сказали что можно вынести логику страницы не используя MVC.
Приведите пожалуйста пример.
Правильно ли я понимаю - Вы считаете что лучше переписать все,
чем позволить временно существовать двум шаблонам?
К сожалению чаще всего получить одобрение бизнеса на такое масштабное изменение
достаточно проблематично.
Да и достаточно рискованно. Потому как скорее всего попросят дать оценку,
а оценить такое масштабное изменение во первых сложно,
во вторых цифра получится большая и ее придется отстаивать,
а в третьих велика вероятность ошибки и за нее придется отвечать.
Я понимаю что есть лучшие практики, и хорошо представляю себе что такое рефакторинг.
В больших системах иногда приходится мириться с временным существованием двух решений.
Как ни прискорбно это сознавать.
И конечно-же от таких временных ситуаций надо избавляться как можно быстрее.
Если сравнить MVC и MVP - разница между ними только в хранении состояния. MVP частный случай MVC согласно их описанию. Сравнить можно например вот здесь и здесь.
По этому я предпочел такое название. Вы можете сами выбрать MVC или MVP.
При этом представленный код будет работать в обоих случаях.
Для реализации MVP возможно придется добавить сохранение состояния между постбэками.
Я бы на Вашем месте попробовал, очень удобно. Дело в том что оба способа имеют достоинства:
CodeRush — быстро, наглядно и без модальных окон скрывающих код
ReShaprer — больше возможностей по настройке (например сразу указать что метод приватный)
Было бы здорово иметь обе возможности в одном инструменте.
проект идет один год
пишут его два программера — гуру супермозга, кучу проектов сделали
вышел один релиз который показал что проект сырой:
— все время новые баги лезут.
— локализовывать их сложно
— окружение быстро меняется и повторить ошибку по логам практически невозможно
сейлзы отказываются его дальше продавать.
теперь еще и мой супермоск добавили к проекту чтобы помог баги пофиксить
причем задача именно баги фиксить а не фреймворк там оптимизировать или инструмент для тестирования улучшить.
вот не знаю что лучше — тупо баги фиксить или пойти начальника программировать…
да в нем еще и стоимость и объем работ и этапы с датами проставили.
так что не расстраивайтесь, чаще всего никто за вас думать не будет.
а даже если и так, считайте это случайным бонусом.
да и теперь вы точно знаете что нужно делать в такой ситуации, а так бы жили себе в аквариуме.
стресс заставляет быстрее двигаться, кто быстрее двигается тот больше знает и умеет.
а если надо выбирать из двух задач я выберу ту что посложнее, пусть может там и жопа встретится.
зато потом будет что вспомнить
особенно на ярко освещенных центральных городских улицах.
но иногда и там собак выгуливают и лошади бродют.
а еще бывает что и небо чистое и прогнозы хорошие, а домой мокрым возвращаешься.
вот как потом в рабочее состояние приходить, вот вопрос интересный.
потому как восстанавливаться после таких неприятностей приходится.
а может попробовать еще какой-то вариант?
есть много проектов в которых команда распределенная и им как-то удается эффективно обмениваться информацией.
ведь бардак — это совсем не то что все делают работу когда им удобно.
бардак — это когда нет согласованности и ожидаемого результата.
затягивая гайки вы лишаете себя радужного чувства свободы.
оно конечно будет работать и даже хорошо, но не будет так привлекательно для людей.
в управлении есть такая штука — что контролируем, то и получаем.
введением обязательных часов на рабочем месте вы решаете вопрос согласования работ и обмена информацией внутри команды.
перед тем как принимать такие жесткие меры как ограничение свободы своих сотрудников попробуйте поставить задачу команде решить эту проблему.
возможно самое удобное время для этого — ретроспектива.
контролируйте принятые договоренности и отслеживайте результат чтобы дать обратную связь о том как все идет.
а лучше чтобы ребята сами контролировали свои обязательства.
это как-то вроде по взрослому и профессионально — отвечать за свои слова.
ну и уж если все-таки это не удалось, принимайте личное решение (но тогда это уже точно не agile :)
кстати, может получитья и так что команда сама решит ограничить себя обязательными часами.
agile он не о практиках, он о качественном продукте и эффективном взаимодействии.
поэтому если у вас не выходят стендапы или не работают итерации, может вам они и не нужны.
и цели которые достигаются этими практиками нужно решать как-то по другому.
А так — минимальные изменения в окружении и REST сервис для нужд сайта готов.
За 15 минут объяснил подход всем участникам команды.
С WCF такой трюк боюсь что не прошел бы.
А команда у нас еще и распределенная.
Поэтому при выборе подхода надо хорошенько подумать.
Кстати, очень интересная темя для статьи.
В конечном счете в ASP.NET все должно сводиться к стандартным механизмам — сессия, IPrincipal и декларативная или императивная модель безопасности кода.
msdn.microsoft.com/en-us/library/a95batfc.aspx
хочу видеть в codebehind только DataBind и обработку событий.
логику страницы хочу видеть отдельно.
под логикой страницы я понимаю:
— загрузку словарей
— подготовку данных для вывода пользователю
— хранение используемых моделей
— вызовы методов бизнес логики
— логика настройки отображения
например: если эта модель заполнена, то подгрузить зависимую
— взаимодействие между составными частями страницы
например: заполнен фильтр -> нажата кнопка поиска -> передаем данные в блок получения результата
Для меня это насущная проблема, как и для Eltaron и elw00d
Если не использовать подобный описанному подход, то как?
Если Вы не видите в этом разделении смысла, можно не отвечать.
и я бы хотел эту логику вынести из code-behind и структурировать ее так чтобы можно было части этой страницы использовать повторно.
предложите Ваше решение пожалуйста.
что касаемо инверсии управления между вьюшкой и презентером — я пробовал строить такую схему, получается сложнее для понимания и поддержки.
надо сравнить затраты на изменение презентера и вьюшек под него заточенных с затратами на реализацию и поддержку независимых вьюшек. в моем случае дешевле было первое.
посмотрю Ваш пример, возможно я до чего-то не догадался.
возможно мы несколько по разному понимаем назначение презентера. в моей схеме он выполняет всю работу по подготовке данных для вьюшки, также как и обработку данных поступающих от вьюшки.
тут есть ошибка не верно выставлять модель напрямую, правильно будет использовать для этого свойства презентера.
основная задача этого подхода отделить события и биндинги от логики страницы — избежать мешанины из этого всего.
потому как часто хватает сложностей связанных с жизненным циклом страницы, а если туда примешивается стейт сохраненный в контролах и ViewState, то становится совсем тяжко.
опыт есть - двойное решение существует уже два года. переписываем по мере необходимости.
как Вы знаете WebForms — инструмент достаточно гибкий и позволяет написать одно и тоже многими способами. после внедрения этого шаблона программисты стали писать код единообразно. он прост и доступен даже новичку, ему легко следовать, код легче проверять.
на большом количестве проектов в течении, наверное, лет 15 возникало желание отделить логику страницы от событий и биндингов. применялись различные подходы, но все они, в итоге, сводятся к подобным решениям.
Вы сказали что можно вынести логику страницы не используя MVC.
Приведите пожалуйста пример.
А на мой вопрос Вы к сожалению не ответили.
чем позволить временно существовать двум шаблонам?
К сожалению чаще всего получить одобрение бизнеса на такое масштабное изменение
достаточно проблематично.
Да и достаточно рискованно. Потому как скорее всего попросят дать оценку,
а оценить такое масштабное изменение во первых сложно,
во вторых цифра получится большая и ее придется отстаивать,
а в третьих велика вероятность ошибки и за нее придется отвечать.
Я понимаю что есть лучшие практики, и хорошо представляю себе что такое рефакторинг.
В больших системах иногда приходится мириться с временным существованием двух решений.
Как ни прискорбно это сознавать.
И конечно-же от таких временных ситуаций надо избавляться как можно быстрее.
По этому я предпочел такое название. Вы можете сами выбрать MVC или MVP.
При этом представленный код будет работать в обоих случаях.
Для реализации MVP возможно придется добавить сохранение состояния между постбэками.
CodeRush — быстро, наглядно и без модальных окон скрывающих код
ReShaprer — больше возможностей по настройке (например сразу указать что метод приватный)
Было бы здорово иметь обе возможности в одном инструменте.