Должен ли я волноваться, если я решу многие мои проблемы таким же образом?

Я действительно люблю программирование игр и создателей головоломок / игр. Я решаю многие из этих проблем одинаково и, в конечном счете, использую аналогичную технику для их программирования, что мне действительно удобно.

Чтобы дать вам краткое представление, мне нравится создавать графики, в которых узлы представлены объектами. Эти объекты содержат такие данные, как координаты, позиции и, конечно, ссылки на другие соседние объекты. Я помещу их все в структуру данных и буду принимать решения по этой информации в «игровом цикле».

Хотя это краткий пример, он не точен во всех ситуациях. Это всего лишь один способ, с которым я чувствую себя действительно комфортно. Это плохо?

Нет, все хорошо.

Смысл практического программирования заключается в поиске решений, которые, возможно, будут полезны во многих подобных разработках. Вы только что нашли один.

Вы не можете и не должны создавать разные решения только ради того, чтобы они были разными. Но вам определенно следует критически оценивать свои решения каждый раз и спрашивать себя, все ли они хороши или, возможно, отрасль прогрессировала с тех пор, и вам необходимо соответствующим образом согласовать ее.

Если это работает хорошо, назовите это шаблоном дизайна. Если это не так, но вы не знаете лучше, это антипаттерн золотой молоток.

Реально на наших рабочих местах мы часто сталкиваемся с довольно похожими проблемами.

В этих ситуациях хорошо придерживаться того, что вы знаете. Я видел больше примеров плохих решений от людей, реализующих что-то, что они не понимают, что кто-то хорошо использует неидеальную технику.

Если вы хорошо знаете что-то, есть вероятность, что вы сможете согнуть его по мере необходимости, и ваша реализация будет надежной и эффективной. Эти вещи, вероятно, не будут правдой с ваших первых попыток новых методов.

Но с другой стороны, если все, что у вас есть, это молоток, все выглядит как гвоздь. Вы должны делать что-то, чтобы осознать альтернативы и когда вы, возможно, слишком раздвигаете своих фаворитов.

Может быть, выбрать несколько несрочных / некритических изменений и использовать их для ускорения работы с альтернативными решениями?

Хороший вопрос, и я должен признать, что это меня тоже преследует.

Когда это хорошо? Проведите анализ производительности вашего кода - если вы видите, что вы находитесь в O (log n) или O (n) или O (n log n) и, как таковая, проблема сопоставима с известными структурами данных, с вами, как правило, все в порядке.

Когда это не хорошо? Ваша временная или пространственная сложность O (n ^ 2) или хуже, или проблема по определению NP NP. В этих ситуациях вам нужно применить немного эвристики, применить знания из других областей и т. Д.

Быстрый пример: в конструкции микросхемы выбор способа размещения затворов в схеме для минимальной мощности является NP-полным. Только графики не принесут вам пользы, хотя это необходимо. Вам необходимо читать дополнительные материалы, многие из которых иногда являются междисциплинарными, и применять полученные знания в своей области. Например, генетические алгоритмы (алгоритмы, которые имитируют генетические кроссоверы и мутации, как определено в биологии 101) имеют большое применение при разработке аппаратных чипов.

Не обязательно, если это хороший способ их решения :)

Обычно, работая над «решением», я иду по порядку:

• простота ,
• возможность повторного использования ,
• и только последнее выступление .

Не то, чтобы производительность не имела значения: я проектирую с расчетом на производительность, но не слишком углубляюсь в нее (поэтому, если мне нужно сделать вызовы вспомогательного метода, такого как StringUtils.isEmpty или что-то подобное в том же потоке, я выиграл ' не возражаю). Если тогда необходима производительность (бизнес-кейс или проблема с пользовательским интерфейсом), тогда я использую другой подход, нежели простой и многократно используемый. Быть прагматичным.

Странно, однако, что при кодировании на C я гораздо больше беспокоюсь о производительности, чем при кодировании на Java ... Сила привычки :))

Пока проблема решается эффективно, не нужно беспокоиться.

Я думаю, что график является подходящим дизайном для разработки игр, чтобы представлять решения \ выбор. Просто имейте в виду, что, вероятно, это можно улучшить и сделать более эффективным, и это может быть не лучшим решением для других доменов.

Если это работает, это нормально.

Если вы беспокоитесь о чрезмерном использовании одного метода, попробуйте в качестве упражнения найти варианты решенной проблемы, которые могут сделать ваше решение неосуществимым. Дополнительные баллы, если вы можете обобщить изменения, чтобы определить область применимости вашего обычного процесса.

Если вы решаете проблему, это хорошо. И не важно, каким образом, пока это не создаст больше проблем.

«Developer Art» на самом деле имеет правильный ответ, если ваша цель - создать продукт. А если ваша «фабрика» выпускает продукты, которые удовлетворяют, то круто.

Но...

Если вы когда-нибудь захотите изучить новые (и, возможно, лучшие) способы ведения дел, вы должны все изменить. Это приведет к сбоям, но только на самом деле научится. И благодаря этому новому обучению вы сможете создавать еще более качественное и привлекательное программное обеспечение.

На самом деле это подтверждается неврологическими исследованиями. Итак, поехали.