ИИ умеет придумывать идеи, но не умеет в них верить
30 июля в Telegram-канале «Топор. Экономика» появилась новость о том, что московские налоговые инспекции начали массово рассылать письма неработающим гражданам, приобретающим дорогие автомобили, квартиры и яхты.
В сообщении утверждалось, что инспекторы требуют письменные пояснения и документы, подтверждающие происхождение денежных средств, использованных для покупки имущества. В качестве источника был указан РБК, а это далеко не желтая пресса, а вполне серьезное новостное издание.
В тот же день тему подхватил и Forbes. Материал вышел под заголовком (далее…)
Транзакционные письма — подтверждения регистрации, сброс пароля, чеки — кажутся простейшей задачей: подключил SMTP, вызвал send(), готово. Ровно до момента, когда письма начинают тихо улетать в спам Mail.ru и Яндекса, а ты не понимаешь почему: код не менялся, ошибок нет, письма «отправлены».
Качество требования во многом зависит от того, насколько ясно и полно оно сформулировано. Во многих Agile-проектах требования обычно описывают только основную логику работы системы. Варианты сценариев, исключения и ожидаемое поведение при их возникновении остаются неявными и обнаруживаются уже на этапах разработки или тестирования. В результате требования оказываются неполными, команде приходится многократно уточнять детали и тратить время на дорогостоящие переделки.
Мы перешли в опытно-промышленную эксплуатацию. До полноценного промышленного запуска было ещё далеко, но отчитываться уже было о чём. Основные контуры работали, подразделения начали собирать консолидированную потребность не в Excel, а в единой системе, пользователи осваивали новые процессы.
На управляющем комитете я именно об этом и рассказывал: что запущено, что работает, какие задачи ещё остаются. Спонсор выслушал и задал вопрос, который я помню почти дословно:
Мне понадобилось разобраться, что происходит на большом проекте внедрения: почему сроки едут и куда девается ресурс. Разработку вела внешняя команда, живьём я её не вёл и контекста не имел — на руках были только следы: трекер, вики, гит, списания времени.
Начал я с самого очевидного — померить, кто из аналитиков сколько делает. Провозился неприлично долго, получил красивые графики и всё выбросил. Дальше — почему выбросил и что нашлось, когда я перестал смотреть на людей.
Под «апельсином» в этой статье будем понимать не качество продукта целиком, а тот контур функциональной проверки, в котором пересекаются ручное и автоматизированное тестирование. На качество влияют разработчики, аналитики, менеджеры и вся продуктовая команда, но здесь речь пойдет о более узкой задаче: как двум способам проверки работать согласованно и давать команде единый, понятный сигнал о состоянии продукта.
Дисклеймер: статья для разработчиков уровня junior и middle, которые знакомятся с принципами чистого кода и SOLID. Примеры кода — PHP 8.1+.
Всем доброго дня! На связи Валевич Артем — тимлид в компании AGIMA. В первой части серии мы разобрали Single Responsibility Principle на кейсе системы отзывов и пришли к простому выводу:
SOLID нужен не для того, чтобы плодить классы ради классов.