Кстати, отдельно по поводу "(Моего\Вашего\Этого) Компьютера", а также, несколько, «Пуск», а более всего, таких наименований, как "Центр обновлений" или "Служба сетей":
Название «Компьютер» хоть и логичен для названия точки входа, но не переставало озадачивать примерно так: «Но я же уже за компьюером!», «Компьютер в компьютере?», «Мне покажут железо?» — слишком уж общо и непонятно.
Также и «Пуск», который ничего не пускал, а предоставлял доступ к программам и последующим настройкам программ и ОС.
Претензия к «Цетрам» и «Службам», в первую очередь, в избыточности, более долгому визуальному поиску (особенно при одинаковых или похожих иконках). Ведь, если показывается список Служб, то пункты «служба А» и «служба Б» лучше просто именовать «А» и «Б».
Также не люблю местоимения вообще.(далее ИМХО) Местоимение «мой» создает неприятное впечатление опекунства, будто посадили в песочницу и надписали, ведь иначе не разберусь (т.к. подписывал «моим» не я)! А «Ваш» — похожее ощущение: «Ваша овсянка, сэр». Помимо этого, разные стили в разных приложениях запутывают: «моё» — это моё, или же МС или Гугла? Т.е. в целом создается впечатление искуственного разделения «это твоё, а это — моё!»
Местоимения «этот» и «тот» вообще еще более лишены смысла и дезориентируют (если это «этот», то ведь должен быть и «тот», но где он?!)
Поэтому, на мой взгляд, лучше всего отказаться от обезличенных местоимений и, либо их не использовать вообще, либо использовать имена («Компьютер Васи», например). Также, давать имена программам — тоже неплохая идея, хоть и слегка намекает на Скайнет.
> Даже в фильмах детективы иногда умудряются рассмотреть номер автомобиля на кадре с камеры наблюдения, «приблизив» фотографию до предела. И не только номер автомобиля. Тут всё ограничено фантазией и совестью режиссёра и сценариста. Они могут приблизить фотографию ещё больше — и разглядеть отражение преступника в зеркале заднего вида или даже в отполированной металлической головке болта, которым крепится номерной знак.
как в этой связи не вспомнить http://images-cdn.9gag.com/photo/2078832_700b.jpg?
опять же вопрос — как именно он это делает. Есть опасность вернуть неверные данные. И опять же, появляется необходимость пробрасывания и обработки исключений выше — иногда это излишне.
Если вылетает SocketException в результате того, что я дёрнул проводок — ваше приложение падает?
Не намного хуже того, если приложение не падает, а назойливо жалуется, ничего не делает или вообще виснет, пока не вдёрнете проводок на место — вот что имелось ввиду, по-моему.
Про это целую статью накатать можно
Так вся статья о том, насколько и в каких случаях приложение должно быть параноидальным — городить ли проверки на каждую функцию, или «пусть падает» до более общей проверки?
Потому что рискуем зажевать неожиданное исключение и создать ложное впечатление правильности работы юнита (класса, слоя) и долго потом искать реальную причину неправильного поведения системы. Более правильный способ — ловить наиболее конкретизированные исключения, с индивидуальной обработкой (и индивидуальным логгированием), за, возможно, исключением случая, когда неожиданное исключение долетает до пользователя.
Для таких случаев можно использовать catch (Exception ex) на самом верхнем уровне, чтобы пользователю не показывалось 404 и 500, но это очень специфичное исключение. Например, эта же конструкция на нижних уровнях — уродлива.
Урок 1. Не всякое исключение обязательно ловить и пробрасывать собственное — в некоторых случаях «системное» исключение будет не менее информативно, а кол-во кода и классов собственных исключений будет меньше. И еще, нет ничего отвратительнее catch(Exception ex)
Урок 2. Да, исключения бывают штатными и неожиданными, но тут разница только в том, что отсутствие обработки первых — позорно, а вот вторые нужно «почти» не обрабатывать (в гуёвом приложении можно выкинуть окошко «Извините, но что-то плохое случилось», в headless — как минимум, расписать подробно в лог, что мы пытались сделать)
Урок 3. Все сводится к холивару «fail-fast vs defaults», и где лучше исключение, а где — пустые данные — вопрос вечно открытый. А на самом деле, в Java явно недостает конструкции?.. чтобы вместо if(a!=null&&a.getB()!=null&&a.getB().getC()!=null) писать if(a?.getB()?.getC()!=null)
что он упал с NPE на 4ой строке. А почему? да хз, то ли наgetContact(), то ли .getEmail(), а может и на getText(). В страшном коде с кучей проверок мы хотя бы сможем узнать, что у нас null.
Во-вторых, приложение получается «бибикающим», вместо работающего (помните программы-шутки из 90х годов, которые заставляли нажимать ОК 100 раз?)
И в-третьих, GUI.alert по-хорошему не должен быть доступен отовсюду: изолированный код — хороший код (см. закон Деметры)
Да, схема называется «одноразовые лица»: один предложил хрень, ее приняли, лицо дискредитировалось, потом напоказ выставляется другое лицо… а хрень-то прорастает
Я ленив. ОЧЕНЬ ленив. Особенно писать тесты. Особенно в соответствии с TDD: т.е. до того, как напишу код, до того, как пойму, что вообще буду писать. Особенно при том, что в процессе разработки я активно перемалываю рефакторю код. Инлайн\выделение методов, свертывание и развертывание объектов (в последовательности и более простые структуры), перенос-переименование классов и т.д. согласно ходу мыслей — настолько, что уже через час код может драматически измениться.
И в этой связи написание\изменение тестов может практически остановить этот процесс. А потому я и не пытаюсь следовать заповедям TDD.
И все же я пишу тесты. Это происходит тогда, когда мне необходимо убедиться, что мои предположения в коде верные, а защитные механизмы (типа assert) слишком дороги, чтобы ими присыпать функции, словно снегом. Мне тесты нужны, чтобы или выделить маленькую часть и проверить те детали реализации, которые уже не различает замыленный глаз (выход за пределы массива, переполнение или потеря точности нулевые указатели и т.д.). Т.е. тестом я поднимаю не все приложение, а беру нашпигованный логикой сервис, эмулируя окружение и возможные граничные ситуации, и смотрю, насколько хорошо класс с ними справляется. Я пишу тесты, чтобы ничего не забыть.
Или наоборот, я пишу тесты не на каждый объектно-функциональный чих, а на длинную связку процессов, таким образом повышая вероятность отсутствия (но, конечно же, не полное отсутствие!) ошибок — т.е. если результат сложного процесса корректен, то, скорее всего, корректна также и работа его составляющих.
Иногда я пишу тесты для того, чтобы понять, что и как я буду кодить — что уже ближе к правильному подходу. Иногда проще написать такой тест, который мне покажет, как написать гибкий, расширяемый, а главное — тестируемый класс. Он же мне поможет избежать создания как и чересчур зависимого класса, так и слишком универсального — конечно, для этого тест должен моделировать более-менее правдоподобную ситуацию (или несколько)
Такой подход позволяет уделять меньше времени написанию тестов только ради покрытия, а также меньше потея из-за мелочей, держа в уме только примерный алгоритм, без деталей — а уж детали выплывут при запуске тестов, и останется только их исправить, чтобы все в конце концов работало, а силы ушли на обдумывание решений, а не на реализацию деталей.
Таким образом, на выходе получаем достаточно надежный код, который будет в большинстве случаев работать, при минимуме тестов и утечкой сил на их написание, а также минимум адаптации старых тестов к новому (чит. сырому) коду, а потому легче не только писать тесты, но и адаптировать их, усложнять и лучше проверять основной код.
Это особенно важно, когда нет времени\сил\желания на скрупулезность (ведь должны быть готово уже вчера!), ведь тестирование слилось в процессе с разработкой — ни до, ни после, а именно во время (да и вовремя) разработки, при этом свежая функциональность работает в большинстве очевидных сценариев.
И только когда основная часть выверена, тогда можно заниматься повышением покрытия сверх 80%, описывая никому не нужные тесты, просто ради того, чтобы были, а также проверяли корректность простых ситуаций.
> Если творится абсурд, надо его всячески поддерживать и подводить ситуацию к тому, чтобы утаить абсурдность стало невозможно.
И тогда абсурд станет нормой, проходили уже. Лет 5-10 назад писали же, что, мол, не будут ничего блокировать, потому что это абсурд. А теперь вспомните, сколько раз блокировали и Википедию, и Гитхаб, и многие другие.
Теперь же речь идет о блокировке всех неугодных сайтов, с запретом технологий типа vpn и «интернета поверх интернета», которые В ТОМ ЧИСЛЕ могут помочь с обходом блокировок, но НЕ ЯВЛЯЮТСЯ ИНСТРУМЕНТОМ для этого, об запрете\ослаблении шифрования, а также MitM-госсертификатах.
Хотите больше абсурда? Пожалуйста: «наверхну» звучали мысли и о запрете интернет-псевдонимов, чтобы у каждого комментария в каждом форумчике был легкоустанавливаемый реальный владелец.
Отчего-то все просто сходят с ума от веб-приложений, пытаясь впихнуть в несчастный браузер все, вплоть до самой операционки; все чаще встречаются приложения, работающие в веб-окружении, обернутом в нативную обертку. И мы вполне можем дождаться того, что из всего многообразия приложений нужен будет только браузер. И вот тогда браузероОС расцветут. В самом деле, если нужен лишь браузер, то зачем нам остальное «лишнее»?
Но пока же стек веб-технологий еще недостаточно развился, волоча за собой хвосты неподходящих для этих целей технологий, как-то:
— избыточный, не слишком стандартизированный HTML, который позволяет одновременно делать много (воспроизведение и обработка видео, 3D-рендеринг и пр.) и делать это плохо (необязательность структуры вроде отсутствия head тегов и закрывающих тегов)
— в целом неплохой язык JavaScript, хоть и завораживающий своей простотой и лаконичностью, но с тяжелым наследием странностей и просто архитектурных просчетов (таких, как поведение this или однопоточная асинхронность), вынуждающих вводить новые странности
— и уж совсем ни на что не годный CSS, работа с которым становится возможна только благодаря всяческим языковым расширениям типа Less\SASS\PostCSS, который, увы, никак не развивается синтаксически, но зато обрастает (имхо) ненужными свойствами типа вау-анимации и пр., таким образом, перестает быть описанием свойств объектов (зеленый, большой) и становится описанием поведения (прыгающий и появляющийся-исчезающий) и уходит от своей идеологии.
К тому же этот стек не показывает себя столь же производительным, сколько натив.
Я тоже не понимаю, отчего в одной приложение, которое изначально должно было уметь только показывать текст, стремятся впихнуть все остальное, но зато понимаю, что если все впихнуть в браузер, то все оставшееся извне просто не нужно.
И напоследок имхо: было бы лучше, если бы не браузер был бы операционкой, а операционка (грубо говоря) «браузером» в плане экосистемы приложений.
Видимо, речь идет о защите от чисто софтверных угроз, типа вирусов и эксплойтов
. Хоть гипервизор — не полноценная виртуалка, но и это все же лучше, чем работа в окружении пользователя (тем более, что чаще всего пользователь работает с правами Администратора).
Название «Компьютер» хоть и логичен для названия точки входа, но не переставало озадачивать примерно так: «Но я же уже за компьюером!», «Компьютер в компьютере?», «Мне покажут железо?» — слишком уж общо и непонятно.
Также и «Пуск», который ничего не пускал, а предоставлял доступ к программам и последующим настройкам программ и ОС.
Претензия к «Цетрам» и «Службам», в первую очередь, в избыточности, более долгому визуальному поиску (особенно при одинаковых или похожих иконках). Ведь, если показывается список Служб, то пункты «служба А» и «служба Б» лучше просто именовать «А» и «Б».
Местоимения «этот» и «тот» вообще еще более лишены смысла и дезориентируют (если это «этот», то ведь должен быть и «тот», но где он?!)
Поэтому, на мой взгляд, лучше всего отказаться от обезличенных местоимений и, либо их не использовать вообще, либо использовать имена («Компьютер Васи», например). Также, давать имена программам — тоже неплохая идея, хоть и слегка намекает на Скайнет.
это почему же?
как в этой связи не вспомнить http://images-cdn.9gag.com/photo/2078832_700b.jpg?
опять же вопрос — как именно он это делает. Есть опасность вернуть неверные данные. И опять же, появляется необходимость пробрасывания и обработки исключений выше — иногда это излишне.
Не намного хуже того, если приложение не падает, а назойливо жалуется, ничего не делает или вообще виснет, пока не вдёрнете проводок на место — вот что имелось ввиду, по-моему.
Так вся статья о том, насколько и в каких случаях приложение должно быть параноидальным — городить ли проверки на каждую функцию, или «пусть падает» до более общей проверки?
Урок 2. Да, исключения бывают штатными и неожиданными, но тут разница только в том, что отсутствие обработки первых — позорно, а вот вторые нужно «почти» не обрабатывать (в гуёвом приложении можно выкинуть окошко «Извините, но что-то плохое случилось», в headless — как минимум, расписать подробно в лог, что мы пытались сделать)
Урок 3. Все сводится к холивару «fail-fast vs defaults», и где лучше исключение, а где — пустые данные — вопрос вечно открытый. А на самом деле, в Java явно недостает конструкции?.. чтобы вместо if(a!=null&&a.getB()!=null&&a.getB().getC()!=null) писать if(a?.getB()?.getC()!=null)
по второму пункту: да, «короткий» код скрывает типы объектов, но по сути, тут просто неверный выбор имен. Код куда понятнее.
Во-вторых, приложение получается «бибикающим», вместо работающего (помните программы-шутки из 90х годов, которые заставляли нажимать ОК 100 раз?)
И в-третьих, GUI.alert по-хорошему не должен быть доступен отовсюду: изолированный код — хороший код (см. закон Деметры)
есть, .eclipse, или что в Вашем понятии «файл проекта»?
так было раньше, теперь eclipse спрашивает, обновить ли файл
что тут говорить, если структура меняется от версии к версии одной IDE, и вообще, это связало бы разработчикам руки
перемалываюрефакторю код. Инлайн\выделение методов, свертывание и развертывание объектов (в последовательности и более простые структуры), перенос-переименование классов и т.д. согласно ходу мыслей — настолько, что уже через час код может драматически измениться.И в этой связи написание\изменение тестов может практически остановить этот процесс. А потому я и не пытаюсь следовать заповедям TDD.
И все же я пишу тесты. Это происходит тогда, когда мне необходимо убедиться, что мои предположения в коде верные, а защитные механизмы (типа assert) слишком дороги, чтобы ими присыпать функции, словно снегом. Мне тесты нужны, чтобы или выделить маленькую часть и проверить те детали реализации, которые уже не различает замыленный глаз (выход за пределы массива, переполнение или потеря точности нулевые указатели и т.д.). Т.е. тестом я поднимаю не все приложение, а беру нашпигованный логикой сервис, эмулируя окружение и возможные граничные ситуации, и смотрю, насколько хорошо класс с ними справляется. Я пишу тесты, чтобы ничего не забыть.
Или наоборот, я пишу тесты не на каждый объектно-функциональный чих, а на длинную связку процессов, таким образом повышая вероятность отсутствия (но, конечно же, не полное отсутствие!) ошибок — т.е. если результат сложного процесса корректен, то, скорее всего, корректна также и работа его составляющих.
Иногда я пишу тесты для того, чтобы понять, что и как я буду кодить — что уже ближе к правильному подходу. Иногда проще написать такой тест, который мне покажет, как написать гибкий, расширяемый, а главное — тестируемый класс. Он же мне поможет избежать создания как и чересчур зависимого класса, так и слишком универсального — конечно, для этого тест должен моделировать более-менее правдоподобную ситуацию (или несколько)
Такой подход позволяет уделять меньше времени написанию тестов только ради покрытия, а также меньше потея из-за мелочей, держа в уме только примерный алгоритм, без деталей — а уж детали выплывут при запуске тестов, и останется только их исправить, чтобы все в конце концов работало, а силы ушли на обдумывание решений, а не на реализацию деталей.
Таким образом, на выходе получаем достаточно надежный код, который будет в большинстве случаев работать, при минимуме тестов и утечкой сил на их написание, а также минимум адаптации старых тестов к новому (чит. сырому) коду, а потому легче не только писать тесты, но и адаптировать их, усложнять и лучше проверять основной код.
Это особенно важно, когда нет времени\сил\желания на скрупулезность (ведь должны быть готово уже вчера!), ведь тестирование слилось в процессе с разработкой — ни до, ни после, а именно во время (да и вовремя) разработки, при этом свежая функциональность работает в большинстве очевидных сценариев.
И только когда основная часть выверена, тогда можно заниматься повышением покрытия сверх 80%, описывая никому не нужные тесты, просто ради того, чтобы были, а также проверяли корректность простых ситуаций.
И тогда абсурд станет нормой, проходили уже. Лет 5-10 назад писали же, что, мол, не будут ничего блокировать, потому что это абсурд. А теперь вспомните, сколько раз блокировали и Википедию, и Гитхаб, и многие другие.
Теперь же речь идет о блокировке всех неугодных сайтов, с запретом технологий типа vpn и «интернета поверх интернета», которые В ТОМ ЧИСЛЕ могут помочь с обходом блокировок, но НЕ ЯВЛЯЮТСЯ ИНСТРУМЕНТОМ для этого, об запрете\ослаблении шифрования, а также MitM-госсертификатах.
Хотите больше абсурда? Пожалуйста: «наверхну» звучали мысли и о запрете интернет-псевдонимов, чтобы у каждого комментария в каждом форумчике был легкоустанавливаемый реальный владелец.
Но пока же стек веб-технологий еще недостаточно развился, волоча за собой хвосты неподходящих для этих целей технологий, как-то:
— избыточный, не слишком стандартизированный HTML, который позволяет одновременно делать много (воспроизведение и обработка видео, 3D-рендеринг и пр.) и делать это плохо (необязательность структуры вроде отсутствия head тегов и закрывающих тегов)
— в целом неплохой язык JavaScript, хоть и завораживающий своей простотой и лаконичностью, но с тяжелым наследием странностей и просто архитектурных просчетов (таких, как поведение this или однопоточная асинхронность), вынуждающих вводить новые странности
— и уж совсем ни на что не годный CSS, работа с которым становится возможна только благодаря всяческим языковым расширениям типа Less\SASS\PostCSS, который, увы, никак не развивается синтаксически, но зато обрастает (имхо) ненужными свойствами типа вау-анимации и пр., таким образом, перестает быть описанием свойств объектов (зеленый, большой) и становится описанием поведения (прыгающий и появляющийся-исчезающий) и уходит от своей идеологии.
К тому же этот стек не показывает себя столь же производительным, сколько натив.
Я тоже не понимаю, отчего в одной приложение, которое изначально должно было уметь только показывать текст, стремятся впихнуть все остальное, но зато понимаю, что если все впихнуть в браузер, то все оставшееся извне просто не нужно.
И напоследок имхо: было бы лучше, если бы не браузер был бы операционкой, а операционка (грубо говоря) «браузером» в плане экосистемы приложений.
. Хоть гипервизор — не полноценная виртуалка, но и это все же лучше, чем работа в окружении пользователя (тем более, что чаще всего пользователь работает с правами Администратора).