Co jeśli nie mam dobrych pomysłów na wdrożenie funkcji? [Zamknięte]

32

Pracuję nad własną aplikacją i utknąłem. Muszę wdrożyć funkcję, ale nie mogę znaleźć dobrego podejścia do jej wdrożenia. Myślałem o tym przez kilka dni i nie nadeszły żadne dobre myśli. Przeszukiwanie Internetu nie dało mi żadnej inspiracji.

Muszę iść dalej, ale chcę wiedzieć, co jest najlepsze:

  • Myśl więcej, czekaj dłużej i szukaj najlepszego podejścia
  • Przestań marnować czas i zacznij od złego projektu, obejmującego wszystko testami

Co myślisz? Jak powiedziałem wcześniej, pracuję nad własną aplikacją. Nie mam żadnych terminów, ale chcę też jak najszybciej zakończyć kodowanie aplikacji.

użytkownik21974
źródło
12
@gnat: Te inne pytania dotyczą sytuacji, w których pytający wiedzą już, jak zaimplementować niektóre funkcje w sposób czysty, ale mogą chcieć poświęcić dobry projekt, aby zostać „szybkim i brudnym”. To pytanie opisuje jednak inną sytuację, dotyczy ogólnie rozwiązywania problemów, gdy nie znajdziesz w ogóle sensu, aby zacząć, więc nie jest to duplikat IMHO.
Doc Brown,
Uwaga: jeśli aplikacja odniesie sukces, nigdy nie „zakończysz jej kodowania”, a funkcje i tak zostaną przeprojektowane. Chciałbym więc wdrożyć to najlepiej, jak mogę teraz.
ren

Odpowiedzi:

41

Oprócz rozmowy z ludźmi o nim (pytanie sugeruje, że nie ma kolegów na temat projektu), często uważają, że jest to dobre podejście do skoncentrowania się na rzeczy, można zrobić.

Zazwyczaj jest jakaś część kodu, którą muszę napisać. Rzeczy, których nie umiem jeszcze pisać, są następnie zastępowane kodami pośredniczącymi, które albo zwracają fałszywe wyniki, albo wykorzystują przybliżenie wystarczająco dobre, aby przetestować resztę.

To zapewnia produktywność. A zanim będziesz musiał zaimplementować brakujący element, masz interfejs. Napisałeś dużo kodu otaczającego problem, w tej samej domenie problemowej, co zwykle pomaga mi generować pomysły: wiesz dokładniej, co musisz wydrukować, i jakie inne dane wejściowe są dostępne, jeśli pomaga rozwiązać problem . Często wniosek jest taki, że brakujący element nie musi być tak wszechstronny, jak początkowo sądzono.

jdv-Jan de Vaan
źródło
6
Minusem pisania najbardziej ryzykownego, najmniej zrozumiałego kodu na końcu jest to, że możesz dowiedzieć się, że nie można rozwiązać problemu lub można go rozwiązać jedynie poprzez znaczące zmiany w architekturze programu, co prowadzi do dużo zmarnowanego wysiłku.
Rich Smith
1
Innym minusem tego podejścia jest czasem: „Mogę rozwiązać problem X. Pozostało tylko zrobić Y”. kiedy w rzeczywistości Y nie jest wykonalne, a prawdziwym rozwiązaniem jest Z.
Brian
@RichSmith, Brian: Zdarza się, choć rzadko kiedy mnie pytasz. Dzięki temu możesz lepiej zrozumieć, dlaczego brakująca część jest tak trudna, co poprawia twoje oceny. I nie sugerowałbym poświęcania tygodni pracy opartej na spekulacyjnym i arbitralnym podziale obowiązków.
jdv-Jan de Vaan,
jest jednak dyskusyjne, czy są to wady, czy nie. czy lepiej byłoby spędzić czas, nie badając problemu? lub siedząc przy zgadywaniu, co by zadziałało? Myślę, że dobrą praktyką jest pisanie szybkich prototypów, wypróbowywanie różnych rzeczy i szybkie zawodzenie. to jedyny sposób, aby wiedzieć na pewno i zdobyć doświadczenie w przyszłych podobnych sytuacjach
sara
14

Jeśli wyszukiwanie nie powiedzie się, zawsze możesz wdrożyć, używając pierwszego (niekoniecznie najlepszego) pomysłu, który masz, a następnie przebuduj go później, gdy znajdziesz właściwe podejście.

Jest to właściwe podejście, ponieważ nawet jeśli znajdziesz coś, co wygląda na dobry pomysł, może się później okazać zły. W tym czasie może być dobrze, ale później znajdziesz coś znacznie lepszego. Wtedy nadal będziesz musiał dokonać refaktoryzacji.

Robiąc to, pamiętaj o zaprojektowaniu i wdrożeniu w taki sposób, aby łatwo było go refaktoryzować. Jeśli zrobisz to poprawnie, będziesz musiał zmienić tylko problematyczną część i nie zaczynać od początku.

BЈовић
źródło
1
Wydaje się, że w tym poście założono, ale chciałbym dodać, że bardzo ważne jest, aby napisać kod w taki sposób, aby łatwo go ponownie rozłożyć na czynniki.
c_maker
@c_maker Tak, oczywiście. W przeciwnym razie nie ma sensu przepisywać wszystkiego później od zera. Dodam to do odpowiedzi. dzięki
BЈовић
10

Co powiesz na pytanie innej osoby? Na przykład możesz opisać swój problem tutaj lub, jeśli jest to bardziej problem z implementacją, na stackoverflow.com i poprosić o pomysły. Czasami już ci to pomoże, jeśli zaczniesz zapisywać problem, nawet jeśli nie uzyskasz dobrych odpowiedzi.

Doktor Brown
źródło
Jeśli problem stanowi interfejs użytkownika, istnieje także ux.stackexchange.com
Rob Church,
jeśli poprosisz o SO, odpowiedzi będą chronione prawami autorskimi na licencji Creative Commons, a w zależności od projektu kod ten może być bezużyteczny.
smcg,
2
Porady mogą być chronione prawami autorskimi? Z pewnością autor użyłby go jako samouczka, a nie kopiowania / wklejania?
grizwako,
@smcg: temat był omawiany tutaj: meta.stackexchange.com/questions/12527/... - Ale szczerze mówiąc, jeśli to naprawdę staje się problemem, myślę, że można to obejść zgodnie z sugestią GrizzLy.
Dok. Brown
@DocBrown IANAL, więc nie mogę powiedzieć na pewno, czy to się utrzyma, ale czasem dobrze jest zachować ostrożność.
smcg,
2

Kilka pomysłów:

  • Burza mózgów
    Napisz każdy głupi pomysł, który masz na głowie (na papierze lub tablicy). Skreśl te, które na pewno nie będą działać. Pisz dalej. Uwzględnij rozwiązania potencjalnie powiązanych problemów w świecie rzeczywistym. Np. Mieszanie farby, wbijanie gwoździ w ścianę lub wymiana oleju rozwiązuje rzeczywistość?
  • Poproś o pomoc
    Google, zapytaj tutaj, zapytaj znajomych maniaków itp.
  • Rozwiązać problem związany
    nie można rozwiązać ten problem, ale można rozwiązać znacznie prostsze? Czy równie skomplikowany, powiązany? Zrób to. Następnie dokonaj drobnych, indywidualnych zmian, aby zbliżyć swoje rozwiązanie do pożądanego rozwiązania.
  • Po prostu zacznij pisać od zewnątrz w
    Niezależnie od tego, czy Twój interfejs jest usługą internetową, stroną internetową, rodzimą formą, kamerą, klawiaturą, monitorem lub czymkolwiek innym, istnieje interfejs. Napisz kilka wierszy kodu / pseudokodu, aby interfejs działał. Użyj magicznych metod, które jeszcze nie istnieją. Rekurencyjnie rób to samo dla każdej nieistniejącej magicznej metody. Zoptymalizuj później.
svidgen
źródło
2

Nie ma nic złego w wybieraniu złego rozwiązania. Często po prostu nie wiesz wystarczająco dużo o problematycznej dziedzinie w tym momencie. Wybierając złe rozwiązanie, możesz przejść dalej i dowiedzieć się więcej o problemie. Wtedy nadal możesz wrócić i zrefakturować swoje pierwsze rozwiązanie.

Oliver Weiler
źródło
1

Zawsze staram się patrzeć na to z perspektywy użytkownika końcowego. Bardzo łatwo jest wyobrazić sobie „fajny” pomysł jako programisty, nad którym można spędzić całe lata pracując, co w rzeczywistości niewiele wnosi do Twojej aplikacji.

Idealnie chcesz zmapować wszystkie funkcje swojej aplikacji i nadać im priorytety zgodnie z korzyścią dla użytkownika końcowego, osobiście korzystam z MOSCoW , chociaż tak długo, jak długo zachowujesz tę samą metodę ustalania priorytetów, może to być tak proste, jak 1 - 5.

Po czym, jeśli nadal uważasz, że ta funkcja jest istotną częścią Twojej aplikacji, to jak już powiedzieli ludzie, zapytaj! Nie sądzę, że kiedykolwiek spotkałem problem, który ostatecznie nie został rozwiązany ani przez kolegę, ani przez tych miłych ludzi na Stackoverflow.

Mrk Fldig
źródło
Fajnie, bo jestem z Moskwy :)
user21974
Proszę bardzo, to jest znak!
Mrk Fldig,
1

Moim zdaniem: nigdy nie pisz kodu, który po prostu działa! W przyszłości refaktoryzacja powinna być bardzo trudna.

Jest to bardzo powszechne podejście dla programistów (i oczywiście szefów lub szefów). Słyszałem, że dużo czasu „po prostu działam” lub „naprawię później” (później, kiedy ??? nigdy!), Ale myślę, że jakość nie jest czymś, czego nie można uzyskać w trakcie realizacji projektu.

Sugeruję, żebyś przestał na chwilę zastanawiać się nad swoim problemem ... zrób coś innego, a czasem rozwiązania same się pojawią.

Btw, pytanie do kolegi to absolutnie świetny sposób na rozwiązanie twoich problemów.

Andrea Girardi
źródło