Czy powinienem się martwić, jeśli rozwiążę wiele problemów w ten sam sposób?

Bardzo lubię programować gry i twórców puzzli. Uważam, że wiele z tych problemów opracowuję w ten sam sposób i ostatecznie stosuję podobną technikę, aby zaprogramować je, z którymi jestem naprawdę zadowolony.

Aby dać ci krótki wgląd, lubię tworzyć wykresy, w których węzły są reprezentowane przez obiekty. Te obiekty przechowują dane, takie jak współrzędne, pozycje i oczywiście odniesienia do innych sąsiednich obiektów. Umieszczę je wszystkie w strukturze danych i podejmę decyzje dotyczące tych informacji w „pętli gry”.

Chociaż jest to krótki przykład, nie jest dokładny we wszystkich sytuacjach. To tylko jeden sposób, w jaki czuję się naprawdę dobrze. Czy to źle?

Nie, w porządku.

Celem praktycznego programowania jest znalezienie rozwiązań, które prawdopodobnie będą przydatne w wielu podobnych projektach. Właśnie znalazłeś.

Nie możesz i nie powinieneś tworzyć różnych rozwiązań tylko dlatego, że są różne. Ale zdecydowanie powinieneś za każdym razem krytycznie przyjrzeć się swoim rozwiązaniom i zadać sobie pytanie, czy są one dobre, a może od tego czasu branża się rozwija i musisz odpowiednio dostosować się do nich.

Jeśli działa dobrze, nazwij to wzorem. Jeśli nie, ale nie wiesz lepiej, to antipattern ze złotym młotem.

Realistycznie w naszych codziennych zawodach mamy dość sporo podobnych problemów.

W takich sytuacjach trzymanie się tego, co wiesz, może być dobre. Widziałem więcej przykładów złych rozwiązań od ludzi wdrażających coś, czego nie rozumieli, że ktoś dobrze posługuje się nie idealną techniką.

Jeśli wiesz coś dobrze, istnieje duża szansa, że ​​możesz go dowolnie dostosowywać, a wdrożenie będzie solidne i skuteczne. Te rzeczy prawdopodobnie nie będą prawdziwe od pierwszych prób wprowadzenia nowych technik.

Ale drugą stroną jest to, że wszystko, co masz, to młotek, wszystko wygląda jak gwóźdź. Powinieneś robić rzeczy, aby uświadomić sobie alternatywy, a kiedy zbyt daleko posuwasz swoich ulubionych.

Może wybierzesz kilka nie pilnych / niekrytycznych zmian i wykorzystasz je, aby uzyskać dostęp do alternatywnych rozwiązań?

Dobre pytanie i muszę przyznać, że to też mnie prześladuje.

Kiedy to jest w porządku? Wykonaj analizę wydajności swojego kodu - jeśli zauważysz, że jesteś w O (log n) lub O (n) lub O (n log n) i jako taki problem można zmapować na znane struktury danych, na ogół jesteś w porządku.

Kiedy to nie jest w porządku? Twoja złożoność czasu lub przestrzeni wynosi O (n ^ 2) lub gorzej, lub problem z definicji jest NP kompletny. W takich sytuacjach musisz zastosować sporo heurystyki, zastosować wiedzę z innych dziedzin itp.

Szybki przykład: w projektowaniu układów wybór sposobu rozmieszczenia bramek w obwodzie przy minimalnej mocy jest NP-zupełny. Same wykresy nie przyniosą wiele dobrego, choć jest to konieczne. Musisz przeczytać dodatkowy materiał, czasem interdyscyplinarny i zastosować wiedzę w swojej dziedzinie. Na przykład algorytmy genetyczne (algorytmy naśladujące genetyczne krzyżowania i mutacje, zgodnie z definicją w biologii 101) mają wiele zastosowań w projektowaniu układów sprzętowych.

Niekoniecznie, jeśli to dobry sposób na ich rozwiązanie :)

Zwykle pracując nad „rozwiązaniem”, wybieram następujące rzeczy w kolejności:

• prostota ,
• wielokrotnego użytku ,
• i tylko ostatni występ .

Nie chodzi o to, że wydajność nie ma znaczenia: projektuję z myślą o wydajności, ale bez przesuwania jej zbyt daleko (więc jeśli muszę zrobić wywołania metody narzędzia, takiej jak StringUtils.isEmpty lub coś takiego w tym samym przepływie, wygrałem „ t mind). Jeśli potrzebna jest wydajność (uzasadnienie biznesowe lub problem z doświadczeniem użytkownika), wybieram inne podejście niż proste i wielokrotnego użytku. Być pragmatycznym.

O dziwo, kiedy koduję w C, bardziej zależy mi na wydajności niż podczas programowania w Javie ... Siła przyzwyczajenia :))

Dopóki problem zostanie rozwiązany w skuteczny sposób, nie musisz się martwić.

Myślę, że wykres to odpowiedni projekt do projektowania gier, który reprezentuje decyzje / wybory. Pamiętaj tylko, że prawdopodobnie można to udoskonalić i uczynić bardziej wydajnym, a może nie być najlepszym rozwiązaniem dla innych domen.

Jeśli to działa, jest OK.

Jeśli martwisz się nadmiernym poleganiem na jednej technice, spróbuj jako ćwiczenie wymyślić różne rozwiązane problemy, które uniemożliwiłyby rozwiązanie. Dodatkowe punkty, jeśli można uogólnić zmiany w celu zdefiniowania obszaru stosowalności zwykłego procesu.

Jeśli rozwiążesz problem, to dobrze. I nie ma znaczenia, w jaki sposób, dopóki nie spowoduje to więcej problemów.

„Sztuka twórcy” ma właściwie prawidłową odpowiedź, jeśli Twoim celem jest wytworzenie produktu. A jeśli twoja „fabryka” produkuje produkty, które spełniają, wtedy są fajne.

Ale...

Jeśli kiedykolwiek chcesz nauczyć się nowych (i potencjalnie lepszych) sposobów robienia rzeczy, musisz je zmienić. Spowoduje to awarie, ale tylko przez awarię faktycznie się uczymy. Dzięki tej nowej wiedzy możesz być w stanie stworzyć jeszcze lepsze i bardziej przekonujące oprogramowanie.

Jest to faktycznie poparte badaniami neurologicznymi. Więc proszę bardzo.