Кстати, Касперский может резать большой json, приходящий аяксом (что-то около 3 мегабайт). Причем режет по длине текста, т.к. приходит на самом деле 700-килобайтный gzip. Можно извратиться с мапами, а можно и попробовать скомпрессить так.
Весь смысл в том, что вы акцентируете на симптомах, а не на причинах, которые их вызывают.
Если говорить о программах как таковых — никого не волнует, сколько строк кода там (да, было время, когда за SLOC платили, но идея быстро изжила себя). Для бизнеса/пользователя важно, чтобы было реализовано достаточное количество функционала, доступ к нему был максимально простой, скорость исполнения высокой, и в процессе не возникало ошибок (здесь можно заметить, что можно разделить собственно ошибки на много видов: неясности вроде ошибок с цифровыми кодами вместо сообщений, несогласованности при ошибках в интеграции систем, просто ошибки — например, возраст может быть отрицательным, ошибки критические — когда пользователь теряет время, деньги или не получает результата вовсе). Т.е. возможных метрик (а ошибки могут быть метрикой кода — я, например, не зря привел в пример программы NASA, количество ошибок в коде которых минимальнейшие из всех софтверных компаний) куда больше, чем просто «количество ошибок». Кроме того, количественно-качественное отношение здесь сложно вывести, т.к., на самом деле, нужны дополнительные инструменты в метрике. Справедливости ради, некоторые отчеты в Джире я так и смотрю — количество багов на период, разбитых по уровню сложности (тривиал-критикал) и влиянию на систему, дополнительно вводя срезы по компонентам.
То есть ошибки как бы могут говорить что-то о коде. Но (и если вы читали книги, о которых я упомянул выше), вы бы понимали, что: а) любое приложение имеет баги, т.к. 100% покрытие автоматическими/ручными тестами невозможно (при сложности, стремящейся к увеличению), б) можно подсчитать количество обнаруженных багов, но не скрытых, в) невозможно прогнозировать количество багов в будущее на основе имеющегося количества (т.к. у нас метрика — окончательный результат, а не что-то общее и для блоков, которые будут написаны позднее и т.п.).
Это примерно как анализировать, напишет ли художник следующую картину лучше (или маляр покрасит новый забор) по количеству правильно переданных светотеней. И не просто оценивать его прогресс как таковой, но выносить за эту некую оценку качества. Пример некорректный, но он только для того, чтобы показать, что окончательные метрики не могут использоваться для прогнозирования.
Но о чем же все эти «рефакторинги», «совершенные коды» и статьи в таком духе, называющие наши обожаемые исходники говнокодом? Они о том, что основные метрики качества кода еще более субъективные — масштабируемость, расширяемость, простота для понимания при работе средними и большими командами, наличие необходимых условий для автоматического тестирования, покрытие кода (не взирая на «строгое» определение, довольно расплывчатая метрика!), — т.е. критерии, которые облегчают разработку и потенциально уменьшают количество ошибок (как симптомов болезни), помогают избежать их при переписывании больших и критически важных частей кода, легко расширять и бла-бла-бла. В общем, те вещи, по которым депрессирует каждый программист в крупных проектах (выше в комментариях дали правильное определение процессу, которая возникает всегда, — энтропия, т.е. постепенное сваливание проекта в огромного неповоротливого монстра с костылями, багами и часями архитектуры, о которых никто не знает).
В заключение скажу, что вы в какой-то мере правы. Для простого программиста, который пишет свою часть и не проектирует что-то крупное (из того что пишет), мерило качества — выполнение своих функций и отсутствие ошибок (хотя никто не освободит вас при этом от конвенций в коде и от паттернов). Точно так же, как мерилом профессионализма этого программиста могут выступать количество денег, которые ему платят за это (согласитесь, корреляция в таком случае несколько… хм).
На более высоких уровнях,- бизнеса, архитектора, лида, прожект-менеджера — код должен не только работать.
Остальным, кто еще не читали классику — «Факты и заблуждения профессионального программирования» и «Мифический человекомесяц» — марш читать, а то так и будете считать, что все субъективно и все просто пытаются заставить вас писать так, как нравится «им».
супер защищённый мессенджер для смартфонов, на столько безопасный, что за его взлом объявлен конкурс с внушительным призом.
Я даже сделаю вид, что в упор не вижу ошибку, но — недавно писали про ловушки конкурсов, и многие не верили, что между внушительным призом и защищенностью быстро поставят знак равенства. Зря, видимо.
Это совершенно некорректно и ведет к тем же проблемам, что и в старых версиях php делал register_globals и не выставленный в E_ALL уровень репортинга. Умом понимаю, почему Twig по умолчанию не включает стрикт по умолчанию, но сердце отказывается верить. Да и согласитесь,
{% if errors is defined %}
выглядят куда круче. В крайнем случае это может быть
лучшедешевлеЕсли говорить о программах как таковых — никого не волнует, сколько строк кода там (да, было время, когда за SLOC платили, но идея быстро изжила себя). Для бизнеса/пользователя важно, чтобы было реализовано достаточное количество функционала, доступ к нему был максимально простой, скорость исполнения высокой, и в процессе не возникало ошибок (здесь можно заметить, что можно разделить собственно ошибки на много видов: неясности вроде ошибок с цифровыми кодами вместо сообщений, несогласованности при ошибках в интеграции систем, просто ошибки — например, возраст может быть отрицательным, ошибки критические — когда пользователь теряет время, деньги или не получает результата вовсе). Т.е. возможных метрик (а ошибки могут быть метрикой кода — я, например, не зря привел в пример программы NASA, количество ошибок в коде которых минимальнейшие из всех софтверных компаний) куда больше, чем просто «количество ошибок». Кроме того, количественно-качественное отношение здесь сложно вывести, т.к., на самом деле, нужны дополнительные инструменты в метрике. Справедливости ради, некоторые отчеты в Джире я так и смотрю — количество багов на период, разбитых по уровню сложности (тривиал-критикал) и влиянию на систему, дополнительно вводя срезы по компонентам.
То есть ошибки как бы могут говорить что-то о коде. Но (и если вы читали книги, о которых я упомянул выше), вы бы понимали, что: а) любое приложение имеет баги, т.к. 100% покрытие автоматическими/ручными тестами невозможно (при сложности, стремящейся к увеличению), б) можно подсчитать количество обнаруженных багов, но не скрытых, в) невозможно прогнозировать количество багов в будущее на основе имеющегося количества (т.к. у нас метрика — окончательный результат, а не что-то общее и для блоков, которые будут написаны позднее и т.п.).
Это примерно как анализировать, напишет ли художник следующую картину лучше (или маляр покрасит новый забор) по количеству правильно переданных светотеней. И не просто оценивать его прогресс как таковой, но выносить за эту некую оценку качества. Пример некорректный, но он только для того, чтобы показать, что окончательные метрики не могут использоваться для прогнозирования.
Но о чем же все эти «рефакторинги», «совершенные коды» и статьи в таком духе, называющие наши обожаемые исходники говнокодом? Они о том, что основные метрики качества кода еще более субъективные — масштабируемость, расширяемость, простота для понимания при работе средними и большими командами, наличие необходимых условий для автоматического тестирования, покрытие кода (не взирая на «строгое» определение, довольно расплывчатая метрика!), — т.е. критерии, которые облегчают разработку и потенциально уменьшают количество ошибок (как симптомов болезни), помогают избежать их при переписывании больших и критически важных частей кода, легко расширять и бла-бла-бла. В общем, те вещи, по которым депрессирует каждый программист в крупных проектах (выше в комментариях дали правильное определение процессу, которая возникает всегда, — энтропия, т.е. постепенное сваливание проекта в огромного неповоротливого монстра с костылями, багами и часями архитектуры, о которых никто не знает).
В заключение скажу, что вы в какой-то мере правы. Для простого программиста, который пишет свою часть и не проектирует что-то крупное (из того что пишет), мерило качества — выполнение своих функций и отсутствие ошибок (хотя никто не освободит вас при этом от конвенций в коде и от паттернов). Точно так же, как мерилом профессионализма этого программиста могут выступать количество денег, которые ему платят за это (согласитесь, корреляция в таком случае несколько… хм).
На более высоких уровнях,- бизнеса, архитектора, лида, прожект-менеджера — код должен не только работать.
Остальным, кто еще не читали классику — «Факты и заблуждения профессионального программирования» и «Мифический человекомесяц» — марш читать, а то так и будете считать, что все субъективно и все просто пытаются заставить вас писать так, как нравится «им».
Я даже сделаю вид, что в упор не вижу ошибку, но — недавно писали про ловушки конкурсов, и многие не верили, что между внушительным призом и защищенностью быстро поставят знак равенства. Зря, видимо.
{% if errors is defined %}выглядят куда круче. В крайнем случае это может быть
{% if errors|default('') is empty %}Когда у нас логика сложнее/ненормальнее.