Czy zapisywanie notatek, myśli, algorytmów, decyzji podczas kodowania i konserwacji jest normalne / dopuszczalne? [Zamknięte]

Niektórzy ludzie mają ten problem, że nie mogą myśleć bez słów. A spisanie ich myśli i decyzji jest najskuteczniejszym sposobem postępowania.

Więc - czy to normalne i dopuszczalne, że zapisuję swoje myśli i decyzje w pliku Notepad ++ podczas kodowania?

Czasami powinno to być dopuszczalne, np. Przy odtwarzaniu dokumentacji technicznej lub wnioskowaniu na temat bardziej złożonych algorytmów, ale czasem może być dziwne, np. Kiedy rozważam opcje projektowania i próbuję dokonać oceny.

Wpływ tej praktyki na wydajność jest niejasny. Z jednej strony - rozumowanie za pomocą wewnętrznych słów może być szybsze niż za pomocą słów pisanych. Z drugiej strony - bardziej złożone problemy wymagają pisania. Poza tym, jeśli utkniesz z większą liczbą opcji projektowych, to uczucie jest lepsze, gdy decyzja jest zapisana, więc podnosi morale.

To nie tylko normalne, to dobry pomysł.

Jest słynny cytat

„Daj mi sześć godzin na ścięcie drzewa, a pierwsze cztery spędzę na ostrzeniu siekiery”.

Poświęcenie czasu na uporządkowanie myśli i zaplanowanie pracy przed kodowaniem to czas dobrze spędzony. Zapisanie tych myśli na papierze da ci czas na zastanowienie się nad swoimi planami, ich krytykę i uporządkowanie w sposób, który byłby bardzo trudny, gdyby wykonano je tylko „w twojej głowie”.

Tak, jest to całkowicie dopuszczalne i normalne.

Dokumentowanie procesu decyzyjnego jest często cenne przy ponownym odwiedzaniu kodu, aby pomóc ustalić, dlaczego kod został napisany w określony sposób.

Te uwagi mogą być zawarte bezpośrednio w kodzie jako komentarze, jeśli są wystarczająco krótkie. Rozszerzony komentarz jest często przechowywany jako część zewnętrznego dokumentu projektu technicznego.

To cholernie dobry pomysł. Aż do momentu, gdy stanie się sposobem na zwlekanie.

Kluczem jest równowaga. Uważam, że jestem najbardziej produktywny, jeśli nie zapakuję się w siebie, ale będę wychwytywać pomysły w miarę ich pojawiania się.

Jeśli grinduję na niskim poziomie i pojawia się pomysł na wysokim poziomie, po prostu zapisuję go i wracam do niego później.

Planowanie pracy jest dobrym pomysłem, ale chyba że musisz się komunikować lub zaprezentować publiczności, najlepszym narzędziem są pióro i serwetka. Uchwyć pomysł. Nie trać czasu na upiększanie.

W każdej sytuacji zawodowej jest to nie tylko „normalne i dopuszczalne”, jest obowiązkowe. Typowy cykl programowania składa się z dwóch faz dokumentacji, zanim jeszcze rozpocznie się kodowanie:

1. Dokument wymagań funkcjonalnych: zazwyczaj napisany przez analityków biznesowych, określający funkcjonalność, która ma zostać zaimplementowana.

2. Szczegółowy projekt dokumentu: który jest właściwie tym, o czym mówisz, tylko bardziej formalny, określający rozkład funkcjonalny (faktoring) systemu, algorytmy itp. Niektóre z moich (bardzo) starych są w trybie online, np . To .

W przypadku mniej formalnej dokumentacji 110% zgadzam się z wcześniejszymi uwagami na temat komentarzy wewnętrznych. To jedyna droga; tak czy inaczej, wszystko inne w końcu się gubi. Ale schludne i przemyślane komentowanie w wierszu to osobna umiejętność kodowania, rozwijana poprzez wysiłek i praktykę, jak każda inna umiejętność. Możesz zobaczyć niektóre z moich (bardzo) starych rzeczy, np . To . Ten styl może ci się nie podobać. Polecam najpierw znaleźć dobrze skomentowany kod w stylu, który ci się podoba, i emulować go we własnym kodzie. Po chwili dostosuj go według własnego uznania.

Świetnym miejscem na umieszczenie tego rodzaju informacji jest bezpośrednio w komunikacie zatwierdzenia systemu kontroli wersji (SVN, git itp.). W ten sposób możesz zobaczyć zmiany i ich uzasadnienie w tym samym miejscu.

Oprócz innych dobrych odpowiedzi dodam, że często zapisuję swoje przemyślenia na temat tego, co próbuję zrobić.

Wyrażanie się w wyrażaniu tego, co próbuję zrobić, pomaga mi w realizacji założeń, założeń i / lub wymagań, które niekoniecznie się spełniają.

To wskazuje na alternatywne rozwiązania, które z kolei mogę lepiej przemyśleć; to pisanie pomaga uratować moje miejsce, jeśli pomyślę o czymś innym.

Robię szybkie notatki, aby zbadać oddech i głębię, więc działa rekurencyjnie, pomagając mi opracowywać, nawigować i oceniać drzewo rozwiązań, tworzyć kopie zapasowe, eksplorować, odkrywać, realizować i podejmować decyzje.

Zapisywanie wszystkiego, co może zaoszczędzić czas / (nowych) członków zespołu, to czas, który dobrze spędzasz. Tylko upewnij się, że jest to coś, czego ktoś może potrzebować później i nie zastanawiaj się, chyba że jest to naprawdę długoterminowy projekt.

Nie powinno to również zająć czasu. Jeśli spędzasz czas na myśleniu, możesz zapisać swoje przemyślenia od 1 do 1 (o ile będą one / mogą być dla kogoś przydatne).

Prawdziwym problemem może być przemyślenie tego, co piszesz. To, że piszesz, nie oznacza, że ​​musisz przestrzegać już istniejącego formatu lub przejść całą procedurę tworzenia pełnej dokumentacji.

Jeśli wybierzesz między nie zapisywaniem niczego a pisaniem nieformalnych notatek w notatniku, po prostu napisz nieformalne notatki.

Mówicie: „Niektórzy ludzie mają ten problem, że nie potrafią myśleć bez słów. A spisanie myśli i decyzji jest najskuteczniejszym sposobem na kontynuację”.

Jeśli spisanie myśli i decyzji jest najskuteczniejszym sposobem postępowania, dlaczego nie byłoby normalne i dopuszczalne, aby postępować w najbardziej efektywny sposób? Robisz to, co dla Ciebie najlepsze. Może nie być to, co działa najlepiej dla kogoś innego. W takim przypadku nie pozwalasz komuś innemu powiedzieć, co jest dla Ciebie najlepsze, i nie mówisz mu, co jest dla niego najlepsze. Każdy robi to, co dla niego najlepsze.

Ludzie mogą jednocześnie trzymać w głowie tylko siedem „rzeczy”. To jest powód dla siedmiocyfrowych numerów telefonów. Aby programiści mogli efektywnie pracować, muszą znaleźć jakiś system, który odciąży rzeczy z pamięci i szybko je w razie potrzeby w razie potrzeby odzyska. Robienie notatek jest oczywistym i bezpośrednim sposobem, ale każdy, kto pracuje nad czymś umiarkowanie złożonym, musi to jakoś zrobić . Po sparowaniu programu z kimś, poszukaj jego metody.

Jednym z powszechnych sposobów jest rozwój oparty na testach. W tej metodologii piszesz jeden test zakończony niepowodzeniem, piszesz wystarczającą ilość kodu, aby przejść ten test zakończony niepowodzeniem, a następnie poprawiasz kod, aby wyglądał ładniej, zachowując wszystkie istniejące testy. Ta metodologia utrzymuje wszystkie „notatki” zakodowane w testach. Ludzie mogą w ten sposób pracować bardzo szybko, nie robiąc notatek, ponieważ koncentrują się na kolejnym teście.

Innym powszechnym sposobem jest po prostu zapisywanie notatek w kodzie jako komentarzy lub kodów pośredniczących, a następnie stopniowe zastępowanie ich prawdziwymi. Tak zwykle piszę algorytmy. Mój pierwszy szkic jest tylko główną funkcją z pseudokodem, a następnie stopniowo wypełnia coraz głębsze poziomy abstrakcji.

Nie przejmuj się używaniem dowolnej metody, ale spróbuj zauważyć, jakich metod używają Twoi „wydajni” koledzy. Mają te same ludzkie ograniczenia, co ty.