Во-первых, в статье я, к сожалению, не заметил указания, что эта система должна предоставляться по желанию.
Во-вторых, лично я выбрал бы усложнение. Частично я с вами согласен. Но лишь частично.
В-третьих, с такой системой (если убрать незамеченное мной "по желанию") за других решаете как раз вы.
И последнее. Даже среди грамотно подкованных людей существует один недостаток, выражающийся в банальной фразе: "если это сложно и необязательно, то использоваться не будет".
Поэтому таких, кто реально (не в голосовании, а на практике) выберет такую сложную систему, а после некоторого времени ее использования с нее не уйдет, будет минимум. И именно поэтому банки не будут это делать, как их не заставляй.
Работать ради 0.1% рынка (цифру взял для из головы для красного слова, но не думаю, что в реале наберется хотя бы 5-10%) никто не станет. Особенно в такой неповоротливой сфере как банки.
P.S. однако мне понравился вот этот комментарий:
В США вопрос решается проще: если клиент заявил о мошенничестве, банк обязан возместить всё и сразу. А потом уже самостоятельно работать с правоохранителям, ловить мошенников и т.п. Это установлено на законодательном уровне.И банки со-овсем по другому относятся к вопросу.
Вот это похоже на один из реальных способов простимулировать банки сделать хоть что-то. И именно так на них и стоит воздействовать.
Чем больше ключей и чем их сложность выше, тем сложнее пользователю их запомнить. Чем сложнее пользователю запомнить, тем выше вероятность, что он попытается облегчить себе жизни: записать на бумажку, сохранить в телефоне и так далее.
Поэтому можно придумать сколь угодно независимых ключей для доступа, но вся эта система с треском разобьется о бабушку, которая не сможет запомнить пароль сложнее, чем имя внучки + дата рождения.
К решению проблем безопасности нужно подходить с двух сторон: со стороны профессиональной (те самые варианты ключей и их независимость) и со стороны простого пользователя. А сделать простой, но безопасный ключ - весьма нетривиальная задача.
А с вашим десятком независимых ключей, выбор которых зависит от дня недели, ретроградного меркурия и луны в козероге, от услуг таких банков пользователи начнут уходить ибо "сложно, ничего не понятно".
А зачем расширять? Да, другая логика, возможно, затронута. Но тестировщик не знает, что было или могло быть затронуто.
Именно поэтому ему стоит сообщить о том, что ты задел другую логику, и на нее тоже стоит взглянуть.
Хорошо, если есть автотесты, делающие регресс основной функциональности. Если не при каждом билде, то хотя бы регулярно.
Это да, хорошо, но автотесты - не панацея. Вы могли изменить логику таким образом, что ранее невозможный кейс стал актуальным. На него не будет автотестов.
На мой взгляд, она должна выявляться не на этом этапе. Либо раньше, на этапе PR, юнит-тестов, либо позже, на регрессе релиза
Это все хорошо опять же для ранее существовавших кейсов. Если вы изменили критичную логику и создали "новый" кейс для "старой" логики, то никто, кроме вас этого не знает.
Юнит тесты вы сами поправите в соответствие с измененной логикой (хорошие тесты и так падают при изменении логики). Если это выявится на уровне PR, то хорошо. Но дальше, если никто не знает, то QA- инженер не протестирует и регресс тоже особо не выявит (некто ж не знает, что регресс надо расширить на ранее невозможный кейс). Код уйдет на прод.
Я согласен, что это перестраховка. Но если действовать так, то при малых затратах можно получить более высокую надежность.
А по поводу воина и солдата здесь смысл один. Воин действует "сам за себя", а солдат работает в команде. Командная работа, когда каждый действует не изолированно, а вместе, дает значительный профит. И да, это относится именно к организации процесса. ни в коем случае не говорю о том, что воина надо заменять.
Да, может, но ошибки нужно выявить, а их выявит регресс позже. В рамках задачи ошибка, не входящая в скоуп задачи, выявлена не будет. А если расширять критерии приемки задачи с учетом затронутой логики, получим "полный регресс", как я писал выше.
Мало того, сталкивался со случаями, когда в относительно сложной логике поверх одних измений, содержащих ошибку, накручивалась логика, эти изменения использующая. В этом случае исправление становится весьма нетривиальным.
В любом случае, если можно избежать сложностей, их стоит избежать.
Я найду время и сделаю "работу над ошибками" (поправлю неочевидные моменты).
Чтобы проверить каждую доработку, нужно знать, какие изменения сделаны и какая бизнес-логика затронута. Если же затронули больше, чем надо, то и проверить нужно больше.
(а возможно, даже провести полный регресс-тест всей системы)
Здесь говорится даже больше не о самом регрессе, а о том, что тестирование фичи при таких изменениях, а именно негативное тестирование, становится эквивалетно полному регресс-тесту системы.
для потребителя скорость изменений важнее их качества
Видимо, мне и правда нужно обдумать формулировки.
Для потребителя качество важнее, с этим спорить невозможно (да и не нужно)
Максимально быстрая доставка изменений пользователю - требование не пользователя, а бизнеса (потребность компании). Чем динамичнее развивается продукт и предоставляет новые фичи пользователю и закрывает ошибки в уже имеющемся, тем проще ему удержаться на рынке
Под максимально быстрой доставкой я понимаю доставку без ущерба качеству, но с учетом реального мира (когда "лучшее - враг хорошего"). Компромисс с бизнес потребностями такой: лучше доставить изменения хорошего качества быстро, чем идеальные, но намного позже. Особенно это касается исправления ошибок, в этом случае скорость доставки исправлений играет серьёзную роль.
Будто это так плохо. Регресс надо делать регулярно.
Плохо, когда вынуждены делать его незапланированно. Регулярный регресс системы - хорошая практика, когда он запланирован и выполняется как отдельная задача.
А если QA-инженеры помимо проверки конкретной задачи вынуждены в рамках нее еще и регресс всей системы делать, то доставка изменений на прод будет занимать огромное количество времени. Вот это уже плохо.
А если таких задач будет две? три? Делать полный регресс после каждой задачи, конечно, можно, но это явный оверхед.
Похоже мы друг друга не до конца не понимаем, возможно, я неверно формулирую.
Бизнес несет убытки от ошибок в любом случае. Вопрос в том, как это быстро и эффективно поправить.
Воин перепишет все, никого не спрашивая, что приведет к тому, что код дольше будет идти на прод, увеличивая потери бизнеса.
Я же говорю о том, что нужно подходить к решению организованно и рассматривать затраченные ресурсы не только свои, а всей команды. Чтобы все сделать правильно.
У Воина есть Честь и Кодекс. Компромиссные решения вызывают праведный гнев, а костыли и велосипеды - желание начать новый крестовый поход. "Воин в команде" проявляет инициативу и стремится сделать нашу жизнь лучше.
В Кодексе воина (западного или восточного) прописано стремление к перфекционизму и неприятие компромиссов. Исправить все и сразу.
У самураев есть интересное правило, которое может помочь в принятии решений в жизни:
Подумав - решайся. Решившись - не думай.
Но вот только "не думать" в разработке и идти любыми силами к идеальному коду зачастую приводит к большим проблемам.
Да, даже в этом случае. Критичные изменения можно и следует пустить отдельной задачей (веткой и так далее). Они так дойдут быстрее (пункт "Что делать с прочими обнаруженными проблемами?") А если твоя задача и есть в том, чтобы исправить возникшую проблему, то тут уже другой вопрос (ситуация с точечным и общим исправлением). Можно сделать быстрый хотфикс с точечным исправлением, а потом уже спокойно отдельной задачей продумать оптимизацию критичного участка. И опять же отдельной задачей.
не «оптимизируй» то что используется мало и редко, но работает
Это правильный и логичный подход. Это не "путь воина", о котором я говорил выше. Воин, скорее, наооборот, полезет оптимизировать все из лучших побуждений.
«оптимизируй» самый проблемный функционал
Путь воина - категорично исправить все и сразу. Что может привести к задержкам доставки кода на прод.
Если изменение критично, всегда можно сообщить об этом команде. И после того, как задача будет обсуждена и приоритезирована, а менджер даст добро, можно внести правки. Так проект станет более управляемым и будет иметь понятные сроки реализации.
Себе в прошлом (не таком далеком, как школа, скорее в универе и далее в начале карьеры программиста) я бы посоветовал больше учить технологий, читать статей о различных решениях и новых подходах в решении задач (особенно с архитектурной точки зрения). Тогда я, возможно, избежал бы многих «велосипедов» и «граблей». Например, не пытался бы создать свою реализацию общения между клиентом и сервером на TCP-сокетах с шифрованием и плюшками, если бы в то время узнал про WCF. Аналогично с Entity Framework и другими широко используемыми библиотеками.
С другой стороны автор правильно сказал:
Такие вещи нужно делать с одной целью — чтобы был собственный каталог граблей.
Такой малоприятный опыт помогает взглянуть на многие вещи более осознанно. Да и бросаться в другую крайность — знание технологий без знания, как он устроены — тоже плохой подход. Во всем нужен баланс.
Хранимые процедуры переносятся: код их создания будет присутствовать в скрипте генерации базы. Есть возможность выгрузки только скриптов хранимых процедур. Проверено для Sql Server 2014 и Microsoft SQL Server Management Studio 12.0.
Перенос с учетом локализации, согласен, довольно сложный. Однако я заострил внимание на скрипте генерации базы. В него необходимо внести дополнительные настройки, если это потребуется.
Насчет остального, опять же, я описал основное направление и те проблемы, с которыми столкнулся. Если кто-то поделится своим опытом и дополнит эту инструкцию, будет просто замечательно.
Такая вероятность была минимальна. Основное подозрение было на сами данные в базе. Некий неучтенный кейс поведения приложения, возможно нарушающий консистентность данных. Остановиться на Server 2016 я не мог, так как для базы требовалось дополнительное окружение (другие базы, сильная связанность данных), настройка которого потребовала бы гораздо большего времени.
Однако, в статье описан не сам поиск бага, а способ, как можно вытащить данные из бэкапа новой версии на сервер более старой версии. Поиск бага — всего лишь причина, по которой пришлось это сделать.
Поводов для использования этого способа немного, но они могут возникнуть. И, как написано в заключении, надеюсь, что это никому не понадобится.
Да, именно второй кейс и был описан. В данной задаче требовались только данные с продакшен-сервера, чтобы найти причину возникновения бага. Сам сервер так и продолжил работу, как и раньше. А воспроизведение ситуации для поиска ошибки велось уже на компьютере с локально установленной базой, на которой ты сам себе админ. Поэтому проблем с правами доступа не было.
Информация
В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Во-первых, в статье я, к сожалению, не заметил указания, что эта система должна предоставляться по желанию.
Во-вторых, лично я выбрал бы усложнение. Частично я с вами согласен. Но лишь частично.
В-третьих, с такой системой (если убрать незамеченное мной "по желанию") за других решаете как раз вы.
И последнее. Даже среди грамотно подкованных людей существует один недостаток, выражающийся в банальной фразе: "если это сложно и необязательно, то использоваться не будет".
Поэтому таких, кто реально (не в голосовании, а на практике) выберет такую сложную систему, а после некоторого времени ее использования с нее не уйдет, будет минимум. И именно поэтому банки не будут это делать, как их не заставляй.
Работать ради 0.1% рынка (цифру взял для из головы для красного слова, но не думаю, что в реале наберется хотя бы 5-10%) никто не станет. Особенно в такой неповоротливой сфере как банки.
P.S. однако мне понравился вот этот комментарий:
Вот это похоже на один из реальных способов простимулировать банки сделать хоть что-то. И именно так на них и стоит воздействовать.
Чем больше ключей и чем их сложность выше, тем сложнее пользователю их запомнить. Чем сложнее пользователю запомнить, тем выше вероятность, что он попытается облегчить себе жизни: записать на бумажку, сохранить в телефоне и так далее.
Поэтому можно придумать сколь угодно независимых ключей для доступа, но вся эта система с треском разобьется о бабушку, которая не сможет запомнить пароль сложнее, чем имя внучки + дата рождения.
К решению проблем безопасности нужно подходить с двух сторон: со стороны профессиональной (те самые варианты ключей и их независимость) и со стороны простого пользователя. А сделать простой, но безопасный ключ - весьма нетривиальная задача.
А с вашим десятком независимых ключей, выбор которых зависит от дня недели, ретроградного меркурия и луны в козероге, от услуг таких банков пользователи начнут уходить ибо "сложно, ничего не понятно".
Именно поэтому ему стоит сообщить о том, что ты задел другую логику, и на нее тоже стоит взглянуть.
Это да, хорошо, но автотесты - не панацея. Вы могли изменить логику таким образом, что ранее невозможный кейс стал актуальным. На него не будет автотестов.
Это все хорошо опять же для ранее существовавших кейсов. Если вы изменили критичную логику и создали "новый" кейс для "старой" логики, то никто, кроме вас этого не знает.
Юнит тесты вы сами поправите в соответствие с измененной логикой (хорошие тесты и так падают при изменении логики). Если это выявится на уровне PR, то хорошо. Но дальше, если никто не знает, то QA- инженер не протестирует и регресс тоже особо не выявит (некто ж не знает, что регресс надо расширить на ранее невозможный кейс). Код уйдет на прод.
Я согласен, что это перестраховка. Но если действовать так, то при малых затратах можно получить более высокую надежность.
А по поводу воина и солдата здесь смысл один. Воин действует "сам за себя", а солдат работает в команде. Командная работа, когда каждый действует не изолированно, а вместе, дает значительный профит. И да, это относится именно к организации процесса. ни в коем случае не говорю о том, что воина надо заменять.
Да, может, но ошибки нужно выявить, а их выявит регресс позже. В рамках задачи ошибка, не входящая в скоуп задачи, выявлена не будет. А если расширять критерии приемки задачи с учетом затронутой логики, получим "полный регресс", как я писал выше.
Мало того, сталкивался со случаями, когда в относительно сложной логике поверх одних измений, содержащих ошибку, накручивалась логика, эти изменения использующая. В этом случае исправление становится весьма нетривиальным.
В любом случае, если можно избежать сложностей, их стоит избежать.
Я найду время и сделаю "работу над ошибками" (поправлю неочевидные моменты).
Чтобы проверить каждую доработку, нужно знать, какие изменения сделаны и какая бизнес-логика затронута. Если же затронули больше, чем надо, то и проверить нужно больше.
Здесь говорится даже больше не о самом регрессе, а о том, что тестирование фичи при таких изменениях, а именно негативное тестирование, становится эквивалетно полному регресс-тесту системы.
Согласен, сформулировано неочевидно.
Видимо, мне и правда нужно обдумать формулировки.
Для потребителя качество важнее, с этим спорить невозможно (да и не нужно)
Максимально быстрая доставка изменений пользователю - требование не пользователя, а бизнеса (потребность компании). Чем динамичнее развивается продукт и предоставляет новые фичи пользователю и закрывает ошибки в уже имеющемся, тем проще ему удержаться на рынке
Под максимально быстрой доставкой я понимаю доставку без ущерба качеству, но с учетом реального мира (когда "лучшее - враг хорошего"). Компромисс с бизнес потребностями такой: лучше доставить изменения хорошего качества быстро, чем идеальные, но намного позже. Особенно это касается исправления ошибок, в этом случае скорость доставки исправлений играет серьёзную роль.
Плохо, когда вынуждены делать его незапланированно. Регулярный регресс системы - хорошая практика, когда он запланирован и выполняется как отдельная задача.
А если QA-инженеры помимо проверки конкретной задачи вынуждены в рамках нее еще и регресс всей системы делать, то доставка изменений на прод будет занимать огромное количество времени. Вот это уже плохо.
А если таких задач будет две? три? Делать полный регресс после каждой задачи, конечно, можно, но это явный оверхед.
Похоже мы друг друга не до конца не понимаем, возможно, я неверно формулирую.
Бизнес несет убытки от ошибок в любом случае. Вопрос в том, как это быстро и эффективно поправить.
Воин перепишет все, никого не спрашивая, что приведет к тому, что код дольше будет идти на прод, увеличивая потери бизнеса.
Я же говорю о том, что нужно подходить к решению организованно и рассматривать затраченные ресурсы не только свои, а всей команды. Чтобы все сделать правильно.
Возможно. Но я имел в виду немного другое:
В Кодексе воина (западного или восточного) прописано стремление к перфекционизму и неприятие компромиссов. Исправить все и сразу.
У самураев есть интересное правило, которое может помочь в принятии решений в жизни:
Но вот только "не думать" в разработке и идти любыми силами к идеальному коду зачастую приводит к большим проблемам.
Да, даже в этом случае. Критичные изменения можно и следует пустить отдельной задачей (веткой и так далее). Они так дойдут быстрее (пункт "Что делать с прочими обнаруженными проблемами?")
А если твоя задача и есть в том, чтобы исправить возникшую проблему, то тут уже другой вопрос (ситуация с точечным и общим исправлением). Можно сделать быстрый хотфикс с точечным исправлением, а потом уже спокойно отдельной задачей продумать оптимизацию критичного участка. И опять же отдельной задачей.
Это правильный и логичный подход. Это не "путь воина", о котором я говорил выше. Воин, скорее, наооборот, полезет оптимизировать все из лучших побуждений.
Путь воина - категорично исправить все и сразу. Что может привести к задержкам доставки кода на прод.
Если изменение критично, всегда можно сообщить об этом команде. И после того, как задача будет обсуждена и приоритезирована, а менджер даст добро, можно внести правки. Так проект станет более управляемым и будет иметь понятные сроки реализации.
С другой стороны автор правильно сказал:
Такой малоприятный опыт помогает взглянуть на многие вещи более осознанно. Да и бросаться в другую крайность — знание технологий без знания, как он устроены — тоже плохой подход. Во всем нужен баланс.
Проверено для Sql Server 2014 и Microsoft SQL Server Management Studio 12.0.
Насчет остального, опять же, я описал основное направление и те проблемы, с которыми столкнулся. Если кто-то поделится своим опытом и дополнит эту инструкцию, будет просто замечательно.
Однако, в статье описан не сам поиск бага, а способ, как можно вытащить данные из бэкапа новой версии на сервер более старой версии. Поиск бага — всего лишь причина, по которой пришлось это сделать.
Поводов для использования этого способа немного, но они могут возникнуть. И, как написано в заключении, надеюсь, что это никому не понадобится.