December 13th, 2011

404

Боевые гаремники

Кстати, этот жанр вполне себе имеет массу удачных представителей, если вспомнить внимательно. Первый яркий представить - SMJ. С тех пор этот жанр мирно существует, иногда давая замечательные вещи.
404

Есть ли жизнь за ТЗ

В качестве максимы я слышал утверждение, мол, что "хорошо написанное ТЗ полностью определяет качество результата". И что (при условии выполнения ТЗ) любые проблемы - это признак кривого ТЗ (или непокрытия им части условий).

С одной стороны - да. С другой... Одно и то же ТЗ можно реализовать очень по-разному. Это "по разному" во-первых описывает поведение в неописанных в ТЗ ситуациях. Например, в ТЗ написано "при отклонении от success datapath приложение должно вывести на stderr сообщение об ошибке, информацию об условиях возникновения, номер строки исходного кода, где возникла ошибка; скинуть буфферы и закрыть хэндлер файла, в который осуществлялся вывод, завершить программу с кодом возврата, перечисленным в файле с кодами возврата, уникальными для каждой ошибки; коды ошибок должны быть отрицательными для критических ошибок, связанных с потерей данных, положительными для ошибок, которые не привели к потере данных.

Достаточно обстоятельно? Заметим, в ТЗ удачно обойдена проблема "а у нас такого типа ошибки в ТЗ не было". ТЗ есть? Есть. Достаточно ли этого ТЗ для написания (этой части) программы? Да.

Есть ли в этом ТЗ свобода сделать херню? Есть! Например, программист может написать класс/функцию для вывода сообщений, обвёрнутых в эксепшн. И что эта функция будет делать при ошибке вывода в stderr? Правильно, зациклится и упадёт с переполнением стека. А если даже не упадёт, то, не выведя сообщения (к этому претензий нет), закроет stderr (упс...) и выйдет с уникальным кодом возврата.

А как же flush для исходного файла? А там ценная информация была, а её того не того, не сохранили...

Кто виноват? Автор ТЗ? Нет, он описал что нужно сделать? Программист? Нет, он сделал что сказали.

В таких местах есть только одно решение. Это не увеличение детализации ТЗ (путь совершенно бесперспективный, потому ТЗ, покрывающее все случаи и описывающее всё, что должна делать программа, можно смело кормить компилятору и после небольших фиксов в запятых и скобках для устранения неоднозначностей, считать своим собственным решением). Это его _уменьшение_.

Вышенаписанный пример должен выглядеть так:

При ошибке нужно вывести сообщение на stderr, по возможности подробное, уникальный код возврата (минус для фатальных, плюс для нефатальных) и обязательно сохранить всё, что можно сохранить без порчи данных.

А может даже и так:
При ошибке ругаться кодом и текстом, скидывать буфферы.

Каждый последующий вариант накладывает на программистов всё больше и больше свободы реализации с всё большим уровнем "поразумевания". И он же всё больше и больше полагается на адекватность программиста, на то, что он чувствует как надо делать вещи правильно. И когда он делает неправильно, то кто виноват?

... ответ - команда. Виноват и тот, кто писал ТЗ, не понимая, что программист его не поймёт и сделает не так. Виноват и программист, который а) не почувствовал в этом месте что-то странное и не уточнил (с занесением в хотя бы сопроводительную документацию, а лучше прямо в ТЗ) б) сделал криво.

Именно потому программирование - не "code monkey job". Если бы ТЗ состояло из псевдокода, то работа программиста была бы подобна работе девочки-перфористки, которая по рукописному исходнику набирает на перфораторе программу - ноль интеллекта, максимум усидчивости и внимательности.

Но реально - программист ДОЛЖЕН решать для себя как сделать ту или иную вещь. Часть вещей сам, часть, если не видит однозначного решения (или не видит устраивающего на 100% решения) - с коллегами.

Причём в реальной жизни уровень принимаемых программистом решений много выше, чем в примере выше (то что я написал выше даже не обсуждается, это очевидно программистская вотчина). Например, тз может звучать так:

делаем по принципу "easy fall, конфиги в /etc/app/app.conf, логи через logrotate, (бла-бла-бла-тут-алгоритм), результат скидываем в БД". Заметим, тут даже не сказано, что логи надо в /var/log писать. И не сказано, что IP-адрес БД находится в конфиге. Более того, тут не сказано, что делать, если БД вернула нам ошибку или у нас структура БД отличается от ожидаемой нами при UPDATE. Всё это - на совести программиста.