Czy stosowanie nowych technik szkodzi wydajności? [Zamknięte]

Wydaje się, że wraz ze wzrostem doświadczenia z konkretnym zestawem narzędzi, z którymi musisz pracować, motywacja do wypróbowywania nowych rzeczy słabnie.

Kiedy byłem nowy w tej pracy programistycznej, wypróbowywanie nowych rzeczy, badanie online, sprawiło, że byłem bardziej produktywny, ponieważ często znajdowałem sposób (lub bibliotekę), który ułatwiał to zadanie, ponieważ struktura kodu już istnieje. Więc użycie czegoś nowego - zarówno dla mnie, jak i w kontekście danej bazy kodu - sprawiło, że jestem bardziej produktywny.

Teraz zauważyłem, że jest coraz więcej przypadków, w których dla danego problemu wiem , że prawdopodobnie istnieje lepsze rozwiązanie „tam” i znalezienie go prawdopodobnie poprawiłoby kod. Jednak biorąc pod uwagę moją dogłębną znajomość bazy kodu, zdecydowanie łatwiej jest korzystać z nieoptymalnych narzędzi, które mamy, i uzyskać rozwiązanie (w tym testy), niż znaleźć coś nowego i „lepszego” i „ulepszyć” bazę kodu.

Istnieje więc napięcie: „zrób to poprawnie” vs. „ przyzwoicie wykonaj pracę ”.

Czy to coś, co przytrafia się wielu programistom? Czy to znany konkretny problem? (Czy to w końcu prawdziwy problem?) Czy to rzeczywiście ma związek z rosnącym poziomem doświadczenia?

Aha i uwaga: nadal lubię swoją pracę i lubię ją utrzymywać. Po prostu wydaje się - zawsze interesujące! - część badań staje się mniejsza, gdy uczę się podstawy kodu i zestawów problemów, z którymi mamy do czynienia w naszej aplikacji.

Często ryzykowne jest próbowanie nowych rzeczy. Czasami wpadamy w kłopoty, ponieważ zwykle robimy dwie rzeczy:

1. Przeceniasz, jak przydatna jest fajna / nowa / sprytna rzecz. Widzimy fajny przykład, jakiś kod opublikowany online. Bardzo fajnie myślimy. Bardzo fajny! W XI można wykonać zadanie Y dziesięć razy szybciej. Jest wyraźnie lepszy. Nie widzimy jeszcze wszystkich „nieznanych niewiadomych”. Nie zaskoczyły nas problemy, które pomijają sprzedawcy nowej rzeczy. Nie mamy wystarczającej wiedzy specjalistycznej w tej nowej sprawie, aby zobaczyć miny lądowe czekające na drodze.

2. Nie doceniaj przydatności istniejących narzędzi / frameworka / oprogramowania / rzeczy. Często nie było nas, gdy obecny system był początkowo budowany. Nie doceniamy dokonanych delikatnych kompromisów. Łatwo jest grać w rozgrywki od poniedziałku do rana na istniejącym systemie, ale działa . Prawdopodobnie ma wiele dziwności z powodu bardzo specyficznych kompromisów między utrzymywaniem, działaniem i wydajnością. Tak, pewnie to dziwne. Być może, co najważniejsze, zespół jest ekspertem od obecnej dziwności i wie, jak obejść tę dziwność. Znają miny, pułapki i pułapki, których należy unikać. W rzeczywistości dzieje się tak właśnie dlatego, że widzimy wszystkie brodawki w obecnym sposobie robienia rzeczy, w które jesteśmy nawet zainteresowani grą z nowymi rzeczami.

Ale nie wypróbowanie nowych rzeczy i zachowanie zbyt konserwatywnego jest prawdopodobnie jeszcze bardziej niebezpieczne. Jasne, że musimy stąpać ostrożnie, ale jeśli nie wymyślimy, jak zbudować najlepszą pułapkę na myszy, nasi konkurenci nieco bardziej chętni do wypróbowania czegoś nowego pojawią się i wyrzucą tyłki! Działanie na rzecz konserwatystów i brak ewolucji może doprowadzić do nieuchronnego losu, szczególnie na konkurencyjnym rynku.

Tak więc musimy zrównoważyć utrzymywanie i wysyłanie bieżącej rzeczy z pewnym poziomem zabawnych / edukacyjnych eksperymentów z nowymi sposobami rozwiązywania problemów, pamiętając, że wiele z tych nowych sposobów jest ślepymi zaułkami, podczas gdy inne mogą się opłacić. IMO To dobry powód, dla którego wiele firm ma 20% czasu na zabawę nowymi rzeczami. Wiedzą, że wiele razy się nie udaje, ale wiele pomysłów, które wychodzą z 20% czasu, stają się gangsterami. Bez czasu na zabawę i eksperymenty możesz łatwo stagnować jako firma i naprawdę się popsuć.

To się zdarza cały czas . Powiedziałem to w innych postach, ale częściej niż nie, nie zajmujesz się tworzeniem eleganckiego kodu, zajmujesz się wysyłką produktu. W związku z tym trudno będzie znaleźć menedżera, który byłby skłonny przeznaczyć ngodziny na naprawę czegoś, co nie jest zepsute, a tak naprawdę (na koniec dnia) nie poprawia w znacznym stopniu komfortu użytkownika końcowego. Będziesz równie trudny do znalezienia menedżera gotowego przeznaczyć ngodziny na badania (bez wyraźnego celu końcowego) innego niż „prawdopodobnie jest coś lepszego” niż to, co się robi.

Powiedziawszy to, jeśli w Twojej aplikacji występują wąskie gardła, które odkryłeś za pomocą narzędzi do profilowania i takie, i możesz wyraźnie oszacować oczekiwane ulepszenie komfortu użytkownika, jakie przyniesie ich poprawienie, powinieneś (dość łatwo) uzyskać czas na wykonanie prac badawczo-rozwojowych pracuj nad ich optymalizacją, korzystając z technik dostępnych z różnych źródeł.

Myślę, że niektóre z nich sprowadzają się do ćwiczenia i pogłębionej wiedzy na temat skutecznego rozwiązywania niektórych problemów.

Kiedy jesteś nowy, wszystkie problemy są również nowe i musisz zbadać, jak je rozwiązać. Ale ponieważ rozwiązałeś ten sam typ problemu, potrzeba badań spada, ponieważ znasz skuteczne rozwiązanie tego problemu.

Następnie masz tendencję do badania nowych problemów lub tych, w których stare wypróbowane i prawdziwe albo już nie działają (były przestarzałe), albo powodują problem z wydajnością lub awarią. Gdy zaczniesz głębiej rozumieć złożony system, wiesz, że nie masz czasu realistycznie używać nowych technik za każdym razem, gdy się pojawią, a dzięki doświadczeniu odkryłeś, że często nowa technika nie żyje aż do szumu i stwarza więcej problemów niż rozwiązanych. Dzięki temu stajesz się mniej skłonny do korzystania z nowych narzędzi i technik, kiedy nie potrzebujesz ich do rozwiązania problemu.

Ale mniej skłonny nie powinien oznaczać, że przestaniesz się uczyć lub nigdy nie użyjesz nowej techniki, tylko że bardziej rozsądnie podejmiesz, kiedy są one odpowiednie.

Oto kilka szczegółów:

1. Są terminy : programiści powinni wcześniej mieć dostęp do wszystkich niezbędnych szczegółów narzędzi, których używa. Czytanie strony internetowej, znajdowanie nowych fajnych rzeczy, a następnie używanie jej w środowisku produkcyjnym jest dużym nie-nie. Po prostu nie masz wystarczającego doświadczenia z narzędziem, a co ważniejsze, po prostu nie masz czasu, aby zacząć uczyć się czegoś nowego. Jeśli chcesz jakieś fajne nowe rzeczy, naucz się ich pół roku lub roku przed użyciem.
2. Upewnij się, że znasz go poprawnie przed użyciem : Niektóre fajne nowe narzędzia mogą być fajne w użyciu, ale wyszukiwanie rozwiązań i używanie ich bez odpowiedniego uczenia się może być bardzo złe. Po prostu nie masz wystarczającego doświadczenia. Jeśli potrzebujesz google, aby to rozgryźć, oznacza to, że po prostu nie znasz go wystarczająco dobrze, aby naprawić, gdy zepsuje połowę systemu.
3. Używanie najnowszych rzeczy nie robi tego poprawnie : nowe rzeczy nie są sprawdzoną technologią. W przyszłym roku technologia prawdopodobnie całkowicie zniknęła, a ty jesteś jedynym na świecie, który już z niej korzysta. Wszyscy inni zauważyli, że to po prostu nie działa. Uniknięcie najnowszej srebrnej kulki wymaga ciężkiej pracy, ale warto.
4. Skoncentruj się na technikach, które są twoją podstawową wiedzą : każdy programista zna tylko niewielką część całej wiedzy programistycznej dostępnej na świecie. Część, w której programista jest wystarczająco wygodny w użyciu, jest jeszcze mniejsza. Część, która faktycznie działa, jest jeszcze mniejsza. Używaj tylko wiedzy, którą właściwie się nauczyłeś i wiesz, że to działa. To przyspiesza programowanie i daje lepszy kod.
5. Nie zmieniaj go w nieskończoność : Idealny kod jest dobrym celem, ale nie oznacza to, że najpierw piszesz bzdury, a następnie w nieskończoność dostosowujesz go, aby był coraz lepszy. Napisz to doskonale za pierwszym razem, wykorzystując całą swoją dobrą wiedzę. Zaufaj sobie. Nie ufaj światu. Nikt inny nie wie dokładnie tego samego, co ty. Ich opinia nie ma znaczenia. Jesteś programistą, musisz sprawić, by działał. Świat nie może tego dla ciebie zrobić. Po zakończeniu przestań. Nie dotykaj go, dopóki ktoś nie narzeka.
6. Poświęć czas na naukę nowych rzeczy : każdy musi stale uczyć się nowych rzeczy. Od tego zależy nasza przyszłość. Po prostu nie używaj go! Naucz się nowych rzeczy, ale nie używaj ich, dopóki nie upewnisz się, że to naprawdę działa. Otrzymasz szansę, aby użyć go w przyszłym roku, gdy będzie to sprawdzona technologia. Albo po prostu zapomniałeś, jak wszyscy inni - pozostają tylko dobre rzeczy ...
7. Nie trać dobrych rzeczy : po pomyślnym zbudowaniu dużych systemów i naprawieniu w nich wszystkich problemów oraz nauczeniu się kilku fajnych technik, najgorsze, co możesz zrobić, to porzucić tę wiedzę i poszukać czegoś nowego. Wiesz już, jak to działa, jakie są problemy i jak je rozwiązać. Wyrzucenie go to tylko strata czasu.
8. Bądź na bieżąco z nową technologią : jeden z nowych systemów odniesie sukces. Ma coś zasadniczo lepszego niż cokolwiek innego na rynku. Po prostu nie wiesz, która to srebrna kula. Jeśli nie zdążysz go znaleźć na czas, twoja wiedza będzie nieaktualna. Świat może sprawić, że stracisz wszystkie dobre rzeczy, usuwając dostęp do starych systemów.

Tak, tak się stało. Zwykle musisz przeprowadzić analizę ryzyka, ile czasu zajmie nauczenie się nowej techniki, i czy możesz odzyskać i zastosować starszą technikę, jeśli nowa technika nie spełni oczekiwań. Wolę uczyć się nowych technik, kiedy tylko mogę, ale kiedy presja jest coraz większa i nie mogę sobie pozwolić na spędzanie czasu na wypróbowywaniu nowych rzeczy, które mogą zawieść, trzymam się sprawdzonych metod.

Ogólnie rzecz biorąc, najlepszy czas na naukę nowych technik znajduje się na początku nowego projektu. Zazwyczaj nie ma zbyt dużej presji, a jeśli znajdziesz coś nowego, co działa dobrze, możesz łatwo zintegrować go z resztą projektu, idąc naprzód. Najgorszy czas, aby spróbować i nauczyć się nowych rzeczy jest ostatni kilka szalonych tygodni przed wielkim wdrożenia.

Tak, nowe rzeczy obniżają produktywność

Tak oczywiście. Nawet w najlepszym przypadku nowe rzeczy wymagają dodatkowego czasu, ponieważ są nieznane. Często może to kosztować dużo więcej czasu.

Nie, nowe techniki mogą poprawić wydajność

Każda nowa technika, która pozwala łatwiej wyrazić rozwiązanie, poprawi Twoją wydajność. Może to być tak proste, jak przejście z dużych if-elseifwarunków do tabeli wysyłkowej.

Tak, może to zaszkodzić wydajności. Moja była została poproszona o wykonanie pewnego nudnego zadania przetwarzania danych, więc zdecydowała, że ​​lepiej będzie napisać długi program do obsługi danych, a następnie uruchomić go - co rozwiąże problem w kilka sekund.

Oczywiście zajęło jej to tydzień, ale problem został rozwiązany w kilka sekund później.

Myślę, że to samo dotyczy twojego pytania: tak, możesz zwiększyć produktywność, ucząc się nowych rzeczy, ale nadal lepiej byłoby wykorzystać swoją wiedzę do zadania i ogólnie szybciej go wykonać. Kogo obchodzi znalezienie i nauka nowej biblioteki, jeśli możesz napisać własną w krótszym czasie.

Nie zapominaj również, że często przyzwoite wykonanie przy użyciu istniejących narzędzi jest lepszym rozwiązaniem niż wkładanie nowych rzeczy. Za każdym razem, gdy dodajesz nowe, zwiększasz wymaganą powierzchnię konserwacyjną, co z kolei spowalnia wszystkich innych (i może sprawi, że Twój kod będzie dość niechlujny - myślę o warstwach „nowej” technologii, które z czasem przeszły do ​​przeszłości, ale wciąż są w naszym kodzie, co powoduje, że wszystko jest okropne. Patrząc wstecz, lepiej byłoby po prostu użyć starych metod C zamiast dodawać cały ten COM i cały VB i cały .NET, a teraz także wrzucanie HTMLa)