Pull to refresh

Comments 29

Был у нас один проект, когда требовалось реализовать систему управления безопасностью… После макетирования заказчик раскритиковал нашу систему, потому что она «слишком сложная», хотя имела большой потенциал к расширению и гибкость в использовании. После долгих и мучительных месяцев реализации «простой» системы, на испытаниях, заказчик поблагодарил нас не за выбранное решение, а за то, что кнопки были большие)) После этого к критике со стороны заказчиков я отношусь с определенной долей скептицизма))
Мне кажется, что это стандартная мантра при любом программировании: «вешай столько проверок на корректность данных, сколько можешь придумать». Каждая проверка, которую ты придумал, рано или поздно сработает — и спасет кучу твоего времени.
Нет, это плохая практика. Код всех функций превращается в бесконечные if'ы. На самом деле, во всем должны быть золотая середина — параноидальные проверки зло возможно ещё более худшее чем недостаток проверок. Важно точно определить все возможные диапазоны данных, все бизнес кейсы и места где проверки нужны и где они будут лишними.
Ну в моём Java-мире вешаются JSR-303 аннотации валидации, код выглядит очень красиво, пользователю приходят красивые сообщения. А всюду ниже сервисного слоя мы уже вешаем не ифы, а что-нибудь типа Objects.requireNonNull — чтобы приложение прямо валилось если до этого слоя каким-то образом дошли невалидные данные.
Я тоже живу в Java мире, но тут важен не мир, в избытке явно бессмысленных проверок все равно ничего хорошего нет. К тому же не всегда это хорошо когда из-за каждого чиха приложение валиться, были задачи когда требование были ровно противоположенными (например, была задача обработки логов посещений пользователей сайтов, когда клиент считал потерю/искажение 1% статистики допустимой, если приложение укладывалось по скорости обработки терабайт данных за указанное время и никогда чтобы не случилось не падало, там требовалось лишь сохранять варнинги при самом минимальном кол-ве проверок).
Ну соответственно те места, где падать не надо — ассертами не снабжаются. А вот как сделать нестрогую валидацию мне как-то непонятно. Как реализовали если не секрет? Всмысле как мерили что не более чем 1% данных невалиден?
Все просто, там была построчная обработка данных хитрой структуры, с одним try catch блоком на всю структуру, проверки были только на необязательные данные, падал любой exception (вроде numberFormatException), строка выкидывалась в отдельный error файл, информация об ошибке сохранялась в мапу <тип_ошибки, кол-во> и выполнение шло дальше. А error файл потом анализировался на то кто виноват: кривые данные или код.
На самом деле это как раз зависит от «мира», в котором вы работаете. Есть очень хорошее наблюдение Хоара:
Есть два метода создания программного обеспечения. Один из них — сделать программу настолько простой, чтобы стало видно, что в ней, очевидно, нет ошибок. И другой, сделать приложение таким сложным, чтобы стало видно, что в ней нет очевидных ошибок. Первый метод — гораздо сложнее.
(В оригинале: «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 индусов, чтобы быстро что-то состряпать не получается.
Java — исповедует первый подход, Форт — второй

А может наоборот? А то получается, что в Java очень простые программы.
Да, наоборот, конечно. Спасиба за замечание. Программы в Java обычно просты локально (и все методы на 2-3 строки покрыты тестами, да), но как вся эта структура работает в целом — не знает никто. Отсюда — куча странных backtrace'ов в разных местах (в том числе и на публичных web-сайтах). Причё зачастую вся беда — в проверке, которую можно просто убрать…
Согласен, код из бесконечных try-catch хоть и безопаснее, но представляет трудно отлаживаемую лапшу в которой трудно найти нужные концы.
Работаю удаленно и периодически бывает сложно понять задачи начальства, потому мы нашли хорошее решение — я открываю Google Docs с установленным плагином Plant UML Gizmo и проектирую там решение задачи. По окончанию, начальство (привет Влад) оценивает решение и вносит свои правки. Так может повторяться несколько раз, но в результате мы получаем единое понимание задачи и устраивающее нас обоих решение, что ни раз спасало от переписывания кода.

В статье забыли о двух важных составляющих проекта:
  1. Обратная связь — проект нужен для того, чтобы можно было общаться с заказчиком на одном языке, показывать ему понятные схемы, идеи, интерфейсы, а не для самолюбования
  2. Изменения — проект может и должен изменяться в процессе жизненного цикла ПО. Это не просто нормально, это необходимо. Проект для того и создается, чтобы изменять его, а не исходные коды. Ведь изменить проект гораздо проще и дешевле, чем изменить программу
От того, что систему придётся перепроектировать когда-то, вовсе не значит, что она была спроектирована отстойно. Системы проектируются под конкретные требования и то, что при изменении требований нужно перепроектировать систему является не просто статистически нормальным, а логически неизбежным. Вопрос лишь в том, насколько просто перепроектировать систему под вроде бы незначительные изменения требований, насколько эти изменения были вероятны в данной предметной области.
Мэтт Траут — Perl-разработчик, жалуется что проекты отстойные. ;0)))
Судя по вашему профилю — вы программист на nginx.
Получается?
UFO just landed and posted this here
У чела случился кризис, он написал, что все гавно. Искренне желаю ему включиться в процесс со свежими силами.
Есть такая штука ФФФ. Знал бы о ней автор оригинала, может, не писал бы таких статей.
А чем ФФФ поможет? Если вы занимаетесь ремеслом, то да ФФФ — работает. И неважно — клепаете вы под заказ сайты или кухни.

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

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

Такие дела. Нет, я не против ФФФ: кто-то же должен и кухни делать, не всем уникальные скульптуры ваять… но нужно чётко отдавать себе отчёт в том, что вы делаете, когда и почему…
Еще раз: статья — агрессивный поток сознания. Такие статьи пишешь, когда все идет не так и впадаешь во фрустрацию. Кризис. Похоже, автор оригинала налажал с планированием. Это его планирование отстой, а не мое или ваше. Пусть он классный программист, но тыкать другим в лицо — банально невежливо. Надо честно писать — я не понимаю планирование.
UFO just landed and posted this here
Не существует, поэтому давайте писать, что все говно.
UFO just landed and posted this here
Значит, у нас разное восприятие. Осмысленных выводов в разделе «Итого» я не вижу.
Существует!
Например один мой знакомый взялся внедрять ITIL в РФ
Он говорит что это серебряная пуля для Российского рынка.
;0))
Скоро выйдет закон по которому софт без ITIL будет запрещён?
Да вы что!!! ФФФ!!! Мэтт Траут потратил жизнь зря, он не читал «ЖЖ Товеровского», жаль его, дурака.
Проблема посыла «Ваше проектирование — отстой» в том, что он позволяет разработчику сказать «ну да, отстой; но все равно же будет отстой, что ни делай».
Я считаю вы путаете понятия. Выработанные требования практически всегда имеют изъяны. Это болезнь нашей индустрии.
А мое проектирование по требованиям достаточно хорошо, вот только требования могут измениться в любой момент и к этому стоит быть готовым.

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

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

Articles