Анти-критерии для софта и апи
Jun. 2nd, 2012 12:03 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВ процессе срачей с айседом пришел к выводу, что искать идеальные софты/либы/платформы бесполезно, практически все, что хоть как-то используется - достаточно пригодно для использования. Лучше выделить критерии для того, что использовать нежелательно:
С точки зрения пользователя:
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]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
denisioru:
- невозможность запустить несколько инстансов софтины одновременно. Да, год 2012й. Лом в жопу.
- изобретение собственных IP-протоколов. Прикладной софт должен работать по UDP или TCP. В редких очевидных случаях - RTMP и иже с ними. Люто, бешено лоботомировать.
- использоать API ОС для ресолвинга имён. За формирование руками DNS запросов и отправку их в неизвестном направлении - насылать нещадный кровавый понос.
- использование нестандартных диалогов открытия и сохранения файлов. Как наказание - выдать блок питания к ноуту юзера, несовместимый с розетками в офисе и дома.
- глюки на мультимониторных конфигурациях. За появление главного окна софтины, напополам распиленное между десктопами - выкалывать глаза.
- создание и использование временных файлов ВНЕ системного каталога TEMP - отправлять сортировать мусорные баки.
PS отbelnetmon:
- невозможность запустить софтину под уровнем пользователя , отличного от админа
- невозможность работы с UNC путями
- гадить во временную папку, которую пидор создал в корне системного диска (NVidia, Intel - привет)
С точки зрения пользователя:
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 от
denisioru:- невозможность запустить несколько инстансов софтины одновременно. Да, год 2012й. Лом в жопу.
- изобретение собственных IP-протоколов. Прикладной софт должен работать по UDP или TCP. В редких очевидных случаях - RTMP и иже с ними. Люто, бешено лоботомировать.
- использоать API ОС для ресолвинга имён. За формирование руками DNS запросов и отправку их в неизвестном направлении - насылать нещадный кровавый понос.
- использование нестандартных диалогов открытия и сохранения файлов. Как наказание - выдать блок питания к ноуту юзера, несовместимый с розетками в офисе и дома.
- глюки на мультимониторных конфигурациях. За появление главного окна софтины, напополам распиленное между десктопами - выкалывать глаза.
- создание и использование временных файлов ВНЕ системного каталога TEMP - отправлять сортировать мусорные баки.
PS от
belnetmon:- невозможность запустить софтину под уровнем пользователя , отличного от админа
- невозможность работы с UNC путями
- гадить во временную папку, которую пидор создал в корне системного диска (NVidia, Intel - привет)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-06-04 10:00 pm (UTC)Благородный дон хоть издали слышал слова Bridge Point, xtUML, Shlaer-Mellor?
Новые поколения с удивительным упорством изобретают велосипед на квадратных колёсах...
no subject
Date: 2012-06-05 07:56 am (UTC)И вообще, все технологии придумал еще ДаВинчи, а сейчас только придумали для них красивые названия.
Кстати, мне когда нужен новый класс (вид объекта) или метод (функция объекта), то я просто создаю его, задаю поведение и делаю для него визуальную форму. И совершенно не парюсь, как он будет в БД храниться, какие у него взаимосвязи с другими объектами. А вы предлагаете рисовать схему взаимосвязей, прописывать логику, а добавление к ней реализации поведения считаете великим достижением? Представляю вашу радость, когда в UML добавят возможность описывать формы GUI и макеты отчетов.
no subject
Date: 2012-06-05 09:05 pm (UTC)Не надо хвастаться своей серостью.
Тут тоже полно умельцев, криво "строящих системы" без понятия элементарных основ. В лучшем случае просто убивают в десять раз болше времени, чем нужно. В худшем - получают большую кучу говна.
Зато, все писатели, а не читатели.
А вы предлагаете
Не поняв даже элементарной информации, начинать спорить с померещившимся бредом - это, конечно, круто и создаёт чувство правоты в любой ситуации.
no subject
Date: 2012-06-06 06:54 am (UTC)no subject
Date: 2012-06-06 04:40 pm (UTC)Я удаляюсь. С теми, кто книжку сам прочитать не может, мне не по пути.
no subject
Date: 2012-06-06 04:42 pm (UTC)ИТ - гуманитарная дисциплина
Date: 2012-06-06 04:44 pm (UTC)Re: ИТ - гуманитарная дисциплина
Date: 2012-06-06 04:46 pm (UTC)Re: ИТ - гуманитарная дисциплина
Date: 2012-06-06 06:41 pm (UTC)Меня как-то с английского на русский перевели. Просто текстик. Но писателям это не интересно.
Re: ИТ - гуманитарная дисциплина
Date: 2012-06-07 06:21 am (UTC)