Jak napisać skuteczny kod pomimo dużych terminów

Pracuję w środowisku, w którym mamy wiele projektów o ściśle określonych terminach realizacji. Rozmawiamy nawet bezpośrednio z klientami, więc wykonanie zadań i szybkie jest koniecznością.

Moim problemem jest to, że zawsze piszę kod pierwszego rozwiązania, które przychodzi mi do głowy, co oczywiście uważałem za najlepsze w tym momencie. Zawsze kończy się to brzydko i później zdałem sobie sprawę, że są lepsze sposoby, ale nie stać mnie na zmianę z powodu ograniczeń czasowych.

Czy są jakieś wskazówki, dzięki którym mogę sprawić, by mój kod był skuteczny, a jednocześnie dostarczał na czas?

Jeśli kod wymaga konserwacji, wyjaśnij, że potrzebny jest dodatkowy czas, aby kod był łatwiejszy w utrzymaniu, co pozwoli zaoszczędzić pieniądze na wewnętrznej bazie danych. Innymi słowy, ustaw kod zarządzalny jako wymaganie.

Jeśli nie przejmują się tym, nie sądzę, że musisz robić coś innego, oprócz ciągłego doskonalenia się i robienia wszystkiego, co możliwe, aby w miarę możliwości stosować najlepsze praktyki.

Okej, to może brzmieć trochę szalone, ale przysięgam, że to działa. To nie tylko programowanie, to przepis na większą kreatywność, koncentrację i pamięć:

• Odżywiać się zdrowo
• Medytować
• Prześpij się (7-9 godzin w zależności od osoby)
• Drzemaj, gdy twój mózg jest zamazany
• Idź spać z nierozwiązanym problemem. Nie kończ dnia, gdy wszystko jest kompletne. Pozostaw jedno trudne zadanie do wykonania - twoja podświadomość jest niezwykle skuteczna.
• Noś wygodne ubrania
• Ćwiczenie
• Poświęć trochę czasu na rutynowe ćwiczenia mentalne - sudoku (nie zaprogramowane), krzyżówki, ćwiczenia matematyczne, zagadki przestrzenne itp.
• Wykonaj na sobie obiektywne eksperymenty, aby sprawdzić, które z twoich zachowań wpływają na wydajność (potrzebujesz niezawodnego sposobu przetestowania wydajności, aby to zadziałało).
• Zadbaj o swoje duchowe zdrowie
• Bawełniane majtki
• Zadbaj o swoje zdrowie seksualne
• Znajdź czas dla swojej rodziny i przyjaciół
• Zdobądź biegłość w czymś poza zawodem (muzyka, gotowanie, sport itp.) I utrzymuj kontakty towarzyskie z innymi ludźmi, którzy robią to samo
• Dla niektórych osób zwierzę jest koniecznością

Zanim się zorientujesz, zobaczysz znaczną poprawę wydajności programowania i jakości rozwiązań (nie wspominając o ulepszeniach w innych obszarach).

Źródła:

1. Twój cudowny mózg: maksymalizuj siłę mózgu, popraw swoją pamięć, popraw nastrój, popraw swoje IQ i kreatywność, zapobiegaj starzeniu się umysłu i odwróć go
2. The Quantified Self
3. Seth Roberts - w Scientific American

Jest to sprzeczne z intuicją, ale prawdopodobnie musisz zwolnić. Wdrażając pierwsze, które przychodzi na myśl, tworzysz dla siebie wiele dodatkowej pracy. Przez „w dół drogi” mam na myśli już tego samego popołudnia. Problemy, które sam sobie tworzysz, nie rozwijają się miesiącami. Rozważ swoje opcje. Pisz mniej i rozważ więcej. Nawet w krótkim projekcie przekonasz się, że mniej kodowania może faktycznie cię przyspieszyć.

Jeśli Twoi klienci skupiają się w określonych branżach, spróbuj budować projekty, które zawierają komponenty wielokrotnego użytku. Nie pisanie kodu jest szybsze niż pisanie.

Z perspektywy klienta pachnie to trochę jak „ Szybko, dobrze i tanio, wybierz dwa ”. Oczywiście wszyscy chcemy od razu tego, czego pragniemy, ale Twoi klienci muszą rozważyć, czy jest to najlepsze na dłuższą metę. Spróbuj wyrazić kompromisy i pomóc im w podejmowaniu dobrych decyzji.

Poszukaj innej pracy.

Przekonasz się, że po około 6 miesiącach. do roku, w którym nie będziesz dumny z pracy, którą wykonałeś. Co więcej, nie będziesz tracić czasu na naukę nowych technik, technologii lub ram - więc po roku nie będziesz w stanie nadążyć za nowymi technologiami. Po roku będziesz gorszym programistą w stosunku do rynku niż na początku.

Jeśli minie zbyt dużo czasu (powiedzmy kilka lat lub więcej), będziesz miał bardzo trudny czas, aby zostać zatrudnionym gdziekolwiek, z wyjątkiem takich szybkich zadań, w których jakość kodu nie jest doceniana, tylko szybkość.

To powiedziawszy, jako doświadczenie uczenia się w „prawdziwym świecie”, jest coś, co można powiedzieć o szybkim środowisku, ale powiedziałbym, że około 6 miesięcy. wystarczy. Poza tym powinieneś spróbować skontaktować się z kilkoma rekruterami i poszukać lepszego miejsca. Będziesz o wiele szczęśliwszy, szczery.

Z punktu widzenia klientów wydajność kodu może nie być tak istotna i może być dość droga. W dzisiejszych czasach czas poświęcony na tworzenie kodu musi oszczędzać godziny procesora, aby usprawiedliwić godzinę czasu. W przypadku większości programów wydajność nie jest tak istotna. Nawet w tych miejscach większość kodu nie musi być tak wydajna. Biorąc pod uwagę wybór, wolę raczej łatwe w utrzymaniu rozwiązanie niż bardziej wydajny, trudniejszy w utrzymaniu kod.

Poświęcenie czasu na zaplanowanie kodowania przed rozpoczęciem może dać ci czas na ocenę rozwiązań i rozważenie alternatywnych rozwiązań. Powinno to zaoszczędzić czas na kodowaniu i testowaniu. Przekonałem się, że często prostszy kod jest bardziej wydajny.

Ułóż kod w czystości, używając tyle wierszy, ile potrzeba. Złożony kod może dezorientować optymalizator i może powodować spowolnienie kodu. Nowoczesne kompilatory bardzo dobrze optymalizują kod, ufaj, że wykona swoją pracę.

Zaakceptuj, że wystarczająco dobre jest wystarczająco dobre. Kiedy wymyślisz bardziej efektywne podejście, zrób notatkę dla siebie. Jeśli masz trochę czasu, porównaj kilka bardziej wydajnych projektów z tymi, które zaimplementowałeś. Wypróbuj je zarówno w małym (tylko wykonany kod), jak i dużym (program, który ich używa). Dzięki temu poczujesz, kiedy bardziej efektywne podejście jest właściwe.

Wiele osób uważa przedwczesną optymalizację za złe podejście. Wdrożenie może być kosztowne. Niestety wiele przedwczesnych optymalizacji nie jest tak naprawdę wydajnych jak zoptymalizowany przez nich kod. Aby właściwie zoptymalizować kod, musisz go oprzyrządować przed zmianą i po niej, aby sprawdzić, czy naprawdę poprawiłeś wydajność.

Studiuj techniki, które pomogą Ci pisać czystszy kod o niskim sprzężeniu i wysokiej spójności. W wielu przypadkach zmniejszenie złożoności zwiększa wydajność. Techniki, które pomogą Ci zminimalizować błędy, które musisz naprawić podczas programowania, pomogą Ci szybciej dostarczać. Może to zwolnić czas na przetestowanie alternatywnych metod.

Robert omówił najważniejsze aspekty.

Pracowałem w takich środowiskach, w których kod nie (nie może) żyć dłużej niż sześć miesięcy. Jest kilka podstawowych zasad, o których mogę myśleć:

1. Używaj bibliotek open source, rozwiązań innych firm itp.,. Zaangażowane uczenie się jest opłacane przez mniej konserwacji i debugowania. Jeśli jednak utkniesz w bibliotece z błędami, jesteś skazany.
2. Ściśle upewnij się, że Twój projekt jest rozszerzalny. Obowiązkowy wymóg: większość pracy stanowi ulepszenia, a nie budowanie nowych funkcji.
3. Twórz rygorystyczne plany testów. Uzyskaj kontrolę jakości lub zautomatyzuj testy, aby zapewnić testy regresji.
4. Używaj inteligentnych narzędzi - IDE, narzędzi do generowania kodu itp.,.
5. Utrzymuj wszystko tak konfigurowalne, jak to możliwe. (Druga strona to zwiększone wysiłki testowe)
6. Popraw swoją szybkość pisania :-)

W fazie projektowania rozmawiaj z kolegami .

Omów swój projekt i sposób, w jaki chcesz to zrobić, i poproś, aby przeanalizowali twoje decyzje. Jeśli i kiedy wszyscy zgodzicie się co do tego, co jest inteligentne, otrzymacie znacznie zdrowszą konstrukcję.

Ćwiczyć. Ćwicz pisanie dobrego kodu, aż stanie się on drugą naturą. Następnie szybciej ćwicz kodowanie. Następnie lepiej ćwicz kodowanie. A kiedy skończysz ... poćwicz trochę więcej.

Moim problemem jest to, że zawsze piszę kod pierwszego rozwiązania, które przychodzi mi do głowy, co oczywiście uważałem za najlepsze w tym momencie.

Nie, to nie twój problem. To jest cnota. Robi najprostszą rzecz, która może działać. Ale działa tylko w połączeniu z refaktoryzacją. Jest to ciągły proces: robienie następnej najprostszej rzeczy, która może zadziałać w kółko, dzięki czemu Twój system jest zawsze wyrazem twojego obecnego zrozumienia przestrzeni rozwiązań.

Problem polega na tym, że masz kierownictwo, które nie rozumie prawdziwych kosztów cyklu życia oprogramowania. 90% tych kosztów to utrzymanie, a nie wstępne wdrożenie. Testowanie i refaktoryzacja to nasze najlepsze narzędzia do zmniejszania całkowitego kosztu cyklu życia oprogramowania. Jeśli Twoi menedżerowie nie pozwolą ci robić tych rzeczy, są nieodpowiedzialni i muszą zostać przeszkoleni. Lub musisz znaleźć nową pracę.

Wreszcie: jak powiedziałem wcześniej *, musisz nauczyć się mówić „nie” .

* Jak kodować według bardzo napiętego harmonogramu?

Jeśli ustalą zakres i czas, wszystko, co możesz zrobić, aby termin ten upłynął, to jakość spadku.

Jeśli to możliwe, obniż jakość zewnętrzną, widoczną dla interesariuszy, nie kompromisuj się jakością wewnętrzną, która szkodzi twojemu mieszkaniu w bazie kodu.

Naprawdę nie sądzę, że samodoskonalenie pomoże ci w tej sytuacji. Jeśli cokolwiek, to przykro mi to mówić, zwykle jest to asertywność.

Postaraj się postawić stopę w drzwiach, gdy praca jest szacowana. Jak twój szef może oszacować, ile czasu musisz zrobić?

Dokonaj wyboru dla swojego szefa i / lub klienta. Zbyt często sami programiści decydują się na obniżenie jakości bez komunikowania się. Późne projekty / prace są bardzo powszechne i zazwyczaj „zarządzane”. Działaj na czas, ostrzegaj ludzi, jeśli zbliża się termin.

Nie mogą skrócić zakresu ani przesunąć terminu, jeśli nic im nie powiesz.

Jeśli zamierzasz iść na kompromis w sprawie jakości w jakiejkolwiek formie, postaraj się, aby była to ich decyzja. Daj im rzeczy na wagę.

Niektóre rzeczy, które tylko TY możesz zdecydować. Jeśli tylko masz to działać. Ale to jest bardzo nie do utrzymania. Być może nie jesteś pewien, czy to działa we wszystkich przypadkach. Nie mów nikomu, że skończyłeś. Ponów to. Bardzo często jest to decyzja, którą tylko Ty możesz podjąć. Albo dlatego, że problem jest bardzo czasochłonny, albo masz nietechnicznego kierownika.

Czasami jest to częścią etyki pracy, czy po prostu zszywałbyś pacjenta bez mycia rąk, ponieważ „nie ma czasu”?

Przede wszystkim pamiętaj: nie ma później.

Jestem programistą .Net pracującym nad aplikacjami internetowymi.

Zacząłem robić -

Jeśli jest to kod C #, najpierw próbuję napisać ten kod w LinqPad (jeśli to możliwe).

Jeśli jest to kod JavaScript, najpierw piszę ten kod i testuję go w jsfiddle / jsbin (jeśli to możliwe).

Przekonałem się, że pomaga to w jakości kodu, ale mnie nie spowalnia (w kilku przypadkach stwierdziłem, że jest szybszy).