metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2012-06-02 12:03 pm

Анти-критерии для софта и апи

В процессе срачей с айседом пришел к выводу, что искать идеальные софты/либы/платформы бесполезно, практически все, что хоть как-то используется - достаточно пригодно для использования. Лучше выделить критерии для того, что использовать нежелательно:

С точки зрения пользователя:
1) Отличие от общепринятых UI гайдлайнов. Например, розовый фон, красные кнопки, шрифт Comic Sans и выход из программы по кнопке F1.
2) Неадекватное поведение по отношению к другим программам и ОС. Например, встраивание хуков на системные действия или расширений в Explorer.
3) Издевательства над обычными средствами пользовательской интеграции - например, невозможность без вуду скопировать текст из программы в клипбоард, стандартным сочетанием кнопок или меню.
4) Наличие тупиков в Workflow, т.е. возможность обычными действиями зайти в программе туда, откуда обычными действиями уже не выйдешь (только снимать программу из диспетчера задач, kill и прочая)
5) Отсутствие прогресс-баров и прочей индикации выполнения при длительных операциях, отсутствие возможности их корректно прервать.

С точки зрения админства-деплоймента:
1) Неумение работать в многопользовательской среде/на терминальном сервере.
2) Неумение переживать xcopy-деплоймент и запускаться на чистой машине. В крайнем случае - должно быть документировано, что из окружения требуется (.net, жаба, переменные окружения)
3) Хардкодед пути в бинарниках - убивать нещадно.
4) Размещение своих либ/данных в общих папках, типа system32. Под линуксом - не считается, там за это пакетный менеджер, в идеале, отвечает и там принято всему софту гадить единообразно.

С точки зрения программизма:
0) ad-hoc программирование, без проектирования. Практически сразу заметно по структуре api.
1) Хардкодед значения, не являющиеся математическими константами. Пытать на дыбе авторов. Сюда же - хардкодед пути типа C:/Program Files или C:/openssl/etc (портированный софт
2) Тот же контекст, но в пределах ВСЕЙ ОС, а не только запущенного бинарника (Dragon Naturally Speaking и его апи - сука, ненавижу).
3) Не реентерабельные функции.
4) Отсутствие в АПИ для работы с внешними ресурсами явных пар типа Open/Close, Enter/Exit.
5) Невидимый/недокументированный/мутабельный глобальный контекст. Сюда же - использование такого контекста для работы с внешними ресурсами. Т.е. Open не возвращает "хендл для работы с ресурсом", а просто открывает где-то внутри его и все последующие функции его используют, неявно. Например, коннект к БД - один на всю программу. Или транзакция - одна на весь коннект к БД.
6) Отсутствие для значений getter там где присутствует setter. Забивать гвозди в голову за такое. Т.е. мы можем установить некий параметр, но не можем узнать его значение.
7) Случайное поведение API, не объяснимое переданными параметрами и документированным окружением. Обычно - следствие пункта 5 и общего рукожопия.
8) Использование GUI в явно не-гуишных либах. Последний пример - библиотека для работы с одной железякой, кидающая диалоговое окно при ошибке драйвера. Если ее использовать в фоновом сервисе - капец от входа.
9) Отсутствие в API возможности показать прогресс и прервать длительно выполняющиеся операции.
10) Отсутствие обработки ошибок вообще. УБИВАТЬ! УБИВАТЬ! УБИВАТЬ!
11) Обработка ошибок нормального workflow исключениями. Т.е. "попытка подключится к отсутствующему серверу" кидает исключение, хотя должна быть операция TryConnect
Хуже этого - только парсинг строк в простые значения без функции TryParse
12) Отсутствие логгинга. Сажать на кол, конечно же.
13) Отсутствие исходников - когда вышеописанное вылезет в полной мере, а автор окажется живущим половой жизнью с ежихой в ашраме Гуру Бхактиведанты Свами Прабхувады Ребе Короля Мошиаха - вам придется чинить либу самому.
За вас никто ничего чинить не будет - инфа 100%, еще ни одной либы не видел, где автор бы починил самоочевидную ошибку ранее чем через месяц после баг-репорта.

Т.е., если вы проектируете API - лучше сразу думайте, как его можно однозначно завернуть в красивый класс на c# или сделать обертку для него на хаскеле функциональном языке - резко становится очевидно, что можно делать и чего нельзя.

PS от [livejournal.com profile] denisioru:
- невозможность запустить несколько инстансов софтины одновременно. Да, год 2012й. Лом в жопу.
- изобретение собственных IP-протоколов. Прикладной софт должен работать по UDP или TCP. В редких очевидных случаях - RTMP и иже с ними. Люто, бешено лоботомировать.
- использоать API ОС для ресолвинга имён. За формирование руками DNS запросов и отправку их в неизвестном направлении - насылать нещадный кровавый понос.
- использование нестандартных диалогов открытия и сохранения файлов. Как наказание - выдать блок питания к ноуту юзера, несовместимый с розетками в офисе и дома.
- глюки на мультимониторных конфигурациях. За появление главного окна софтины, напополам распиленное между десктопами - выкалывать глаза.
- создание и использование временных файлов ВНЕ системного каталога TEMP - отправлять сортировать мусорные баки.

PS от [livejournal.com profile] belnetmon:
- невозможность запустить софтину под уровнем пользователя , отличного от админа
- невозможность работы с UNC путями
- гадить во временную папку, которую пидор создал в корне системного диска (NVidia, Intel - привет)

[identity profile] n0way.livejournal.com 2012-06-03 02:42 pm (UTC)(link)
"2) Неадекватное поведение по отношению к другим программам и ОС. Например, встраивание хуков на системные действия"

подразумевается что всегда есть альтернатива? это не так.

[identity profile] serbod.livejournal.com 2012-06-03 06:11 pm (UTC)(link)
Я бы не стал называть дураком человека, спроектировавшего и реализовавшего классическую опердень. Даже если она не особо удачна и перспективна.

[identity profile] creatorcray.myopenid.com (from livejournal.com) 2012-06-03 08:41 pm (UTC)(link)
Я так понимаю ребе имел в виду случай когда исключения показываются юзеру как "айбля шота упало" + стектрейс.
Юзер от такого писается и потом долго по ночам зовёт маму.

[identity profile] sbinq.livejournal.com 2012-06-03 10:20 pm (UTC)(link)
Такое делать понятно не стоит, особенно если "нету конекшна к серверу" это нормальная штатная ситуация.

Но как мне показалось речь идет не об этом, а именно о разнице в API - TryConnect() с boolean return value vs Connect() c соотв Exception-ом.
Понятно что и тот и другой вариант легко обработать (и нужно обработать в ситуации когда нет конекшна - это нормальный кейс) и показать юзеру какое-то внятное сообщение. Но таки чем вариант с return value удобнее exception-а все равно не понятно, даже учитывая что это нормальный workflow.
Edited 2012-06-03 22:33 (UTC)

[identity profile] sbinq.livejournal.com 2012-06-03 10:32 pm (UTC)(link)
Ребе, вы можете посоветовать куда посмотреть / что-нить почитать / итп чтобы подробно раскрыть тему чем же это так плохо? А то как-то неловко грузить вас глупыми вопросами :)

Я если что согласен что не стоит overuse exceptions, но именно описанная выше ситуация с Connect() кажется вполне себе нормальной, и если "нет конекшна" - это штатная ситуация, то никто не мешает обрабатывать соотв exception, как вы и написали - непонятно чем удобнее иметь отдельный метод без exception.

[identity profile] fraks-nsk.livejournal.com 2012-06-04 02:49 am (UTC)(link)
>> - создание и использование временных файлов ВНЕ системного каталога TEMP - отправлять сортировать мусорные баки.

Может не так категорично?
Например Firebird имеет в конфиге настройки где ему создавать временные файлы, и из соображений оптимизации работы дисков это может быть совсем не системный темп.

[identity profile] denisioru.livejournal.com 2012-06-04 03:35 am (UTC)(link)
Какой оптимизации?? Вы небось ещё и бакапите временные файлы чтобы оптимизировать работу интернета?

[identity profile] metaclass.livejournal.com 2012-06-04 03:55 am (UTC)(link)
Временные файлы используются для сортировок и создания индексов, их имеет смысл держать отдельно от системы и отдельно от БД - чтобы быстрее работало.
Впрочем, для СУБД, которая не умеет tablespace все это как мертвому припарка.

[identity profile] fraks-nsk.livejournal.com 2012-06-04 04:00 am (UTC)(link)
Оптимизация например такая - если винтов на сервере более одного то надо как минимум разнести БД и TEMP Firebird на разные диски. В каких-то случаях может быть актуальным сделать TEMP Firebird на электронном диске или еще что-то...
Edited 2012-06-04 04:02 (UTC)

[identity profile] metaclass.livejournal.com 2012-06-04 04:07 am (UTC)(link)
Насчет электронного диска - дичайшая содомия. Проще и дешевле же памяти докинуть.

[identity profile] fraks-nsk.livejournal.com 2012-06-04 04:14 am (UTC)(link)
Хм... так электронный диск в наше время наверное из основной ОЗУ и делается?
А про памяти докинуть - сам не вникал, еще не требуется, но слышал что бывают вопросы как заставить FB обожраться памяти, да использовать ее оптимально. Задав темп на эд - он по любому попадает в RAM, вне зависимости от каких-либо настроек по памяти.

Прочем пример конечно же не рядовой а из разряда хаков-извращений :)

[identity profile] fraks-nsk.livejournal.com 2012-06-04 04:15 am (UTC)(link)
Тем не менее это лучше чем ничего.

[identity profile] metaclass.livejournal.com 2012-06-04 04:21 am (UTC)(link)
Вот да, похоже это вопрос из разряда извратов.

[identity profile] denisioru.livejournal.com 2012-06-04 04:45 am (UTC)(link)
В пост врывается firebird? Причем здесь он?

[identity profile] denisioru.livejournal.com 2012-06-04 04:47 am (UTC)(link)
Для БД придуманы свои методы - вроде базы типа tempdb в mssql, которые можно переложить куда либо. Речь про прикладной софт.

[identity profile] metaclass.livejournal.com 2012-06-04 04:52 am (UTC)(link)
К нетривиальным местам для временных файлов.
Однажды была ситуация, когда Firebird не мог восстановить свою базу с бредовым сообщением, в итоге оказалось - не хватило места на диске С для временных файлов для восстановления индексов.

[identity profile] denisioru.livejournal.com 2012-06-04 04:55 am (UTC)(link)
Firebird в своем стиле ага. И кстати, причем тут нехватка места к путям для временных файлов? Запускайте его под другим юзером, для которого TEMP установлен в куда надо.

[identity profile] fraks-nsk.livejournal.com 2012-06-04 06:34 am (UTC)(link)
Сообщение было про то что бумага в принтере кончилась? Причем по-русски?

[identity profile] fraks-nsk.livejournal.com 2012-06-04 06:37 am (UTC)(link)
При том что требования к темпу у разных программ может быть разным и требования ко всем гадить строго в системный темп - бредовое.

[identity profile] metaclass.livejournal.com 2012-06-04 06:54 am (UTC)(link)
Что-то вроде "system call WriteFile failed" причем без указания имени файла вообще.
Влад, кажется, это уже пофиксил.

[identity profile] vp.livejournal.com 2012-06-04 07:44 am (UTC)(link)
+1
Обычно на сервере если делается раздел под временные файлы, дык все равно, что туда временное будет писаться, ФБ или системные временные файлы. Искусственно тут вводить еще какую-то настройку не вижу смысла.

[identity profile] vp.livejournal.com 2012-06-04 07:45 am (UTC)(link)
Ну дык мы вынесли системный темп на другой раздел? В чем проблема чтобы и ФБ его использовал?

[identity profile] fraks-nsk.livejournal.com 2012-06-04 08:32 am (UTC)(link)
Проблема в том что кроме FB может быть еще какой-нибудь активный юзатель темпа, и для безконфликтной работы их может быть желательно развести на раздельные девайсы.

[identity profile] serbod.livejournal.com 2012-06-04 08:43 am (UTC)(link)
Почитал.
Зря вы недооцениваете ORM, для учетно-бухгалтерских оперденей оно гораздо удобнее и продуктивнее, чем генерация классов по UML. В оперденях обычно работают с относительно простыми объектами из реального мира - документ, карточка товара, карточка клиента. Отчеты в основном сводятся к фильтрации и компоновке данных. А при просмотре больших списков используются курсоры и постраничный fetch. То есть, нет сложных select'ов, и проще генерировать SQL из объектов, чем объекты из схемы.

Зато в оперденях много логики (как круто звучит, а?) и она все время меняется. Для таких малых квантов данных очень дохрена логики. А логику проще, лучше и удобнее реализовывать на клиентской части, чем в хранимых процедурах. В идеале, использовать какой-нибудь скриптовый язык, чтобы можно было логику опердени писать и отлаживать прямо на коленке, не пересобирая весь проект. И не заморачиваться деталями работы хранилища - не те объемы.

Ваш подход эффективен только для специфичных систем, где очень много данных и мало логики - биллинг, например. А бухгалтерская опердень на хранимых процедурах - дикий оверкилл.

Page 4 of 6