Bug driven design
Есть у программистов такой шуточный термин - Bug driven development. Это когда вся разработка сводиться к непрерывному обнаружению и исправлению нескончаемого потока глюков. Дословно - разработка, ведомая багами. И если термин и шуточный, то ситуация, которую он описывает, абсолютно не смешная. Однако согласно закону Мэрфи, нет такой плохой ситуации, которая не может стать ещё хуже. *здесь должен быть звук фанфар* Представляю вам проектирование, ведомое багами. Это когда вы ещё не начав писать код уже пытаетесь упорядочить и обуздать поток глюков. И это хуже чем это звучит.
К чему всё это? Вот байка.
Предыстория. Дано: широко известная в узких кругах операционная система, Java 1.6, сертификация уровня 2. Проблема: Начиная с релиза 25 что ли, в Java 1.6 под Unix есть баг, исправленный только в 1.7 и связан он с рассинхронизацией координат окна по мнению JVM с его истинным положением на экране. Как результат, после изменения состояния окна все выпадающие элементы - меню, списки, подсказки - начинают резко глючить до неюзабельного состояния. Решение - всё можно вернуть в норму, если пустить поток, который будет периодически переписывать координаты окна из нативного уровня в JVM, благо обёртку над Xlib уже сделали за нас. "Отрицательные явления имеют тенденцию к увеличению" - закон Уинна. Вышла новая, необратимо улучшенная версия системы. И за многими улучшениями, как это не странное признать, она лучше старой. Но дьявол кроется в деталях. В новой версии обновлён WindowManager - компонент управления окнами - и да, он сломан. Как бы ты не двигал окно, в какой бы момент не запросил его координаты, тебе скажут, что окно всё на том же месте, где появилось и ни на писель не сдвинулось. Даже xprop говорит, что окно не передвинуто, хотя это не так. Ой.
Байка. На прошедшей недели Фэйнс решал непростую задачу: нужно оповещать разнородные компоненты, отображающие одни и те же данные, если эти данные меняются. И эта задача сложнее, чем кажется. Фэйнс, пораскинув мозгами, решил спросить совета на конкретные вопросы у коллеги. Но когда он рассказал ему всё, с чем приходится иметь дело, тот спросил только одно - а как ты вообще до такого докатился? А действительно, как? Почему вообще возникла необходимость синхронизировать разнородные компоненты, ведь в оригинале данные были привязаны к своему компоненту и должны вообще были отображаться в одном экземпляре. Ну ответ прост - так описал аналитик. А что конкретно его неустраивало в предложенном варианте? А ничего, просто не билось с концепцией дизайнера. Ммм, открываем концепт. Ага, дизайнер считает что тематически разные данные должны быть разделены друг от друга. И если пара разных объектов ссылаются на третий ни из чьей тематики, то он должен открываться в модальном окне без покидания пространства. Логика есть. Хм, но что-то тут не так. А вот вообще странно - выбор этого элемента можно сделать комбо-боксом, он простой, зачем ему модельное окно? Погодите-ка, да вы меня троллите! Да! Ни на одном макете нет ни одного выпадающего элемента. И меню нет. И подсказки захардкожены на форму! RUFKM?! Да, раздельные пространства с предоткрытыми всеми возможными вариантами сделаны чтобы не использовать командное или навигационное меню, потому что не использовать меню. Модальные диалоги выбора чтобы не использовать комбо-боксы! Аааа! Вот она, классика bug driven design - решать задачи, которые не возникли бы при условии "чистого старта".
И если кто-то хочет спросить - да, было совещание на котором выбрали стек для разработки; нет, swing выбрали за "ценник" и знали о "возможных рисках".
К чему всё это? Вот байка.
Предыстория. Дано: широко известная в узких кругах операционная система, Java 1.6, сертификация уровня 2. Проблема: Начиная с релиза 25 что ли, в Java 1.6 под Unix есть баг, исправленный только в 1.7 и связан он с рассинхронизацией координат окна по мнению JVM с его истинным положением на экране. Как результат, после изменения состояния окна все выпадающие элементы - меню, списки, подсказки - начинают резко глючить до неюзабельного состояния. Решение - всё можно вернуть в норму, если пустить поток, который будет периодически переписывать координаты окна из нативного уровня в JVM, благо обёртку над Xlib уже сделали за нас. "Отрицательные явления имеют тенденцию к увеличению" - закон Уинна. Вышла новая, необратимо улучшенная версия системы. И за многими улучшениями, как это не странное признать, она лучше старой. Но дьявол кроется в деталях. В новой версии обновлён WindowManager - компонент управления окнами - и да, он сломан. Как бы ты не двигал окно, в какой бы момент не запросил его координаты, тебе скажут, что окно всё на том же месте, где появилось и ни на писель не сдвинулось. Даже xprop говорит, что окно не передвинуто, хотя это не так. Ой.
Байка. На прошедшей недели Фэйнс решал непростую задачу: нужно оповещать разнородные компоненты, отображающие одни и те же данные, если эти данные меняются. И эта задача сложнее, чем кажется. Фэйнс, пораскинув мозгами, решил спросить совета на конкретные вопросы у коллеги. Но когда он рассказал ему всё, с чем приходится иметь дело, тот спросил только одно - а как ты вообще до такого докатился? А действительно, как? Почему вообще возникла необходимость синхронизировать разнородные компоненты, ведь в оригинале данные были привязаны к своему компоненту и должны вообще были отображаться в одном экземпляре. Ну ответ прост - так описал аналитик. А что конкретно его неустраивало в предложенном варианте? А ничего, просто не билось с концепцией дизайнера. Ммм, открываем концепт. Ага, дизайнер считает что тематически разные данные должны быть разделены друг от друга. И если пара разных объектов ссылаются на третий ни из чьей тематики, то он должен открываться в модальном окне без покидания пространства. Логика есть. Хм, но что-то тут не так. А вот вообще странно - выбор этого элемента можно сделать комбо-боксом, он простой, зачем ему модельное окно? Погодите-ка, да вы меня троллите! Да! Ни на одном макете нет ни одного выпадающего элемента. И меню нет. И подсказки захардкожены на форму! RUFKM?! Да, раздельные пространства с предоткрытыми всеми возможными вариантами сделаны чтобы не использовать командное или навигационное меню, потому что не использовать меню. Модальные диалоги выбора чтобы не использовать комбо-боксы! Аааа! Вот она, классика bug driven design - решать задачи, которые не возникли бы при условии "чистого старта".
И если кто-то хочет спросить - да, было совещание на котором выбрали стек для разработки; нет, swing выбрали за "ценник" и знали о "возможных рисках".