На самом деле можно существенно усложнить взлом, используя только скремблирование.
В том числе подменять алгоритм в случае, если по вторичным признакам мы обнаруживаем, что нас отлаживают. В этом случае взломщику придется копать, почему в отладчике все путем, а без него все падает. В итоге для взлома требуется более высокая квалификация, следовательно, вероятность падает.
Выбор между целочисленным типом и типом с плавающей точки зависит от природы данных, и никогда не делается «с потолка». По-крайней мере профессионалом.
А вот выбор между float и double… float имеет смысл использовать только в том случае, если имеется большой объем данных, которые влезают в этот тип, причем их нужно только передавать, без проведения каких-либо вычислительных операций. Если же есть арифметика — однозначно double, т.к. большинство стандартных функций все равно преобразует в double.
Иногда нужно уметь оперировать абстракциями без примеров. Потому как составление адекватных примеров часто является в несколько раз более сложной задачей, чем реализация решения.
Писать код с использованием имеющихся средств — это совсем не то же самое, что разрабатывать библиотеку «с нуля». Требуется другой уровень мышления, на пару порядков продвинутей, т.к. нужно учесть все возможные частные случаи и каким-то более-менее адекватным образом на них реагировать.
Так что обучение при написании подобных решений происходит в несколько раз быстрее, чем при написании обычного application-кода.
Насчет очевидности. Конечно, для профессионального разработчика с нормальной подготовкой это очевидно. Однако, очень часто встречаются менее квалифицированные разработчики, поэтому подобные обзоры открывают им глаза на то, как проектировать нормальные системы. И, опять же, полезно для начинающих программистов.
Минусующие!
Просьба, оставляйте коммент, поясняющий причину минусов по тематическому посту.
Я всегда за аргументированные помидоры в мой адрес, но молчаливое сливание, имхо — это просто некрасиво с вашей стороны.
Писать код правильно — это всегда сокращение затрат.
Как минимум на тестирование и поддержку.
Правильный код показывает дисциплину и уровень разработчика. Хороший разработчик не позволяет себе опуститься до говнокода. Конечно, бывают ситуации, когда на небольшой рефакторинг не хватает пару-тройку часов (релиз завтра!), но даже тогда это место локализуется, отделяется интерфейсами и т.д., по максимому соблюдая инкапсуляцию. И обязательно оставляются комментарии.
В дальнейшем (после выкладывания очередного релиза) этот код обязательно переписывается по-человечески.
Если пользоваться английским алфавитом, то лучше писать английские слова.
Я для русского алфавита лучше русские слова.
А то от сегодняшних «супермаркетов» уже тошнит :-)
Если я вижу плохой код, у меня есть желание его переписать.
Если код можно сделать лучше — я делаю его лучше.
Но в работе приоритеты несколько иные:
Делается только то, что нужно заказчикам (внешним или внутренним).
Задачи (как правило) ставятся внешним образом.
Поменять формулировку задачи (а иногда и отменить задачу) можно только в том случае, если сумеешь найти этому объективные причины.
Время, выделяемое для выполнения задач, для разработчиков стремится к минимуму.
На остальные задачи (например, поддержание качества кода) всегда нет времени.
Как можно выйти из этой ситуации?
Я лично предпочел закладывать время на поддержание качества кода в поставленные задачи, а также максимально увеличиваю производительность, выжимая максимум из скорости набора кода, использования средств IDE (горячих клавиш, автоматических рефакторингов и т.д.) и остальной инфраструктуры.
В итоге:
У меня есть личная удовлетверенность от проделанной работой, плюс ощущения собственных возможностей и умений.
Начальники/заказчики получают выполнение своих задач в поставленные сроки.
Качества проекта в целом улучшается или как минимум не ухудшается, что позволит проекту прожить как можно дольше без переписывания «с нуля».
Единственная проблема — ни в одной книге никто не выносил «тонкостей» в отдельное место, они всегда размазаны по книге. В итоге их довольно сложно искать.
В том числе подменять алгоритм в случае, если по вторичным признакам мы обнаруживаем, что нас отлаживают. В этом случае взломщику придется копать, почему в отладчике все путем, а без него все падает. В итоге для взлома требуется более высокая квалификация, следовательно, вероятность падает.
А вот выбор между float и double… float имеет смысл использовать только в том случае, если имеется большой объем данных, которые влезают в этот тип, причем их нужно только передавать, без проведения каких-либо вычислительных операций. Если же есть арифметика — однозначно double, т.к. большинство стандартных функций все равно преобразует в double.
Так что обучение при написании подобных решений происходит в несколько раз быстрее, чем при написании обычного application-кода.
Просьба, оставляйте коммент, поясняющий причину минусов по тематическому посту.
Я всегда за аргументированные помидоры в мой адрес, но молчаливое сливание, имхо — это просто некрасиво с вашей стороны.
Как минимум на тестирование и поддержку.
Правильный код показывает дисциплину и уровень разработчика. Хороший разработчик не позволяет себе опуститься до говнокода. Конечно, бывают ситуации, когда на небольшой рефакторинг не хватает пару-тройку часов (релиз завтра!), но даже тогда это место локализуется, отделяется интерфейсами и т.д., по максимому соблюдая инкапсуляцию. И обязательно оставляются комментарии.
В дальнейшем (после выкладывания очередного релиза) этот код обязательно переписывается по-человечески.
Я для русского алфавита лучше русские слова.
А то от сегодняшних «супермаркетов» уже тошнит :-)
Но в работе приоритеты несколько иные:
Как можно выйти из этой ситуации?
Я лично предпочел закладывать время на поддержание качества кода в поставленные задачи, а также максимально увеличиваю производительность, выжимая максимум из скорости набора кода, использования средств IDE (горячих клавиш, автоматических рефакторингов и т.д.) и остальной инфраструктуры.
В итоге:
Особенно радует наличие ссылок на источники предварительных знаний, чтобы быть в курсе, читая основную статью.