У меня другая сумасшедшая идея: может, пора перестать сходить с ума по веб-приложениям и вернуться к веб-страницам?
Зачем нам ajax, частичная перерисовка, и эти тонны кода, гоняемые клиенту, когда у нас уже нет тонких каналов и проблемы «пустого листа»? Это же с ума сойти можно, ожидая, пока все хозяйство прогрузится на клиент, инсталлируется, кусками подтянет данные с сервера, отрисуется, а потом покажет багованные кастомные элементы, которые ни разу не интуитивны, но зато сверкают анимациями и морфингом.
Отобразить данные в таблице, показать форму с нативными (для браузера) контролами, ведь все в итоге сводится к этому… Тому же, что мы умели и в начале 2000ых — мы не стали решать более сложные проблемы, нет, мы решаем те же проблемы, но используем куда более сложные инструменты… Действительно ли они нам так нужны?
Плиточные упрощенные визуально контролы… Но давайте упрощать их функциональность, а не внешний вид!
Чтобы избежать эту проблему, нужно всегда писать команды так, чтобы их нельзя было получить от пользователя.
Спасибо, Кэп, это ведь все, что ты хотел сказать?
На самом деле проблема глубже: нельзя данные делать слишком «умными». А идеально — максимально жестко ограничивать формат.
К примеру, если мы ждем параметр «цвет» в формате RGB, то нужно проверять, чтобы это была последовательность символов 0-9, A-F из 6 знаков. даже символ # не нужно разрешать, его можно и так подставить. 6 знаков, не 7, не 8…
Хорошее начинание, таких Spotify должно быть больше в каждой стране. Только так можно уменьшить кол-во маразма с вечным копирайтом, штрафами за исполнение своих произведений, невозможностью копировать для себя и одалживать друзьям, слушать слишком громко и т.п.…
Все экстремизм, кроме УК, ГК и Библии. Вот чтиво, которое должен читать на ночь добропорядочный гражданин, остальное — пропаганда вольнодумия и развращение юных душ!
Действительно, тема вечная: давно есть адекватные решения, но новички продолжают писать своих убийц pdo с sql injection и выборками в коде, но зато без *фатального недостатка*
А еще для этих целей используется метамодель, и пишется проще: users.get(User_.username). Особенно если сборку настроить для автоматической генерации метамодели
А все эти Assertions.assertEquals(), которые бросают Exception, для кого писали?
Т.е. странно использовать именно джавовский assert, чье поведение еще зависит от конфиги рантайма…
Так что, неудивительно, что отхватили граблей.
Это еще и плохая илея потому, что код в книге гораздо чаще содержит ошибки, чем он же в приложении к книге (гит репо). Что и неудивительно — вычитка кода намного сложнее как для людей, так и для ocr
На самом деле статические анализаторы, в частности, PVS-Studio, очень полезны в поиске типовых ошибок, которые сам программист из-за усталости либо просто невнимания, а то и банально недостаточного опыта сам бы никогда не заметил. Выйти за пределы массива, забыть освободить память, скопипастить и забыть поменять все вхождения может даже гуру-программист, и такую ошибку просто в силу человеческого фактора может пропустить код-ревью. И тут большой вопрос, понижает ли опечатка качество кода, или все же за кошмарный стиль (пусть и без ошибок) надо бить сильнее?
Повторюсь, если статический анализ выявляет подозрительное место, пусть и правильное — но это же место может еще привести к другим ошибкам. Даже если все эти i+++++i понятны автору, то сторонний программист вполне вероятно тут споткнется.
Потому нужны и статические анализаторы, и код-ревью, и тестирование и однообразный стиль кода.
На самом деле, цель не достигнута. Вскользь, да, доводы есть, но на них не сделан акцент, вместо этого приводятся убеждения вида «мамой клянусь».
А стоило бы сделать упор вот на что:
— Поскольку код проектов открыт, а триальная версия анализатора доступна, то любой скептик может провести собственный аудит кода, что не требует от аудитора выдающихся способностей или уймы времени.
— Даже если анализатор нашел множество ошибок (а чем больше проект, тем их должно быть больше), это еще не значит, что код плохой. Предупреждение может быть или ложным срабатыванием (коих ожидается гораздо больше, чем настоящих ошибок), или быть несущественным (ошибочный код или не выполняется почти никогда, или нивелируется поведением корректного кода). И наоборот, просто плохой стиль кода может быть абсолютно корректным с точки зрения как статического анализатора, так и самого рантайма (скажем, обфускация кода не меняет количество предупреждений).
— Не только физически невозможно, но и неинтересно проверять всех конкурентов проверенной программы, а уж тем более проводить сравнение по выявленным огрехам. А тем более каждый аудит оформлять в виде пухлой статьи.
— Проекты с закрытым кодом не могут быть проверены либо из-за недоступности исходников, либо из-за отсутствия права публиковать фрагменты кода. Поэтому статьи только об оперсорс проектах.
— Вор громче всех кричит о том, что у него что-то украли: голословные утверждения непроверяемы в силу человеческого фактора. Если уж абсолютно случайная последовательность нулей и единиц может выдать достаточно длинную очередь только нулей или единиц, это ли основание обвинять случайность в предвзятости? Точно так же предвзято относится обвиняющий в предвзятости, при этом ему совершенно необязательно быть троллем.
— Наконец, статьи тоже пишутся людьми. Есть неинтересные проекты, есть неудачно подобранные для статьи предупреждения, да и все что угодно может показаться негативом. Впрочем, все это проверяемо, и каждый может прогнать повторно Студию по коду — возможно, у него статья получится интереснее.
Думаю, хоть здесь и нет прямой зависимости, но доля правды есть, и вот почему:
1. статическими анализаторами как раз и пользуются для нахождения ошибок, опечаток и пр., имея целью повышения качества кода (иначе зачем таковые вообще нужны)
2. плохо написанный код по определению должен содержать места, которые выявит статический анализатор — ожидается, что чем их меньше, тем код лучше
3. и наоборот, чтобы написать очень плохой код так, чтобы статический анализатор ничего не заметил, это нужно постараться.
Однако, утверждение не может быть полностью правдивым по следующим причинам:
1. как бы хорош ни был анализатор, но он по своей природе не может выявить достаточно большой класс ошибок — как, например, логические ошибки
2. все еще грустнее в мире языков с динамической и\или слабой типизацией, например, таких, как PHP или JS — на то он и статический.
3. даже хороший статический анализатор будет выдавать ложные предупреждения в тех местах, где код корректен, но анализатору что-то там не понравилось; и это не плохо — не будет лишним как минимум обратить внимание на подозрительный код, а как максимум — переписать его (если это возможно) так, чтобы не было предупреждения, а вместе с тем и меньше недоумения у людей, которые будут этот код читать.
Учитывая эти (достаточно очевидные) моменты, что-то я очень сомневаюсь, что есть серьезные проекты, на которые не ругнулся бы С.А., даже лидер класса, такой, как PVS-Studio.
Впрочем, ТС это можно, свое дитя всегда самое красивое )
Итак, ключевая мысль: представление отделяем от данных, виджет отдельно, вся работа с информацией в нем — отдельно. Насколько отдельно?
принцип единственной ответственности, SRP — вот зачем все эти MVC и FRP, поэтому отделяем настолько отдельно, насколько позволяет здравый смысл, чтобы каждый компонент системы занимался только одним отведенным ему делом и не знал ничего о других.
тогда, имея множество маленьких кубиков, мы можем строить наше приложение, как конструктор лего, любой сложности, добавляя, заменяя и выкидывая эти кубики, не ломая всю систему.
и, раз уж в комментариях упомянули maven, то позвольте оффтоп: ну почему сборка maven намного быстрее сборки gradle? волею судеб будучи вынужден работать за слабым и немного умирающим компом, пришлось (хочется верить, что временно) отказаться от gradle в пользу maven именно из-за скорости, а еще и потому, что gradle-демон отжирает оперативку даже когда не нужен. в итоге даже один тяжелый gradle-проект не смог собраться на таком увечном железе, наглухо подвесив всю ОСь...
с java 9 и её обязательной модульностью… да, с одной стороны, полностью standalone приложения весят меньше за счет выкидывания неиспользуемой библиотеки, с другой… а с другой — множество таких приложений весят больше за счет дублирования зависимостей.
плюс поломалось все то, что работало под 8-… плюс, пишем либо под 8, либо под 9… плюс необходимость дполнительно описывать модуль и линковать...
нет, это не совсем то, что нужно. нужен менеджер репозиториев типа maven на уровне инсталляшек, вот как во всех линухах все эти rpm, apt,yast… чтобы все необходимые jar,dll,rpm или что-то--там--неважно--что загружалось и ставилось автоматически при установке софта, при этом по возможности разделяя между собой совместно используемые библиотеки, в идеале — реально загружая только diff/patch.
Зачем нам ajax, частичная перерисовка, и эти тонны кода, гоняемые клиенту, когда у нас уже нет тонких каналов и проблемы «пустого листа»? Это же с ума сойти можно, ожидая, пока все хозяйство прогрузится на клиент, инсталлируется, кусками подтянет данные с сервера, отрисуется, а потом покажет багованные кастомные элементы, которые ни разу не интуитивны, но зато сверкают анимациями и морфингом.
Отобразить данные в таблице, показать форму с нативными (для браузера) контролами, ведь все в итоге сводится к этому… Тому же, что мы умели и в начале 2000ых — мы не стали решать более сложные проблемы, нет, мы решаем те же проблемы, но используем куда более сложные инструменты… Действительно ли они нам так нужны?
Плиточные упрощенные визуально контролы… Но давайте упрощать их функциональность, а не внешний вид!
Спасибо, Кэп, это ведь все, что ты хотел сказать?
На самом деле проблема глубже: нельзя данные делать слишком «умными». А идеально — максимально жестко ограничивать формат.
К примеру, если мы ждем параметр «цвет» в формате RGB, то нужно проверять, чтобы это была последовательность символов 0-9, A-F из 6 знаков. даже символ # не нужно разрешать, его можно и так подставить. 6 знаков, не 7, не 8…
Давно бы пополнили
карманыбюджет и вывели бы страну в лидерыпо уголовникампо уровню жизни!Т.е. странно использовать именно джавовский assert, чье поведение еще зависит от конфиги рантайма…
Так что, неудивительно, что отхватили граблей.
Посмотрите еще экосистему .NET
Повторюсь, если статический анализ выявляет подозрительное место, пусть и правильное — но это же место может еще привести к другим ошибкам. Даже если все эти i+++++i понятны автору, то сторонний программист вполне вероятно тут споткнется.
Потому нужны и статические анализаторы, и код-ревью, и тестирование и однообразный стиль кода.
А стоило бы сделать упор вот на что:
— Поскольку код проектов открыт, а триальная версия анализатора доступна, то любой скептик может провести собственный аудит кода, что не требует от аудитора выдающихся способностей или уймы времени.
— Даже если анализатор нашел множество ошибок (а чем больше проект, тем их должно быть больше), это еще не значит, что код плохой. Предупреждение может быть или ложным срабатыванием (коих ожидается гораздо больше, чем настоящих ошибок), или быть несущественным (ошибочный код или не выполняется почти никогда, или нивелируется поведением корректного кода). И наоборот, просто плохой стиль кода может быть абсолютно корректным с точки зрения как статического анализатора, так и самого рантайма (скажем, обфускация кода не меняет количество предупреждений).
— Не только физически невозможно, но и неинтересно проверять всех конкурентов проверенной программы, а уж тем более проводить сравнение по выявленным огрехам. А тем более каждый аудит оформлять в виде пухлой статьи.
— Проекты с закрытым кодом не могут быть проверены либо из-за недоступности исходников, либо из-за отсутствия права публиковать фрагменты кода. Поэтому статьи только об оперсорс проектах.
— Вор громче всех кричит о том, что у него что-то украли: голословные утверждения непроверяемы в силу человеческого фактора. Если уж абсолютно случайная последовательность нулей и единиц может выдать достаточно длинную очередь только нулей или единиц, это ли основание обвинять случайность в предвзятости? Точно так же предвзято относится обвиняющий в предвзятости, при этом ему совершенно необязательно быть троллем.
— Наконец, статьи тоже пишутся людьми. Есть неинтересные проекты, есть неудачно подобранные для статьи предупреждения, да и все что угодно может показаться негативом. Впрочем, все это проверяемо, и каждый может прогнать повторно Студию по коду — возможно, у него статья получится интереснее.
1. статическими анализаторами как раз и пользуются для нахождения ошибок, опечаток и пр., имея целью повышения качества кода (иначе зачем таковые вообще нужны)
2. плохо написанный код по определению должен содержать места, которые выявит статический анализатор — ожидается, что чем их меньше, тем код лучше
3. и наоборот, чтобы написать очень плохой код так, чтобы статический анализатор ничего не заметил, это нужно постараться.
Однако, утверждение не может быть полностью правдивым по следующим причинам:
1. как бы хорош ни был анализатор, но он по своей природе не может выявить достаточно большой класс ошибок — как, например, логические ошибки
2. все еще грустнее в мире языков с динамической и\или слабой типизацией, например, таких, как PHP или JS — на то он и статический.
3. даже хороший статический анализатор будет выдавать ложные предупреждения в тех местах, где код корректен, но анализатору что-то там не понравилось; и это не плохо — не будет лишним как минимум обратить внимание на подозрительный код, а как максимум — переписать его (если это возможно) так, чтобы не было предупреждения, а вместе с тем и меньше недоумения у людей, которые будут этот код читать.
Учитывая эти (достаточно очевидные) моменты, что-то я очень сомневаюсь, что есть серьезные проекты, на которые не ругнулся бы С.А., даже лидер класса, такой, как PVS-Studio.
Впрочем, ТС это можно, свое дитя всегда самое красивое )
принцип единственной ответственности, SRP — вот зачем все эти MVC и FRP, поэтому отделяем настолько отдельно, насколько позволяет здравый смысл, чтобы каждый компонент системы занимался только одним отведенным ему делом и не знал ничего о других.
тогда, имея множество маленьких кубиков, мы можем строить наше приложение, как конструктор лего, любой сложности, добавляя, заменяя и выкидывая эти кубики, не ломая всю систему.
и, раз уж в комментариях упомянули maven, то позвольте оффтоп: ну почему сборка maven намного быстрее сборки gradle? волею судеб будучи вынужден работать за слабым и немного умирающим компом, пришлось (хочется верить, что временно) отказаться от gradle в пользу maven именно из-за скорости, а еще и потому, что gradle-демон отжирает оперативку даже когда не нужен. в итоге даже один тяжелый gradle-проект не смог собраться на таком увечном железе, наглухо подвесив всю ОСь...
с java 9 и её обязательной модульностью… да, с одной стороны, полностью standalone приложения весят меньше за счет выкидывания неиспользуемой библиотеки, с другой… а с другой — множество таких приложений весят больше за счет дублирования зависимостей.
плюс поломалось все то, что работало под 8-… плюс, пишем либо под 8, либо под 9… плюс необходимость дполнительно описывать модуль и линковать...
нет, это не совсем то, что нужно. нужен менеджер репозиториев типа maven на уровне инсталляшек, вот как во всех линухах все эти rpm, apt,yast… чтобы все необходимые jar,dll,rpm или что-то--там--неважно--что загружалось и ставилось автоматически при установке софта, при этом по возможности разделяя между собой совместно используемые библиотеки, в идеале — реально загружая только diff/patch.
всего лишь надо добавить префикс U