Пикейное жилетство от ИТ
Sep. 11th, 2014 09:48 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
metaclassВ процессе срачей про вечные двигатели и обсуждения доисторических языков типа хаскеля с канадскими линуксоидами посетила следующая идея: проблемы с софтовой индустрией сводятся к трем вещам:
* Качественный софт на самом деле никому не выгоден, про что упоминает![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
vit_r
* Нормальных средств разработки UI как не было, так и нет. Просто нет, от слова совсем. Если сравнить достижения в разработке кишков софта и UI - небо и земля. Все потому, что UI надо разрабатывать, общаясь с пользователями, а еще лучше с психиатрами по эргономике, а асоциальным программистам это внутренний паук запрещает. И вообще психиаторы их всех в психушку сдадут, как только про удобный интерфейс гита узнают.
* Мейнстримные инструменты плохо умеют в целостность данных. Если бы не отцы-основатели реляционной модели, транзакции и ебические объемы данных у главных платежеспособных заказчиков типа банков, в которые ничто, кроме реляционных СУБД, толком не умеет - вся индустрия умерла бы давно, в мучениях.
* Качественный софт на самом деле никому не выгоден, про что упоминает
vit_r* Нормальных средств разработки UI как не было, так и нет. Просто нет, от слова совсем. Если сравнить достижения в разработке кишков софта и UI - небо и земля. Все потому, что UI надо разрабатывать, общаясь с пользователями, а еще лучше с психиатрами по эргономике, а асоциальным программистам это внутренний паук запрещает. И вообще психиаторы их всех в психушку сдадут, как только про удобный интерфейс гита узнают.
* Мейнстримные инструменты плохо умеют в целостность данных. Если бы не отцы-основатели реляционной модели, транзакции и ебические объемы данных у главных платежеспособных заказчиков типа банков, в которые ничто, кроме реляционных СУБД, толком не умеет - вся индустрия умерла бы давно, в мучениях.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2014-09-12 12:42 am (UTC)no subject
Date: 2014-09-12 12:51 am (UTC)если в прошлый раз меняли вон то, а в этот раз меняют вот это, то (не) нужно пересчитывать вон те поля.
число таких зависимостей растет как минимум как квадрат числа полей. описывать это в коде и уточнять у пользователя, что именно должно происходить - тоже растет быстро.
да. проблема тут не в 0мс на сервере на расчет, а в лютом бешеном росте и объёма кода, и числа нужных тестов. и примерно на 8 параметрах эта простая задача превратится в примерно непосильную.
плюс, автосдизайнить гуй под такую задачу - тоже становится крайне муторно
no subject
Date: 2014-09-12 01:07 am (UTC)Это (бизнес) логика
>если в прошлый раз меняли вон то, а в этот раз меняют вот это, то (не) нужно пересчитывать вон те поля.
Это (судя по всему) какие-то оптимизации.
Просто пересчитываейте все.
>число таких зависимостей растет как минимум как квадрат числа полей.
Число зависимостей прописано в ТЗ (или выводится из бизнес-логики). Программисту остается реализовать лишь одну ф-цю вида
User State -> (Business Logic )-> Business Result -> User State
где User State - это поля, чекбоксы и все остальное, что видет и трогает пользователь.
>примерно на 8 параметрах эта простая задача превратится в примерно непосильную.
Нет такой зависимости. Если у вас калбак_через_калбак (и мир не синхронный), то да. А в общем случае - нет. И это не общие, а конкретно ваши проблемы.
>автосдизайнить гуй
Это миф.
no subject
Date: 2014-09-12 08:53 am (UTC)> Это (судя по всему) какие-то оптимизации.
Не оптимизация, это подгон под ожидаемое поведение. Эвристика. Если я фиксирую сумму, потом двигаю первое слагаемое, а потом второе, то ожидается что прыгать-скакать должно третье. Тут поведение далеко за уровнем «onClick» и автогенераторов.
no subject
Date: 2014-09-12 03:48 am (UTC)no subject
Date: 2014-09-12 08:27 am (UTC)Но гуй сразу усложняется, поэтому, если простой пересчет по известным формулам - обычно значение, которое не надо пересчитывать - это то, что пользователь сейчас вводит, и те которые он ввел ранее, а следующие можно пересчитать. Если зависимости циклические, то так просто не получится, да.
no subject
Date: 2014-09-12 10:24 am (UTC)no subject
Date: 2014-09-12 10:44 am (UTC)Можно проверять всю форму сразу и потом рассказывать про ошибки. Но тогда заебёшься придумывать, как это внятно объяснить пользователю. Именно по-человечески, что вот это вот не подходит потому что то-то и то-то. Например, тут в одном популярном клиент-банке формочка полминуты обрабатывается, потом падает с несодержательным сообщением.
Можно опрашивать форму по таймеру или выделять связанные группы параметров, а сообщения об ошибках выдавать в специально отведеённом месте. Есть красные строчки - есть ошибка, чисто - всё нормально.
При этом если в приложении этих форм до ебени матери, всё это должно в едином стиле работать. Нельзя в одном месте окошки бросать, а в другом красные сообщения на форме рисовать. Проблемы, как всегда, в поиске баланса. А для этого надо пользователя чувствовать, смотреть на приложение его глазами.
no subject
Date: 2014-09-12 12:10 pm (UTC)Для поиска баланса вообще, имхо, самое главное, перестать считать пользователя идиотом. Человеку, который "подгоняет катушку индуктивности", про эти катушки по должности положено знать намного больше программиста и его программы. Так что первое, что ему надо - это просто понятный ввод и честное сообщение о его некорректности. В большинстве случаев, получив такое сообщение, он сам поймет в чем не прав.
Проблемы с интерфейсом часто начинаются тогда, когда программа вместо ввода-вывода пытается пересказать человеку всю свою тяжелую жизнь "именно по-человечески, что вот это вот не подходит потому что то-то и то-то". :)
no subject
Date: 2014-09-12 08:22 am (UTC)