amarao (amarao_san) wrote,
amarao
amarao_san

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • systemd-networkd, netlink и arp флуд

    Нереально странный баг пофикшен с помощью eBPF затычки. Для меня большой неожиданностью является реакция на него.…

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 13 comments

  • systemd-networkd, netlink и arp флуд

    Нереально странный баг пофикшен с помощью eBPF затычки. Для меня большой неожиданностью является реакция на него.…

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…