Чи варто хвилюватися, якщо я вирішую багато своїх проблем однаково?

Мені дуже подобається грати в програмування та створювати головоломки / ігри. Мені здається, що я розробляю безліч цих проблем однаково, і в кінцевому підсумку використовую подібну техніку, щоб програмувати їх, з якими мені дуже подобається.

Щоб коротко ознайомитись, я люблю створювати графіки, де вузли представлені об’єктами. Ці об'єкти містять дані, такі як координати, позиції та звичайно посилання на інші сусідні об'єкти. Я розміщую їх усіх у структурі даних та прийму рішення щодо цієї інформації у "ігровому циклі".

Хоча це короткий приклад, його не точно в усіх ситуаціях. Це просто один із способів, як я відчуваю себе дуже комфортно. Це погано?

Ні, це добре.

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

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

Якщо він працює добре, назвіть це схемою дизайну. Якщо це не так, але ви не знаєте краще, це золотий молот антипатерн.

Реально в наших робочих днях ми, як правило, створюємо досить багато подібних проблем.

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

Якщо ви щось добре знаєте, шанси на те, що ви можете згорнути це за необхідності і що ваша реалізація буде міцною та ефективною. Ці речі, ймовірно, не будуть правдивими з ваших перших спроб нових методів.

Але зворотний бік - якщо все, що у вас є, це молоток, все виглядає як цвях. Вам слід робити щось, щоб знати про альтернативи і коли ви, можливо, занадто сильно штовхаєте своїх улюблених.

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

Добре запитання, і я повинен визнати, що це теж переслідує мене.

Коли це штраф? Зробіть аналіз продуктивності свого коду - якщо ви бачите, що ви перебуваєте в O (log n) або O (n) або O (n log n), і, як правило, ця проблема відображається на відомих структурах даних, ви, як правило, добре.

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

Короткий приклад: У дизайні мікросхем вибір способу розташування воріт в ланцюзі для мінімальної потужності не відповідає NP. Тільки графіки самі по собі не принесуть великої користі, хоча це необхідно. Потрібно прочитати додатковий матеріал, багато його міждисциплінарно часом і застосувати знання у вашому домені. Наприклад, генетичні алгоритми (алгоритми, що імітують генетичні кросовери та мутації, як визначено в біології 101) мають велике застосування при розробці апаратних мікросхем.

Не обов’язково, якщо це вдалий спосіб їх вирішення :)

Зазвичай під час роботи над "рішенням" я переходжу до таких речей у порядку:

• простота ,
• повторне використання ,
• і лише останній виступ .

Не те, що продуктивність не має значення: я розробляю з урахуванням продуктивності, але не натискаючи на це занадто далеко (тому, якщо мені потрібно робити дзвінки до утилітного методу типу StringUtils.isEmpty або чогось подібного в тому ж потоці, я переміг t розум). Якщо тоді потрібна продуктивність (проблема з діловим випадком чи досвідом користувачів), то я підходжу до іншого підходу, ніж простого та багаторазового використання. Будучи прагматичним.

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

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

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

Якщо це працює, це нормально.

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

Якщо ви вирішите проблему, це добре. І неважливо, яким способом, поки це не створить більше проблем.

"Art Developer Art" насправді має правильну відповідь, якщо ваша мета - виготовити продукт. І якщо ваша "фабрика" виробляє продукцію, яка задовольняє, тоді це круто.

Але ...

Якщо ви хочете навчитися вивчати нові (і, можливо, кращі) способи робити речі, ви повинні змінити. Це призведе до невдач, але лише через невдачі насправді вчиться. І завдяки цьому новому навчанню ви зможете виробляти ще краще та переконливіше програмне забезпечення.

Це фактично підкріплено за допомогою неврологічних досліджень. Так що ви йдете.