Ваше проектирование – отстой

[@yTko]

[@Kolyuchkin]

Был у нас один проект, когда требовалось реализовать систему управления безопасностью… После макетирования заказчик раскритиковал нашу систему, потому что она «слишком сложная», хотя имела большой потенциал к расширению и гибкость в использовании. После долгих и мучительных месяцев реализации «простой» системы, на испытаниях, заказчик поблагодарил нас не за выбранное решение, а за то, что кнопки были большие)) После этого к критике со стороны заказчиков я отношусь с определенной долей скептицизма))

[@giffok]

Мне кажется, что это стандартная мантра при любом программировании: «вешай столько проверок на корректность данных, сколько можешь придумать». Каждая проверка, которую ты придумал, рано или поздно сработает — и спасет кучу твоего времени.

[@terryP]

Нет, это плохая практика. Код всех функций превращается в бесконечные if'ы. На самом деле, во всем должны быть золотая середина — параноидальные проверки зло возможно ещё более худшее чем недостаток проверок. Важно точно определить все возможные диапазоны данных, все бизнес кейсы и места где проверки нужны и где они будут лишними.

[@asm0dey]

Ну в моём Java-мире вешаются JSR-303 аннотации валидации, код выглядит очень красиво, пользователю приходят красивые сообщения. А всюду ниже сервисного слоя мы уже вешаем не ифы, а что-нибудь типа Objects.requireNonNull — чтобы приложение прямо валилось если до этого слоя каким-то образом дошли невалидные данные.

[@terryP]

Я тоже живу в Java мире, но тут важен не мир, в избытке явно бессмысленных проверок все равно ничего хорошего нет. К тому же не всегда это хорошо когда из-за каждого чиха приложение валиться, были задачи когда требование были ровно противоположенными (например, была задача обработки логов посещений пользователей сайтов, когда клиент считал потерю/искажение 1% статистики допустимой, если приложение укладывалось по скорости обработки терабайт данных за указанное время и никогда чтобы не случилось не падало, там требовалось лишь сохранять варнинги при самом минимальном кол-ве проверок).

[@asm0dey]

Ну соответственно те места, где падать не надо — ассертами не снабжаются. А вот как сделать нестрогую валидацию мне как-то непонятно. Как реализовали если не секрет? Всмысле как мерили что не более чем 1% данных невалиден?

[@terryP]

Все просто, там была построчная обработка данных хитрой структуры, с одним try catch блоком на всю структуру, проверки были только на необязательные данные, падал любой exception (вроде numberFormatException), строка выкидывалась в отдельный error файл, информация об ошибке сохранялась в мапу <тип_ошибки, кол-во> и выполнение шло дальше. А error файл потом анализировался на то кто виноват: кривые данные или код.

[@khim]

На самом деле это как раз зависит от «мира», в котором вы работаете. Есть очень хорошее наблюдение Хоара:

Есть два метода создания программного обеспечения. Один из них — сделать программу настолько простой, чтобы стало видно, что в ней, очевидно, нет ошибок. И другой, сделать приложение таким сложным, чтобы стало видно, что в ней нет очевидных ошибок. Первый метод — гораздо сложнее.
(В оригинале: «There are two ways of constructing a software design: one way is to make it so simple that there are obviously no deficiencies; the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult»)

Java — исповедует первый подход, Форт — второй. Подход к ошибкам в Форте концептуально прост, но вот привыкнуть к нему непросто: GIGO стоит во главе всей идеологии. Если вызывающая процедура может сделать проверку сама — то, стало быть, она и должна делать проверку. Если вы вызвали функцию с неверными параметрами — ССЗБ, не ждите, что вам кто-то плохое слово скажет, всё будет отлично, просто результат вы получите даже и близко непохожий на ожидаемый. Перемножить два указателя на строки? Что может быть проще! Какие-то ошибки порождаются только функциями, общающимися с внешним миром (скажем функция чтения из файла, так как заранее сказать — будет на диске ошибка или нет нельзя).

Удивительным образом подобное «программирование по бразильской системе» тоже вполне себе работает и приводит к написанию очень компактных, быстрых и не требующих много ресурсов программ — но при этом имеет проблемы с масштабированием… Примечание, увы, оказывается правдой: программы на Форте, как правило, имеют очень мало ошибок (а часто — и не имеют их вообще), но так как метод «тяп-ляп и в продакшн» недоступен, то нанять 100500 индусов, чтобы быстро что-то состряпать не получается.

[@terryP]

Java — исповедует первый подход, Форт — второй

А может наоборот? А то получается, что в Java очень простые программы.

[@khim]

Да, наоборот, конечно. Спасиба за замечание. Программы в Java обычно просты локально (и все методы на 2-3 строки покрыты тестами, да), но как вся эта структура работает в целом — не знает никто. Отсюда — куча странных backtrace'ов в разных местах (в том числе и на публичных web-сайтах). Причё зачастую вся беда — в проверке, которую можно просто убрать…

[@Idot]

Согласен, код из бесконечных try-catch хоть и безопаснее, но представляет трудно отлаживаемую лапшу в которой трудно найти нужные концы.

[@Delphinum]

Работаю удаленно и периодически бывает сложно понять задачи начальства, потому мы нашли хорошее решение — я открываю Google Docs с установленным плагином Plant UML Gizmo и проектирую там решение задачи. По окончанию, начальство (привет Влад) оценивает решение и вносит свои правки. Так может повторяться несколько раз, но в результате мы получаем единое понимание задачи и устраивающее нас обоих решение, что ни раз спасало от переписывания кода.

В статье забыли о двух важных составляющих проекта:

1. Обратная связь — проект нужен для того, чтобы можно было общаться с заказчиком на одном языке, показывать ему понятные схемы, идеи, интерфейсы, а не для самолюбования
2. Изменения — проект может и должен изменяться в процессе жизненного цикла ПО. Это не просто нормально, это необходимо. Проект для того и создается, чтобы изменять его, а не исходные коды. Ведь изменить проект гораздо проще и дешевле, чем изменить программу

[@VolCh]

От того, что систему придётся перепроектировать когда-то, вовсе не значит, что она была спроектирована отстойно. Системы проектируются под конкретные требования и то, что при изменении требований нужно перепроектировать систему является не просто статистически нормальным, а логически неизбежным. Вопрос лишь в том, насколько просто перепроектировать систему под вроде бы незначительные изменения требований, насколько эти изменения были вероятны в данной предметной области.

[@tumikosha]

Мэтт Траут — Perl-разработчик, жалуется что проекты отстойные. ;0)))

[@zdm001]

Судя по вашему профилю — вы программист на nginx.
Получается?

[@igrishaev]

У чела случился кризис, он написал, что все гавно. Искренне желаю ему включиться в процесс со свежими силами.
Есть такая штука ФФФ. Знал бы о ней автор оригинала, может, не писал бы таких статей.

[@khim]

А чем ФФФ поможет? Если вы занимаетесь ремеслом, то да ФФФ — работает. И неважно — клепаете вы под заказ сайты или кухни.

А вот если вы делаете что-то новое… тут ФФФ не работает. Посмотрите на рынок операционок к примеру. Есть там работающие по принципе ФФФ компании? Да — есть: Ubuntu, FirefoxOS, etc. Полнейшие аутсайдеры без каких-либо шансов куда-то продвинуться. Причём появились они как раз когда iOS и Android, сырые, косые и убогие пришли и уничтожили Symbian, Palm, BlackBerry…

Хороший пример представляет из себя также Android и ChromeOS: команда Android'а — работает «с надрывом», часто на праздниках и выходных, при этом ChromeOS — «ФФФ как он есть». Ну и? На чём там у нас Pixel C? А почему — как вы думаете? Одна компания, сравнимые по качеству инженеры, etc.

Такие дела. Нет, я не против ФФФ: кто-то же должен и кухни делать, не всем уникальные скульптуры ваять… но нужно чётко отдавать себе отчёт в том, что вы делаете, когда и почему…

[@igrishaev]

Еще раз: статья — агрессивный поток сознания. Такие статьи пишешь, когда все идет не так и впадаешь во фрустрацию. Кризис. Похоже, автор оригинала налажал с планированием. Это его планирование отстой, а не мое или ваше. Пусть он классный программист, но тыкать другим в лицо — банально невежливо. Надо честно писать — я не понимаю планирование.

[@igrishaev]

Не существует, поэтому давайте писать, что все говно.

[@igrishaev]

Значит, у нас разное восприятие. Осмысленных выводов в разделе «Итого» я не вижу.

[@tumikosha]

Существует!
Например один мой знакомый взялся внедрять ITIL в РФ
Он говорит что это серебряная пуля для Российского рынка.
;0))

[@VolCh]

Скоро выйдет закон по которому софт без ITIL будет запрещён?

[@zdm001]

Да вы что!!! ФФФ!!! Мэтт Траут потратил жизнь зря, он не читал «ЖЖ Товеровского», жаль его, дурака.

[@lair]

Проблема посыла «Ваше проектирование — отстой» в том, что он позволяет разработчику сказать «ну да, отстой; но все равно же будет отстой, что ни делай».

[@overmes]

Я считаю вы путаете понятия. Выработанные требования практически всегда имеют изъяны. Это болезнь нашей индустрии.
А мое проектирование по требованиям достаточно хорошо, вот только требования могут измениться в любой момент и к этому стоит быть готовым.

И помните — выпустить что-то отстойное на 100% лучше, чем не выпустить вообще ничего.

Это похоже на «Лучше сделать и жалеть, чем не сделать и жалеть». Оба выражения лишь утешения для людей, которые ошиблись. Не стоит обманывать себя и злоупотреблять ими.