1) Не понял, при чём тут интеграционное тестирование, если повествование о фронтенде. Обычное функциональное тестирование.
2) Статья одного маркетолога для других. Так никакой конкретики и не нашёл. Полстатьи шуток-прибауток, затем поток названий всевозможных инструментов. А применять это как? Показали бы пару примеров НЕ «Hello world». Раз у вас такая крутая команда, могли бы что-нибудь интересное наскрести.
Любую модель разграничения ответственности и ролей можно поставить под сомнение при желании. В том смысле, что для любой методологии всегда найдётся такая команда, которой эта самая методология не подойдёт.
Возможно, по прочтении статьи может сложиться впечатление о безальтернативности матрицы из MSF, но я не намеревался выставить это в таком свете.
Очень эмоционально получилось. Я так понял, что основная мысль здесь была про недооценку важности специалистов техподдержки? Согласен, что многие разработчики недооценивают на этапе проектирования и даже сдачи проекта важности наличия необходимого функционала у операторов, способов восприятия информации простыми пользователями, нет понимания целей, которые преследуют эти самые пользователи.
Но у нас в конторе для этого на этапе сдачи проекта привлекаются спецы и их начальники, ответственные за поддержку клиентов в затрагиваемой области. Они себе не враги и тупо не примут в эксплуатацию недоработанную систему.
Если же где-то это «прокатывает», то при честной и открытой игре они просто не выдержат конкуренции и покинут рынок в качестве самостоятельного игрока.
1) Я не спрашивал кто будет лезть в код, когда программист уволится. Я спрашивал «кто отвечает за код в процессе». Если никто не отвечает, то вам и без DI наворотят, вплоть до "#define TRUE FALSE", и спросить не с кого.
Тогда может возникнуть вопрос, а кто отвечает за тех, кто отвечает за код. Ну был архитектор, ни которого я полагался. И по факту никакого времени у него не было, чтобы реально оценить решение.А вообще не понятно, куда вы уводите дискуссию.
Отвечает за проект РП. Он и виноват в итоге. С себя я вины не снимаю. Но и не вижу противоречий с моим посылом, что при написании программы, было неплохо подумать о тех людях, которые с этим потом будут разибираться. Может, это будет РП, может — программист-стажёр, может — перешедший с других технологий.
2) Ну так Вы и оценивайте сможете ли Вы правильно использовать.Если нет — не нужны статьи про DI, это нефункциональное требование «мне лень в этом разбираться — делаем по-старинке».
Мне кажется, что вы недостаточно хорошо меня знаете, чтобы с такой лёгкостью обвинять меня в лени. Потрудитесь, прощу вас, почитать мою статью ещё раз (в особенности — выводы) и указать, что именно в ней не так сказано
3) Так получается, вы и не РП. Ну или «и жнец и кузнец и на дуде игрец», плохо справляющийся со всем (ни в DI разобраться времени не нашли, и бюджет съеден, и код не отревьюен).
О своих управленческих ошибках я не забыл упомянуть в своей статье. т.ч. на чём вы меня пытаетесь подловить?
Жизнь оказывается несколько сложнее, чем наши идеалистические представления. Полицейские должны ловить преступников, а не копаться в кипах бумаг, чиновники должны исходить с позиций долга перед обществом и ставить интересы социума выше своих личных, врачи должна оказывать квалифицированную помощь бесплатно. Ну должны. Тут вопрос, скорее, философский. Сделать так, чтобы наверняка. Или наваять по науке, а потом сетовать на окружающий мир за непонятый замысел. Мне ближе 1-ый вариант.
Самое забавное, что все (ну ладно, многие) считают, что они пишут для себя. Отсюда и такое как у Вас отношение. Пишите так, чтобы другие сказали, что вы пишете понятно. Исли изначально исходить из таких предпосылок, то и вопросов о читаемости не возникнет.
Вот и про то же. Причём и вполне себе опытные спецы могут так делать. Как я писал в начале статьи, на мой ИМХО, очень мало акцентируется внимания в статьях и книгах, поэтому, когда мозг проектировщика начинает усиленно переваривать ТЗ, на уровне подкорки не возникает желания взглянуть на продукт с точки зрения тех, кто будет его запускать, сопровождать и развивать.
Тут мы вспоминаем про Фаулера и начинаем излагать умные мысли, хотя на самом деле нужно было изначально подумать «а как мы будем изменять», ведь изменение — основа всех учетных систем. И IOC в данном случае как раз путь к решению этой проблемы на уровне архитектуры
Задним умом мы всегда умные. Но, как правило, ближе к запуске проекта ни бюджета, ни времени, ни сил уже нет на то, чтобы переделывать архитектуру.
С точки зрения архитектуры я привел стати авторов, которые утверждали, что IoC вполне может применяться, если, например, может быть несколько стратегий поведения.
Про сферических коней в вакууме я уже писал выше. Когда вы несколько дней подряд посидите по 12-16ч на работе или 3-4 недели без выходных, я посмотрю на вас, с каким энтузиазмом вы будете писать автотесты.
В-вторых, организация тестовой среды в интеграционном проекте часто бывает делом далеко не тривиальным.
Ну, так это проблема не Smart Client, а организации работы в команде. Если у вас только один понимает архитектуру проекта, то это закономерно приведет к таким последствиям, вне зависимости от того, какие инструменты, библиотеки и т.п. вы используете.
Вот именно это и побудило меня на написание этой статьи. Организация не та, организаторы не те, организуемые не те, сфера образования не та, пользователи не такие и т.д.
А можно просто делать просто, чтобы было понятно даже стажёру.
Автомат Калашникова никогда не отличался рекордами в своих стрелковых характеристика, но простота обслуживания, чистки, устойчивости к факторам внешней среды обсуловила всемирную популярность.
Пока у меня был программист, который стоял у истоков создания этого приложения, который понимал всю эту штуку в целом, меня всё устраивало. Проблемы начались, когда я остался один.
На самом деле к DI/IoC надо прийти.
Безусловно. С этим никто не спорит. Но с точки зрения РП, как можно в самом начале оценить, будет разработчик правильно использовать или нет? Я могу поверить, что в этом есть что-то изящное, но простым смертным не всегда доступное. :)
под слабой связанности вы тут именно cohesion или coupling имеете ввиду?
Имею в виду инстанцирование в runtime-е.
Интересно каким образом DI/IoC нарушает инкапсуляцию.
Реализация некой логики выносится не понятно куда, и что именно будет делаться в данном классе — поди разберись в многоуровневом стеке анонимных вызовов.
Может быть проблема как раз таки в низкой квалификации?
Разумеется. Об этом и речь. Других под рукой не было :)
То есть это в целом проблема инстанциирования большого графа зависимостей. нет? Причем тут IoC/DI? Ну и еще есть простой лайфхак. если между кодом который вызывает и кодом который выполняет тонны абстракций, их можно спрятать/выкидывать грепом. Как правило у таких вещей будет вполне себе явный нэймспейс и можно легко фильтровать стэктрейсы
Вполне допускаю, что есть хорошие способы. Вопрос к авторам кода, почему их не использовали. Возможно, на тот момент какая-то книжка была прочитана наполовину. :)
причем тут IoC/DI? Если система спроектирована плохо,
Разумеется. Плохо. С IoC/DI это сделать очень просто. ИМХО.
Я так и не увидел предлагаемой альтернативы. Более того я так и не понял что плохого вы видите в IoC. Есть подозрение что под IoC вы имеете ввиду контейнер зависимостей а не сам принцип.
Наверное, альтернатив может быть много. Тут я не берусь навязывать.
Как читатель, получивший диплом 10 лет назад и ни разу на практике теорию чисел (да и почти всего остального тоже) не применявший, я понял так, что:
1. В стандартных теориях введение исключений при делении на 0 позволяет избавиться от противоречий (и головняка) в свойствах поверх аксиоматики.
2. В данной статье описывается, как предки предложили специальные обозначения для двух типов сложных ситуаций, и в общем никто не запрещает эти случаи ещё раздробить – как обычно говорится в таких случаях, читателю предлагается проделать это самостоятельно [при желании].
Спасибо за DSDM, т.к. нашёл там полезную инфу для своей статьи в периодическом издании)))
Теперь критика.
1. Мне кажется, не стоит умалчивать об управлении проектами в общем. Те же PMBoK, PRINCE/PRINCE2 и прочие вполне подходят и для управления ИТ-проектами. Просто различные RUP, MSF, Agile и т.д. более подробно останавливаются на отдельных специфицеских для ИТ моментах.
2. Гляньте ещё в сторону SWEBOK.
3. Есть у меня товарищ, утверждающий, что PMBoK слизан с наработок в СССР. Мне не удалось пока найти ни подтверждений, ни опровержений этого тезиса. Если бы Вам удалось что-то найти про отечественный опыт – это бы стало дополнительной «изюминкой», которую, кстати, очень любят в наших научных кругах (ИМХО – и правильно делают).
2) Статья одного маркетолога для других. Так никакой конкретики и не нашёл. Полстатьи шуток-прибауток, затем поток названий всевозможных инструментов. А применять это как? Показали бы пару примеров НЕ «Hello world». Раз у вас такая крутая команда, могли бы что-нибудь интересное наскрести.
Возможно, по прочтении статьи может сложиться впечатление о безальтернативности матрицы из MSF, но я не намеревался выставить это в таком свете.
Но у нас в конторе для этого на этапе сдачи проекта привлекаются спецы и их начальники, ответственные за поддержку клиентов в затрагиваемой области. Они себе не враги и тупо не примут в эксплуатацию недоработанную систему.
Если же где-то это «прокатывает», то при честной и открытой игре они просто не выдержат конкуренции и покинут рынок в качестве самостоятельного игрока.
Тогда может возникнуть вопрос, а кто отвечает за тех, кто отвечает за код. Ну был архитектор, ни которого я полагался. И по факту никакого времени у него не было, чтобы реально оценить решение.А вообще не понятно, куда вы уводите дискуссию.
Отвечает за проект РП. Он и виноват в итоге. С себя я вины не снимаю. Но и не вижу противоречий с моим посылом, что при написании программы, было неплохо подумать о тех людях, которые с этим потом будут разибираться. Может, это будет РП, может — программист-стажёр, может — перешедший с других технологий.
Мне кажется, что вы недостаточно хорошо меня знаете, чтобы с такой лёгкостью обвинять меня в лени. Потрудитесь, прощу вас, почитать мою статью ещё раз (в особенности — выводы) и указать, что именно в ней не так сказано
О своих управленческих ошибках я не забыл упомянуть в своей статье. т.ч. на чём вы меня пытаетесь подловить?
Жизнь оказывается несколько сложнее, чем наши идеалистические представления. Полицейские должны ловить преступников, а не копаться в кипах бумаг, чиновники должны исходить с позиций долга перед обществом и ставить интересы социума выше своих личных, врачи должна оказывать квалифицированную помощь бесплатно. Ну должны. Тут вопрос, скорее, философский. Сделать так, чтобы наверняка. Или наваять по науке, а потом сетовать на окружающий мир за непонятый замысел. Мне ближе 1-ый вариант.
Вот и про то же. Причём и вполне себе опытные спецы могут так делать. Как я писал в начале статьи, на мой ИМХО, очень мало акцентируется внимания в статьях и книгах, поэтому, когда мозг проектировщика начинает усиленно переваривать ТЗ, на уровне подкорки не возникает желания взглянуть на продукт с точки зрения тех, кто будет его запускать, сопровождать и развивать.
Задним умом мы всегда умные. Но, как правило, ближе к запуске проекта ни бюджета, ни времени, ни сил уже нет на то, чтобы переделывать архитектуру.
С точки зрения архитектуры я привел стати авторов, которые утверждали, что IoC вполне может применяться, если, например, может быть несколько стратегий поведения.
В-вторых, организация тестовой среды в интеграционном проекте часто бывает делом далеко не тривиальным.
Если старый бюджет съеден, а новый будет только после запуска, то запускать придётся самому.
Вот именно это и побудило меня на написание этой статьи. Организация не та, организаторы не те, организуемые не те, сфера образования не та, пользователи не такие и т.д.
А можно просто делать просто, чтобы было понятно даже стажёру.
Автомат Калашникова никогда не отличался рекордами в своих стрелковых характеристика, но простота обслуживания, чистки, устойчивости к факторам внешней среды обсуловила всемирную популярность.
Пока у меня был программист, который стоял у истоков создания этого приложения, который понимал всю эту штуку в целом, меня всё устраивало. Проблемы начались, когда я остался один.
Безусловно. С этим никто не спорит. Но с точки зрения РП, как можно в самом начале оценить, будет разработчик правильно использовать или нет? Я могу поверить, что в этом есть что-то изящное, но простым смертным не всегда доступное. :)
Имею в виду инстанцирование в runtime-е.
Реализация некой логики выносится не понятно куда, и что именно будет делаться в данном классе — поди разберись в многоуровневом стеке анонимных вызовов.
Разумеется. Об этом и речь. Других под рукой не было :)
Вполне допускаю, что есть хорошие способы. Вопрос к авторам кода, почему их не использовали. Возможно, на тот момент какая-то книжка была прочитана наполовину. :)
Разумеется. Плохо. С IoC/DI это сделать очень просто. ИМХО.
Наверное, альтернатив может быть много. Тут я не берусь навязывать.
Вот это поворт :)
В научных статьях нужно указывать ключевые слова. Может, и здесь подойдёт? "Ключевые слова", "список/перечень ключевых слов".
Или это не тренд?
1. В стандартных теориях введение исключений при делении на 0 позволяет избавиться от противоречий (и головняка) в свойствах поверх аксиоматики.
2. В данной статье описывается, как предки предложили специальные обозначения для двух типов сложных ситуаций, и в общем никто не запрещает эти случаи ещё раздробить – как обычно говорится в таких случаях, читателю предлагается проделать это самостоятельно [при желании].
Возможно, был в СССР некий отраслевой стандарт или внутриведомственная инструкция.
Для примера (к теме не относится). Наткнулся в своё время на ОСТ 4.071.030.
Теперь критика.
1. Мне кажется, не стоит умалчивать об управлении проектами в общем. Те же PMBoK, PRINCE/PRINCE2 и прочие вполне подходят и для управления ИТ-проектами. Просто различные RUP, MSF, Agile и т.д. более подробно останавливаются на отдельных специфицеских для ИТ моментах.
2. Гляньте ещё в сторону SWEBOK.
3. Есть у меня товарищ, утверждающий, что PMBoK слизан с наработок в СССР. Мне не удалось пока найти ни подтверждений, ни опровержений этого тезиса. Если бы Вам удалось что-то найти про отечественный опыт – это бы стало дополнительной «изюминкой», которую, кстати, очень любят в наших научных кругах (ИМХО – и правильно делают).