ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Четверг
28 марта
560073 Топик полностью
Николай Коровин (16.11.2014 20:11, просмотров: 68) ответил Скрипач на А давай! 8)
Ну ОК... это будет долго, я надеюсь, что мне хватит остатков совести не полениться дописать до конца и дописать так, чтобы не быть понятым превратно. Пост первый из стапиццот. Принцип KISS часто понимают неправильно. Особенно это проявляется в том, что некий набор сущностей пытаются свести к одной универсальной сущности. Одна, всего одна! Что может быть проще? Однако, посмотрев на внутреннее устройство этой сущности и оценив сложность практического её использования, мы запоздало понимаем, что перехитрили сами себя. И если Вася ещё может пойти на попятный, то корпорация, где решение подписано у руководства -- всё, финиш, вся теперь заложник своего решения. "Король-то голый!" -- не крикнет никто. Есть такая пародия на известный советский лозунг -- "экономия должна быть экономной", то есть не приводить в итоге к потерям, превышающим объём "наэкономленного". Так вот, с KISS и всевозможными "упростителями разработки" это случается постоянно. Заблуждение первое: сведение всех архитектур к некоей виртуальной архитектуре, которая "одна и поэтому так проще". "Не работает" от слова "совсем". Сложность архитектуры, которая должна предусматривать всё -- ещё практически вообще не проблема по сравнению с тем, как эта архитектура себя чувствует, встречаясь с новыми технологиями. И как себя чувствует прикладное ПО на ней -- тоже. Разберём условный пример. Допустим, мы написали Универсальный Протокол Всех Мышей И Джойстиков. Они обмениваются XML-текстом, что стоило нам немалых усилий софта и железа, но зато мы можем сообщить и узнать любой параметр, как нынешний, так и будущий. Скажем, X diff, Y diff и Wheel Diff. Мы их запрашиваем, мышь отвечает, вместо байтов туда-сюда летают килобайты, в мыши контроллер греется, красота. Вдруг засада: появились мыши с силовым фидбэком! Ну у нас же универсальная архитектура, мы можем отправить в мышь Force Y Shift, мышь дёрнется в руке, изображая отдачу револьвера, красота! А теперь вопрос: а хоть одна игра это поддерживает? Нет, но сейчас будут! Теперь второй вопрос: а что мешает, при написании этих игр, взять и использовать вместо обычного бинарного протокола 1.0, в котором есть X, Y и колесо, обычный бинарный протокол 1.1, в котором есть X, Y, колесо и отдача, раз прикладное ПО-то всё равно нуждается в адаптации, чтобы была поддержка? Ничего. Тогда третий вопрос: а зачем мы городили весь этот огород с виртуализацией "до уровня текста"? Разберём живой пример. Появление e-ink никак не помогло ведроиду, потому что понятия "частичного обновления экрана", "быстрого обновления экрана" и "полного обновления экрана", ставшие вдруг разными в пику всей привычной вековой картине разработки GUI, никто не догадался предусмотреть ни в графических АПИ системы (настолько универсальной виртуальная архитектура быть уже не может), ни в прикладном ПО, а если каждый раз делать полное обновление -- eink тогда не eink, а дерьмо какое-то. Вот и остаются книжки "вещью в себе", а попытки сделать смартфон на e-ink пока сливаются с оглушительным гороховым треском. Разберём мёртвый пример. Телефон, который "просто звонит" и имеет алфавитно-цифровой дисплей, мог бы использовать ту часть ПО смартфона, которая могла бы работать чисто консольно: email-клиент, jabber-клиент, voIP-клиент. Сейчас это не актуально, поэтому пример и "мёртвый", но показательности ему это не убавляет: представим себе, что нам нужно охватить нашей ОС и этот сегмент рынка. Какие у нас шансы сделать простой виртуализацией архитектуры Siemens me45 и Nokia e90 "прозрачно одинаковыми" для прикладного ПО? Нулевые. Запомним эти примеры: при некоторой абстрактности, перемыть им косточки нам ещё придётся.