Весьма забавно, что почти все «проблемы плохого кода» связаны совсем не с разработкой и потому в «разработке» решены быть не могут. (В разработке необходимо и достаточно чтобы все участники понимали и стремились придерживаться DRY, DI,SRP. Если в группе разработки все будут придерживаться этих принципов, то даже есликогда внутри классов присутствует откровенный говнокод, взаимодействие между классами как правило достаточно простое и позволяет «расширять» и «углублять» в нужных местах по необходимости)
Все описанные в посте проблемы растут из неспособности т.н. руководителей к диалогу (впрочем неспособность к диалогу присуща многим) + иногда стремление «руководить» а не «решать задачу».
P.S. «вдруг оказывался совершенно запутанным» — вот это вот «вдруг» — очень повеселило.
Не пробовали сделать мини-версию магазина как приложение контакта? (Интересует насколько легче посетители перетекают в покупателей) Оно будет выглядеть как приложение группы, ссылки на товары перестанут быть внешними, оплатить можно будет в т.ч. голосами, да и вообще — регистрация не нужна, а заказ оформляется часто в 1 клик
Наталья, как мне кажется, говорила всё же о конфликтах разработки и тестирования.
Что же до ошибок верхнего менеджмента и конкретно приводимых вами примеров — да такое тоже бывает. Люди часто ошибаются) — но это уже совсем другая проблема.
Я не имею опыта в прохождении организацией сертификаций типа CMMI или ISO (Видимо подразумевается семейство ISO9000 которое окружает нас повсюду, либо какой-то из его родственников/потомков ) и имею, если честно, весьма поверхностное представление о них. Но насколько я помню/понимаю — там высказываются довольно общие идеи из серии «в организации должен быть отдел контроля качества, который занимается контролем качества. эффективность работы отдела определяется разработанными и утвержденными в организации метриками». Уверен, что там нет нислова про то что такими метриками качества работы обязательно является «количество ошибок вообще» и/или «количество блокеров».
Я уверен что, что прохождение сертификации не является причиной ошибочных решений.
Если верхнее руководство ошиблось и ввело метрики которые ухудшают качество работы — варианта 3:
1)Смириться и остаться
2)Смириться и в скором времени сменить работу
3)Начать диалог.
с вариантами 1 и 2 всё вобщем ясно (на всякий случай — «уйти» — не всегда является плохим решением)
А вот про 3ий вариант хочется сказать немного подробней. В нашей отрасли редко кто стремится к диалогу. Чаще бывает так что: верхнее начальство придумало очередную ерунду, и разработчики вместо того чтобы разобраться, сформулировать свою позицию и попытаться обсудить сложившуюся ситуацию — сразу «встают и уходят».
Нет — понятно если эта работа «так себе». Но если это место работы вам нравится — обязательно надо «поговорить».
В случае с навязыванием метрик которые вредят — попробуйте написать письмо. Там будут ваши предложения — ввести новые метрики. Мотивационная часть новых метрик. Сравнение предлагаемых метрик с уже введенными а в особенности — с ошибочными (важный момент — избегать даже намеков на то что «кто-то» ошибся введя неверные метрики. иначе защита, агрессия, диалогу конец). Поймите, что руководство компании обычно заинтересовано в том чтобы всё было хорошо значительно рядовых сотрудников. И если идея здравая и внесена правильно — её скорей всего поддержат (и с удовольствием выдадут за свою) )
«Почему такое происходит?»
Всё вобщем написано верно (и про уровень квалификации, и про то что введение неправильных KPI вредит ходу проекта). Но честно гововря это всё декорации, на фоне которых разворачивается главное действие и источник проблем:
1)Повсеместный нарцысизм/стремление к интеллектуальному эллитизму который выражается в высокомерно-пренебрежительно-снисходительном отношении между участниками проекта. Причём выражается это часто как вербально так и невербально.
2)Низкая квалификация и/или попустительство линейных руководителей. PM не проводит приватных бесед со своими «звездами», на тему того что мы все делаем общее дело, что нет разделения на «мы» и «они», что наша общая цель — не обосраться после релиза, а вовсе не соревнования кунг-фу по переписке между тестированием и разработкой.
Кому-то может показаться что это «детский сад», что у нас же работают опытные взрослые люди. Тем-не менее «неконструктивное поведение» присуще людям внезависимости от возраста и квалификации. Вербальные и невербальные проявления высокомерия и проч — вызывают в ответ только проявление агресси — что негативно сказывается на общей эффективности и результатах.
«Програмисстские проекты» тут как правило вообще не причём.
Согласитесь, что чтобы понять в какой последовательности должны быть расположены поля формы какогото доумента — не надо быть «крутым компьютерщиком» или чтото понимать в новомодных ныне «usability» и «UX» — для ответа на этот вопрос достаточно понаблюдать как люди заполняют соответсвующи бумажный бланк. в какой последовательности, куда подглядывают, с чем сверяются. И из этого этого вырастает пусть, возможно, не самый лучший вариант, но уже достаточно хороший и обоснованный.
И если в данной ситуации начальник этих операторов упорствует и требует всё неприменно сделать по «евойному» — то он просто «идиот».
А по поводу вашего тезиса о «невозможности удовлетворить всех» — в целом согласен. Но «математика» тут не причём) Причины этих проблем всёже — человеческий фактор, а не фундаментальное противоречие OLTP и OLAP)
Кстати — может быть кто-то может порекомендовать какую-нибудь толковую книгу по работе с людьми которые настроены неконструктивно?
«Согласитесь, когда оно жестко прописано разрабатывать гораздо легче. „
Я бы сказал по другому: хорошо когда есть заинтересованность и диалог. ТЗ как таковое тут не причём)
ТЗ вобще стало одним из buzzword в нашей отрасли. Юмор ситуации в том что, хотя это мало кто осознаёт, ТЗ ничего не гарантирует и ни от чего не защищает. Точней ТЗ “защищает» интересы только юристов.
Дело вот в чём. Представте. Есть заказчик, Есть Подрядчик. Они составили подробнейшее ТЗ («жестко всё прописали»). Начали делать. Закрываются этапы. Заказчик их так или иначе оплачивает. И вот в какой-то момент — толи потому что по статистика все идиоты, толи потому что жизнь так устроена и обстоятелсьтва изменились, заказчик гововрит что ему нужно [не]совсем другое.
Вот ситуация. Да есть ТЗ. В котором всё «жётско» пропсиано. Что делать?
«ТЗ защищает интересы подрядчика» — очевидно что нет. Бекоспромисность под предлгом того что в ТЗ всё жестко пропсиано — прямая дорога к убыткам и длительным судебный разбирательствам с целью получить деньги за выполненный, но непринятый этап и не оплаченный этап(а ведь есть догвоовры в которы есть предоплата, и оплата по завершении) + отрицательная карма.
«ТЗ защищает заказчика» — тоже очевижно что нет. Подрядчик чтото сделал. Может похожее на ТЗ может не похожее. Но в любом случае — не то что нужно заказчику. Требовать по ТЗ? Угрожать не оплатить этап работ? Разорвать договор? Требовать выплат неустоек предусмотренных догвоовром?
Это опять — потеря времени, потеря денег, суды, а главное — если вам разработка для чегото была нужна — у вас её как небыло так и нет и в ближайшее время уже точно не появится.
Перспективы подбного рода судебных разбирательств весьма туманны если честно. Дело в том что судья — он как бэ ничего в этом не понимает. И в своих суждениях он может опираться только на заключения экспертов. Каждая из сторон естесвенно представит своих экспертов.
+Если например у вас приложением к договору идут документы где есть какието «схемки» (типа UML и проч нотаций) и тз писал подрядчик — то заказчик так вобще ничего в этих схемах не понимает — может подрядчик мошенник может нет. новые экспертизы экспертов.
+ затягивание процесса.
профит только у юристов и экспертов. у всех остальных участников — убытки.
Так что «жесткое ТЗ» как и любая другая безкомпромиссная позиция чаще всего оказываются ошибочной.
Хотя безусловно — подбробное, полное и непротиврочивое тз оно безусловно хорошо и способствует реализации — но вот от «изменений» никак не страхует.
Дополнительно:
«Я отключился от сети/Сменил компьютер — мои данные исчезнут?»
На обязательно. Возможные варианты:
1)когда нибудь внедрят ipv6 и хранилищем ваших данных наконецто станет холодильник с прямым адресом (он работает всегда)
2)тенденция некоторого класса устройств (андройдо/яблоко-фоны) постоянно присутсвовать в сети очевидно будет только наберать обороты
3)«Всего за 2,99$/мес» вы сможете сделать свой информаицонный клон который живёт на всешнем хостинге
«в любом случае нельзя гарантировать, данные не появятся в кеше какой-нибудь другой системы или поисковой машины.» — только вы определяете степень публичности. Ни Брин, ни Цукерберг, ни Дуров. Потому что
4)Если ваши данные зашифровать вашим приватным ключем, а потом зашифровать публичным ключем вашего френда — то такой файл (а точней файлы — для каждого френда придётся шифровать копию специально для него, но это не проблема — делается вроде довольно быстро, а места на жестких дисках уже давно не проблема) — то такой файл можно безопасно хранить на любых публичных хостингах (дабы ваши френды могли получить информацию даже когда вас нет в сети) и/или синхронизировать хоть через тот же дропбокс (это к вопросу о смене компа-телефона-итп) — ваши данные будут доступны только вам и вашему другу и больше никому не смотряна то что они хранятся в публичных местах.
Естесвтенно чт спецслужбы при желании смогут получить доступ к вашим данным — путем внедрения в круг доверия или проникновения на компьютер когото из друзей, но согласитесь, это значительно лучше чем то что сейчас.
Если добавить к этому открытый протокол общения — то любой сможет реализовать альтернативный клиент и мы избавляемся от анализа поведения и показа рекламы. Точка.
«Лучше»
что ваши данные — только ваши. Никто не может требовать от вас реальных ФИО, фотографии, телефона. Никто не может изменить внезапно правила таким образом что внезапно все ваши данные оказываются доступны все сети. Сложно анализировать ваше поведение, очень сложно показывать рекламу, очень сложно спамить — ведь нет каталога.
opera (некоторые приложения opera unite) пытается делать нечто похожее но с другой стороны.
Более реалистичным видится именно путь по котому пошла опера.
В браузер встраивается некоторое ПО.
По средством которого пользователь предоставляет в сеть свои данные:
Фото, контактная информация, «статус» (аналог бесконечным статусам контактиков и твиттер).
Устройство пользователя является физическим носителем этой информации. Фотоальбомы/видео -можно как хранить у себя (для параноиков), так и загружать на хостинги фотографий/фидео, а у себя хранить только метаинформацию.
ПО так же экспортирует rss (например) ленту с новостями (изменение статуса, контактных данных, и другие события о которых пользователь захочет рассказать другим пользователям).
А дальше — ты с помощью обычных поисковиков находишь информацию предоставляемую другими людьми. Добавляешься к ним в друзья, и получаешь доступ к их ленте событий, и прочей информации.
ПО помимо публикации так же регулярно опрашивает ленты друзей на предмет новых событий.
Получается в некотором смысле — просто миллионы персональных бложиков + некоторый общий протокол взаимодействия. Разница только в том что все данных хранятся у тебя. Никто не требует твой номер телефона, Настоящее ФИО и фотографию.
Естесвенно в туже кучу — ассиметричное шифрование для каждого учатсника + нужна какаято децентрализованная технология подддержания целостности для информации вроде «встречки с обсуждением» — чтобы информация хранилась у всех участников и даже если создатель встречи сейчас недоступен — люди могли участвоавать в обсуждении
«9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.»
На мой взгляд оч интересное необходимое условие.
Если любой запрос «представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована» — то тогда любой запрос автоматически проходт это условие. Тогда зачем введено это условие?
А вот ещё интересный вопрос — если «заинтересованное лицо» — заблуждается относительности «неполноценности» и невозможности «проигнорировать». В этой ситуации — запрос уже не явлется требованием? Или всётаки является?
теория такая теория. Она помогает создавать иллюзию контроля и порядка)))
Смиритесь или менйте работу.
КО как бэ подсказывает «требования» меняются.
Это может происходить по разным причинам. Среди них:
1)Политические игры в стане заказчиков.
2)«Заказчик» — идиот
3)PM со стороны заказчика идиот
3)Ваш аналитик — идиот
4)Ваш PM — идиот
5)Вы идиот
6)«жизнь» не стоит на месте — и всё меняется.
(никогда не задумывались почему PMI приводит такую ужасающую статистику по успешному заверщению проектов? И это учитывая что далеко не всякая организованная активность может называться проектом. А только активность котороая соответсвует вполне конкретным правилам и должным образом оформленная)
Вобщем пока заказчик готов оплачивать все свои фантазии — задача «разработки» всяечки способствовать их воплощению в жизнь. ПОменялись фантазии — ок — строим новые. Есессно при условии что всякая работа требует денег и времени — если если нет — смените работу.
по поводу 2го пункта:
КО как бэ нмаекает что не rocket же science
1)открыть firebug и убедиться что цыферки загружаются ajax
2)делай запрос @ парси результат
в том контексте который я описал выше — всё становится с ног на голову)
в модульном тестировании — всё достаточно просто и тестировать работу операций действительно удобно попарно с их обратными «функциями». Но такие случаи — не модульное тестирование)
Когда у нас есть огромный кусок кода, у которого много обязанностей (да и чего уж там — иной раз просто непонятно что этот кусок в точности делает) — тут тестировать обратными функциями конечно можно, но это стоит дороже.
Нам нужно добавить например 100 сущностный что бы проверить операцию чтения. Да причём ещё не рэндомных — а сущностей с некоторыми условиями. А когда вы не знаете что именно делает этот код — это становится сложно — требуется сначала разобраться, затем или написать какой-то генератор или руками нагенерить данные. Это всё требует времени и так же сопряжено с ошибками.
С другой же стороны — у нас уже есть набор данных в базе — на котором работает наша система. Есть собственно сама рабочая система. В данной ситуации выглядит более разумным сделать примерно следующее:
0)«Оторвать» представление дабы мы могли внедрить туда нужный нам объект.
1)Делаем дамп боевой базы
2)ждём 1-2-3 дня (попутно собирая подробные аксеслоги. не забываем про параметры POST)
(3) опционально -Делаем новый дамп базы.
Далее делается 2 тестовых инстанса:
1)работающая сейчас система
2)система на которой мы проводим рефакторинг
каждой из них даётся слепок базы из п. (1)
и начинают накатываться запросы из аксеслога (оригинальный или модифициорованный)
внедренные вместо шаблонизатора заглушки повзволяют нам сравнивать какие данные хотят вывести обе системы.
как вариант используем дамп (3) и сравниваем с тем что получилось у нас. (эффекты связанные со временем или игнорируются или учитываются специальным образом по мере обнаружения) )
Такой подход (ну и его вариации) позволяет нам не разбираясь как именно работает наша система отвечать на вопрос продолжает ли она работать так же. Строится быстрей, менее хрупкая чем ручные автотесты для такого монолита, содержит меньше ошибок (когда я не понимаю что именно должен делать участок кода но пишу для него автотест — это непонимаение отражается и в тесте)
вот как-то так.
ну и ещё раз — это не модульное тестирование и здесь «всё по другому»)
Ну представте, что у вас и «бизнесс логика» закодирована прямо в экшенах контроллера и всё это выглядит например так:
валидация данных из $_POST
чтение чегото из базы (вот прямо mysql_query)
какие-то манипуляции с прочитанными данными и данными из базы (прямо здесь же. в лучшем случае в приватных методах/функциях)
запись данных в базу (всё тем же mysql_query)
вывод результатов (часто с ипользованием чего-нибудь типа Smarty) )
В такой ситуации просто нет других интерфейсов на которые можно было бы опереться при тестировании
у них другая проблема.
У них есть монолитная система. Скорей всего — достаточно сложная (простую систему можно было бы быстро переписать).
Есть потребность навести в системе порядок. Хотя бы минимальный.
Каждое изменение сопряжено с появлением новых ошибок (много связей + языки с динамической типизацией помогают).
Единственные стабильные интерфейсы в такой ситуации это со стороны пользователя (напр. контроллеры в MVC) и со стороны базы. Все остальные интерфейсы будут меняться в процессе рефаткоринга.
Вот и они и стремятся написать автотесты через те стабильные интерфейсы что у них есть, чтобы во время рефаткоринга получать информацию что «вроде работает так же ка краньше». Других враиантов кроме как «с базой» у них особо нет.
Да. Всё верно.
Но просто дело в том что в вашем случае это не ЮНИТ-тесты.
Плохо спроектированные системы не поддаются модульному тестированию. Автотесты которые при определённых усилиях можно для таких систем написать — как правило большие, сложные (сложность часто сравнима с тестируемой подсистемой) и очень хрупкие. Они долго пишутся, часто исправляются.
Это может называться функциональными или интеграционными тестами в зависимости от масштаба бедствия. но никак не модульными.
юнит-тест является автотестом. обратное верно не всегда. И распространение материалов в которых автотесты «вообще» названы модульными — формирует неправильное представление у наших с вами коллег вообще (и связаных с php в частности) и в конечном итоге способствует увеличению числа проектов вроде того в котором оказались вы.
Кстати — не думали о смене места работы?
Учиться новому и перенимать лучше практики — луче же чем исправлять чужие ошибки. Тем более что такая работа часто бывает невидна и непонятна «обычным людям» (читай представителям бизнеса)
Вот так вот и плодятся массовые заблуждения относительно юнитетестов, из которых потом вырастает убежденность что модульное тестирование это «долго и дорого».
Контролллер -> Фасад -> микс из доменных объектов и сервисов -> Репозиторий/ДАО ->реляционнаясубд/key-value хранилище/in-memory/ file/etc
Так вот юниттест пишется Для! интерфейса! вашего хранилища/dao. Он независим от вашей реализации и работает всегда одинаково. (И когда вы смените реализацию — поможет убедиться что ничего не поменялось) Почти все тесты для него пишут так же как в младших классах нас учили проверять результаты вычислений: результат умножения проверяется делением, сложения — вычитанием. Ну или чуть более формально: f^-1(f(A))==A
Для тестирования «другой» стороны — используются разного рода «пустышки».
И всё. Никаких БД. (если конечно это МОДУЛЬНОЕ тестирование)
есликогда внутри классов присутствует откровенный говнокод, взаимодействие между классами как правило достаточно простое и позволяет «расширять» и «углублять» в нужных местах по необходимости)Все описанные в посте проблемы растут из неспособности т.н. руководителей к диалогу (впрочем неспособность к диалогу присуща многим) + иногда стремление «руководить» а не «решать задачу».
P.S. «вдруг оказывался совершенно запутанным» — вот это вот «вдруг» — очень повеселило.
«резко поменять» — да может. Всё меняется. «контроль» лишь иллюзия.
После того как начнёте использовать подобный магазин — обязательно поделитесь статистикой)
Что же до ошибок верхнего менеджмента и конкретно приводимых вами примеров — да такое тоже бывает. Люди часто ошибаются) — но это уже совсем другая проблема.
Я не имею опыта в прохождении организацией сертификаций типа CMMI или ISO (Видимо подразумевается семейство ISO9000 которое окружает нас повсюду, либо какой-то из его родственников/потомков ) и имею, если честно, весьма поверхностное представление о них. Но насколько я помню/понимаю — там высказываются довольно общие идеи из серии «в организации должен быть отдел контроля качества, который занимается контролем качества. эффективность работы отдела определяется разработанными и утвержденными в организации метриками». Уверен, что там нет нислова про то что такими метриками качества работы обязательно является «количество ошибок вообще» и/или «количество блокеров».
Я уверен что, что прохождение сертификации не является причиной ошибочных решений.
Если верхнее руководство ошиблось и ввело метрики которые ухудшают качество работы — варианта 3:
1)Смириться и остаться
2)Смириться и в скором времени сменить работу
3)Начать диалог.
с вариантами 1 и 2 всё вобщем ясно (на всякий случай — «уйти» — не всегда является плохим решением)
А вот про 3ий вариант хочется сказать немного подробней. В нашей отрасли редко кто стремится к диалогу. Чаще бывает так что: верхнее начальство придумало очередную ерунду, и разработчики вместо того чтобы разобраться, сформулировать свою позицию и попытаться обсудить сложившуюся ситуацию — сразу «встают и уходят».
Нет — понятно если эта работа «так себе». Но если это место работы вам нравится — обязательно надо «поговорить».
В случае с навязыванием метрик которые вредят — попробуйте написать письмо. Там будут ваши предложения — ввести новые метрики. Мотивационная часть новых метрик. Сравнение предлагаемых метрик с уже введенными а в особенности — с ошибочными (важный момент — избегать даже намеков на то что «кто-то» ошибся введя неверные метрики. иначе защита, агрессия, диалогу конец). Поймите, что руководство компании обычно заинтересовано в том чтобы всё было хорошо значительно рядовых сотрудников. И если идея здравая и внесена правильно — её скорей всего поддержат (и с удовольствием выдадут за свою) )
вот как-то так.
Всё вобщем написано верно (и про уровень квалификации, и про то что введение неправильных KPI вредит ходу проекта). Но честно гововря это всё декорации, на фоне которых разворачивается главное действие и источник проблем:
1)Повсеместный нарцысизм/стремление к интеллектуальному эллитизму который выражается в высокомерно-пренебрежительно-снисходительном отношении между участниками проекта. Причём выражается это часто как вербально так и невербально.
2)Низкая квалификация и/или попустительство линейных руководителей. PM не проводит приватных бесед со своими «звездами», на тему того что мы все делаем общее дело, что нет разделения на «мы» и «они», что наша общая цель — не обосраться после релиза, а вовсе не соревнования кунг-фу по переписке между тестированием и разработкой.
Кому-то может показаться что это «детский сад», что у нас же работают опытные взрослые люди. Тем-не менее «неконструктивное поведение» присуще людям внезависимости от возраста и квалификации. Вербальные и невербальные проявления высокомерия и проч — вызывают в ответ только проявление агресси — что негативно сказывается на общей эффективности и результатах.
Согласитесь, что чтобы понять в какой последовательности должны быть расположены поля формы какогото доумента — не надо быть «крутым компьютерщиком» или чтото понимать в новомодных ныне «usability» и «UX» — для ответа на этот вопрос достаточно понаблюдать как люди заполняют соответсвующи бумажный бланк. в какой последовательности, куда подглядывают, с чем сверяются. И из этого этого вырастает пусть, возможно, не самый лучший вариант, но уже достаточно хороший и обоснованный.
И если в данной ситуации начальник этих операторов упорствует и требует всё неприменно сделать по «евойному» — то он просто «идиот».
А по поводу вашего тезиса о «невозможности удовлетворить всех» — в целом согласен. Но «математика» тут не причём) Причины этих проблем всёже — человеческий фактор, а не фундаментальное противоречие OLTP и OLAP)
Кстати — может быть кто-то может порекомендовать какую-нибудь толковую книгу по работе с людьми которые настроены неконструктивно?
Я бы сказал по другому: хорошо когда есть заинтересованность и диалог. ТЗ как таковое тут не причём)
ТЗ вобще стало одним из buzzword в нашей отрасли. Юмор ситуации в том что, хотя это мало кто осознаёт, ТЗ ничего не гарантирует и ни от чего не защищает. Точней ТЗ “защищает» интересы только юристов.
Дело вот в чём. Представте. Есть заказчик, Есть Подрядчик. Они составили подробнейшее ТЗ («жестко всё прописали»). Начали делать. Закрываются этапы. Заказчик их так или иначе оплачивает. И вот в какой-то момент — толи потому что по статистика все идиоты, толи потому что жизнь так устроена и обстоятелсьтва изменились, заказчик гововрит что ему нужно [не]совсем другое.
Вот ситуация. Да есть ТЗ. В котором всё «жётско» пропсиано. Что делать?
«ТЗ защищает интересы подрядчика» — очевидно что нет. Бекоспромисность под предлгом того что в ТЗ всё жестко пропсиано — прямая дорога к убыткам и длительным судебный разбирательствам с целью получить деньги за выполненный, но непринятый этап и не оплаченный этап(а ведь есть догвоовры в которы есть предоплата, и оплата по завершении) + отрицательная карма.
«ТЗ защищает заказчика» — тоже очевижно что нет. Подрядчик чтото сделал. Может похожее на ТЗ может не похожее. Но в любом случае — не то что нужно заказчику. Требовать по ТЗ? Угрожать не оплатить этап работ? Разорвать договор? Требовать выплат неустоек предусмотренных догвоовром?
Это опять — потеря времени, потеря денег, суды, а главное — если вам разработка для чегото была нужна — у вас её как небыло так и нет и в ближайшее время уже точно не появится.
Перспективы подбного рода судебных разбирательств весьма туманны если честно. Дело в том что судья — он как бэ ничего в этом не понимает. И в своих суждениях он может опираться только на заключения экспертов. Каждая из сторон естесвенно представит своих экспертов.
+Если например у вас приложением к договору идут документы где есть какието «схемки» (типа UML и проч нотаций) и тз писал подрядчик — то заказчик так вобще ничего в этих схемах не понимает — может подрядчик мошенник может нет. новые экспертизы экспертов.
+ затягивание процесса.
профит только у юристов и экспертов. у всех остальных участников — убытки.
Так что «жесткое ТЗ» как и любая другая безкомпромиссная позиция чаще всего оказываются ошибочной.
Хотя безусловно — подбробное, полное и непротиврочивое тз оно безусловно хорошо и способствует реализации — но вот от «изменений» никак не страхует.
Видите, всё предусмотрено)
«Я отключился от сети/Сменил компьютер — мои данные исчезнут?»
На обязательно. Возможные варианты:
1)когда нибудь внедрят ipv6 и хранилищем ваших данных наконецто станет холодильник с прямым адресом (он работает всегда)
2)тенденция некоторого класса устройств (андройдо/яблоко-фоны) постоянно присутсвовать в сети очевидно будет только наберать обороты
3)«Всего за 2,99$/мес» вы сможете сделать свой информаицонный клон который живёт на всешнем хостинге
«в любом случае нельзя гарантировать, данные не появятся в кеше какой-нибудь другой системы или поисковой машины.» — только вы определяете степень публичности. Ни Брин, ни Цукерберг, ни Дуров. Потому что
4)Если ваши данные зашифровать вашим приватным ключем, а потом зашифровать публичным ключем вашего френда — то такой файл (а точней файлы — для каждого френда придётся шифровать копию специально для него, но это не проблема — делается вроде довольно быстро, а места на жестких дисках уже давно не проблема) — то такой файл можно безопасно хранить на любых публичных хостингах (дабы ваши френды могли получить информацию даже когда вас нет в сети) и/или синхронизировать хоть через тот же дропбокс (это к вопросу о смене компа-телефона-итп) — ваши данные будут доступны только вам и вашему другу и больше никому не смотряна то что они хранятся в публичных местах.
Естесвтенно чт спецслужбы при желании смогут получить доступ к вашим данным — путем внедрения в круг доверия или проникновения на компьютер когото из друзей, но согласитесь, это значительно лучше чем то что сейчас.
Если добавить к этому открытый протокол общения — то любой сможет реализовать альтернативный клиент и мы избавляемся от анализа поведения и показа рекламы. Точка.
что ваши данные — только ваши. Никто не может требовать от вас реальных ФИО, фотографии, телефона. Никто не может изменить внезапно правила таким образом что внезапно все ваши данные оказываются доступны все сети. Сложно анализировать ваше поведение, очень сложно показывать рекламу, очень сложно спамить — ведь нет каталога.
Более реалистичным видится именно путь по котому пошла опера.
В браузер встраивается некоторое ПО.
По средством которого пользователь предоставляет в сеть свои данные:
Фото, контактная информация, «статус» (аналог бесконечным статусам контактиков и твиттер).
Устройство пользователя является физическим носителем этой информации. Фотоальбомы/видео -можно как хранить у себя (для параноиков), так и загружать на хостинги фотографий/фидео, а у себя хранить только метаинформацию.
ПО так же экспортирует rss (например) ленту с новостями (изменение статуса, контактных данных, и другие события о которых пользователь захочет рассказать другим пользователям).
А дальше — ты с помощью обычных поисковиков находишь информацию предоставляемую другими людьми. Добавляешься к ним в друзья, и получаешь доступ к их ленте событий, и прочей информации.
ПО помимо публикации так же регулярно опрашивает ленты друзей на предмет новых событий.
Получается в некотором смысле — просто миллионы персональных бложиков + некоторый общий протокол взаимодействия. Разница только в том что все данных хранятся у тебя. Никто не требует твой номер телефона, Настоящее ФИО и фотографию.
Естесвенно в туже кучу — ассиметричное шифрование для каждого учатсника + нужна какаято децентрализованная технология подддержания целостности для информации вроде «встречки с обсуждением» — чтобы информация хранилась у всех участников и даже если создатель встречи сейчас недоступен — люди могли участвоавать в обсуждении
«9.Обязательность — требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована. Необязательное требование — противоречие самому понятия требования.»
На мой взгляд оч интересное необходимое условие.
Если любой запрос «представляет собой определенную заинтересованным лицом характеристику, отсутствие которой ведет к неполноценности решения, которая не может быть проигнорирована» — то тогда любой запрос автоматически проходт это условие. Тогда зачем введено это условие?
А вот ещё интересный вопрос — если «заинтересованное лицо» — заблуждается относительности «неполноценности» и невозможности «проигнорировать». В этой ситуации — запрос уже не явлется требованием? Или всётаки является?
теория такая теория. Она помогает создавать иллюзию контроля и порядка)))
КО как бэ подсказывает «требования» меняются.
Это может происходить по разным причинам. Среди них:
1)Политические игры в стане заказчиков.
2)«Заказчик» — идиот
3)PM со стороны заказчика идиот
3)Ваш аналитик — идиот
4)Ваш PM — идиот
5)Вы идиот
6)«жизнь» не стоит на месте — и всё меняется.
(никогда не задумывались почему PMI приводит такую ужасающую статистику по успешному заверщению проектов? И это учитывая что далеко не всякая организованная активность может называться проектом. А только активность котороая соответсвует вполне конкретным правилам и должным образом оформленная)
Вобщем пока заказчик готов оплачивать все свои фантазии — задача «разработки» всяечки способствовать их воплощению в жизнь. ПОменялись фантазии — ок — строим новые. Есессно при условии что всякая работа требует денег и времени — если если нет — смените работу.
КО как бэ нмаекает что не rocket же science
1)открыть firebug и убедиться что цыферки загружаются ajax
2)делай запрос @ парси результат
в модульном тестировании — всё достаточно просто и тестировать работу операций действительно удобно попарно с их обратными «функциями». Но такие случаи — не модульное тестирование)
Когда у нас есть огромный кусок кода, у которого много обязанностей (да и чего уж там — иной раз просто непонятно что этот кусок в точности делает) — тут тестировать обратными функциями конечно можно, но это стоит дороже.
Нам нужно добавить например 100 сущностный что бы проверить операцию чтения. Да причём ещё не рэндомных — а сущностей с некоторыми условиями. А когда вы не знаете что именно делает этот код — это становится сложно — требуется сначала разобраться, затем или написать какой-то генератор или руками нагенерить данные. Это всё требует времени и так же сопряжено с ошибками.
С другой же стороны — у нас уже есть набор данных в базе — на котором работает наша система. Есть собственно сама рабочая система. В данной ситуации выглядит более разумным сделать примерно следующее:
0)«Оторвать» представление дабы мы могли внедрить туда нужный нам объект.
1)Делаем дамп боевой базы
2)ждём 1-2-3 дня (попутно собирая подробные аксеслоги. не забываем про параметры POST)
(3) опционально -Делаем новый дамп базы.
Далее делается 2 тестовых инстанса:
1)работающая сейчас система
2)система на которой мы проводим рефакторинг
каждой из них даётся слепок базы из п. (1)
и начинают накатываться запросы из аксеслога (оригинальный или модифициорованный)
внедренные вместо шаблонизатора заглушки повзволяют нам сравнивать какие данные хотят вывести обе системы.
как вариант используем дамп (3) и сравниваем с тем что получилось у нас. (эффекты связанные со временем или игнорируются или учитываются специальным образом по мере обнаружения) )
Такой подход (ну и его вариации) позволяет нам не разбираясь как именно работает наша система отвечать на вопрос продолжает ли она работать так же. Строится быстрей, менее хрупкая чем ручные автотесты для такого монолита, содержит меньше ошибок (когда я не понимаю что именно должен делать участок кода но пишу для него автотест — это непонимаение отражается и в тесте)
вот как-то так.
ну и ещё раз — это не модульное тестирование и здесь «всё по другому»)
валидация данных из $_POST
чтение чегото из базы (вот прямо mysql_query)
какие-то манипуляции с прочитанными данными и данными из базы (прямо здесь же. в лучшем случае в приватных методах/функциях)
запись данных в базу (всё тем же mysql_query)
вывод результатов (часто с ипользованием чего-нибудь типа Smarty) )
В такой ситуации просто нет других интерфейсов на которые можно было бы опереться при тестировании
У них есть монолитная система. Скорей всего — достаточно сложная (простую систему можно было бы быстро переписать).
Есть потребность навести в системе порядок. Хотя бы минимальный.
Каждое изменение сопряжено с появлением новых ошибок (много связей + языки с динамической типизацией помогают).
Единственные стабильные интерфейсы в такой ситуации это со стороны пользователя (напр. контроллеры в MVC) и со стороны базы. Все остальные интерфейсы будут меняться в процессе рефаткоринга.
Вот и они и стремятся написать автотесты через те стабильные интерфейсы что у них есть, чтобы во время рефаткоринга получать информацию что «вроде работает так же ка краньше». Других враиантов кроме как «с базой» у них особо нет.
просто такие тесты — совсем не «юнит».
О терминологической неточности которая вводит в заблуждение коллег по цеху.
Но просто дело в том что в вашем случае это не ЮНИТ-тесты.
Плохо спроектированные системы не поддаются модульному тестированию. Автотесты которые при определённых усилиях можно для таких систем написать — как правило большие, сложные (сложность часто сравнима с тестируемой подсистемой) и очень хрупкие. Они долго пишутся, часто исправляются.
Это может называться функциональными или интеграционными тестами в зависимости от масштаба бедствия. но никак не модульными.
юнит-тест является автотестом. обратное верно не всегда. И распространение материалов в которых автотесты «вообще» названы модульными — формирует неправильное представление у наших с вами коллег вообще (и связаных с php в частности) и в конечном итоге способствует увеличению числа проектов вроде того в котором оказались вы.
Кстати — не думали о смене места работы?
Учиться новому и перенимать лучше практики — луче же чем исправлять чужие ошибки. Тем более что такая работа часто бывает невидна и непонятна «обычным людям» (читай представителям бизнеса)
Контролллер -> Фасад -> микс из доменных объектов и сервисов -> Репозиторий/ДАО ->реляционнаясубд/key-value хранилище/in-memory/ file/etc
Так вот юниттест пишется Для! интерфейса! вашего хранилища/dao. Он независим от вашей реализации и работает всегда одинаково. (И когда вы смените реализацию — поможет убедиться что ничего не поменялось) Почти все тесты для него пишут так же как в младших классах нас учили проверять результаты вычислений: результат умножения проверяется делением, сложения — вычитанием. Ну или чуть более формально: f^-1(f(A))==A
Для тестирования «другой» стороны — используются разного рода «пустышки».
И всё. Никаких БД. (если конечно это МОДУЛЬНОЕ тестирование)