Kiedy powinniśmy przestać pracować i zrobić narzędzie?

Jako inżynier oprogramowania zawsze chętnie zdobywamy skuteczne narzędzia zwiększające naszą wydajność. W naszej codziennej pracy często nie jesteśmy zadowoleni z istniejących narzędzi i chcielibyśmy mieć lepsze sposoby, takie jak lepsza konfiguracja skryptu GDB, skrypt Vima i niektóre skrypty Python, aby nudne rzeczy były automatyczne.

Jest to jednak kompromis, ponieważ tworzenie narzędzi wymaga również czasu i energii. Nie zapewnia natychmiastowego zwiększenia wydajności. Jak zatem oceniasz, czy nadszedł czas, aby przerwać pracę i stworzyć narzędzia, które złagodzą Twój przyszły ból?

„Tworzę narzędzia”, gdy jedno z nich jest prawdziwe:

1. To mnie denerwuje
2. Ryzyko błędu ludzkiego w zadaniu jest zbyt duże

„Ryzyko” dla drugiej opcji nie musi być ogromne - koszt budowy jednego małego narzędzia jest zwykle niewielki, więc jeśli zaoszczędzisz tylko ryzyko ponownego uruchomienia 10-minutowej kompilacji raz w tygodniu, zwykle będzie to spłaca się bardzo szybko.

Staram się, aby narzędzia były tak małe, jak to możliwe - po prostu ułatw to zadanie, a może następnym razem poprawię.

Oznacza to, że za każdym razem naprawiasz największy ból i nie tworzysz napraw problemów, które tak naprawdę cię nie ranią.

Z doświadczeniem odkryłem, że ciężkie nacieranie na chrząknięcie jest zwykle najbardziej efektywne czasowo. Tworzenie narzędzia jest często kuszące. Rezygnuję z oporu, gdy:

• Narzędzie ma więcej niż jeden cel. Dobry szachista przy każdym ruchu osiągnął dwie rzeczy: zablokował kawałek przeciwnika i uwolnił biskupa. Początkujący prawdopodobnie potrzebuje dwóch tur, aby to zrobić. Podobnie zastanawiam się, czy narzędzie zrobiłoby tylko jedną rzecz, czy przy niewielkim dodatkowym wysiłku zrobić dwie, np. Pomóc naprawić niektóre pliki danych surowych, a także stworzyć sztuczne dane testowe.
• Przyszła przydatność. Może zaoszczędzić mi czasu na pracę w tym tygodniu, ale czy może zaoszczędzić mi lub komuś czas na nowy projekt w przyszłym tygodniu?
• To dobry czas na naukę nowego języka, biblioteki, techniki projektowania lub cokolwiek innego, i mam czas, aby to zrobić. Narzędzie to jest korzystnym efektem ubocznym robienia czegoś edukacyjnego, wykorzystując czas przeznaczony na edukację.
• Kiedy mamy poważne problemy z uruchomieniem rzeczy. Podobnie jak skoki spadochronowe bez spadochronu, naprawdę powinieneś poświęcić czas na zrobienie lub kupienie spadochronu. Jeśli nie możesz uzyskać żadnych znaczących wyników eksperymentalnych lub nowa aplikacja internetowa w ogóle nie będzie działać, musisz po prostu zatrzymać się i stworzyć lub kupić narzędzie do pomiaru tego, czego nie widzisz, prowadzić komponenty lub wymienić część system. Kiedy praca jest całkowicie rozłączona i potrzebuje narzędzia, nie dbam o przyszłe użycie lub wielokrotne użycie. Konieczność waży wystarczająco dużo.

Moja ogólna zasada jest taka, że ​​kiedy muszę coś zrobić po raz trzeci, nadszedł czas albo napisać mały skrypt, aby to zautomatyzować, albo przemyśleć moje podejście.

W tym momencie nie tworzę pełnowymiarowego „narzędzia”, tylko mały skrypt (zwykle bash lub python; perl też by działał, a nawet PHP), który automatyzuje to, co robiłem wcześniej ręcznie. Jest to w zasadzie stosowanie zasady DRY (lub zasady Single Source Of Truth, która jest w istocie tym samym) - jeśli musisz zmienić dwa pliki źródłowe w tandemie, musi być jakaś wspólna prawda, którą dzielą, i że prawda musi być rozłożona na czynniki pierwsze i przechowywana w jednym centralnym miejscu. Wspaniale jest, jeśli możesz rozwiązać to wewnętrznie przez refaktoryzację, ale czasami nie jest to wykonalne i właśnie tam pojawiają się niestandardowe skrypty.

Później skrypt może ewoluować w pełnowartościowe narzędzie, ale zwykle zaczynam od bardzo konkretnego skryptu z dużą ilością zakodowanych w nim rzeczy.

Nienawidzę pracy z pasją, ale również mocno wierzę, że jest to oznaka złego lub niewłaściwego projektu. Bycie leniwym jest ważną cechą programisty i lepiej być takim, w którym przechodzisz przez wiele czasu, aby uniknąć powtarzalnej pracy.

Jasne, czasami saldo jest ujemne - spędzasz trzy godziny na refaktoryzowaniu kodu lub pisaniu skryptu, aby zaoszczędzić godzinę powtarzalnej pracy; ale zazwyczaj bilans jest dodatni, tym bardziej, jeśli weźmie się pod uwagę koszty, które nie są bezpośrednio widoczne: awaria człowieka (ludzie są naprawdę źli w powtarzalnej pracy), mniejsza baza kodów, lepsza konserwowalność dzięki zmniejszonej redundancji, lepsza dokumentacja, szybsza przyszłość programowanie, czystszy kod. Więc nawet jeśli saldo wydaje się teraz ujemne, baza kodów będzie się dalej rozwijać, a to narzędzie, które napisałeś do generowania formularzy internetowych dla trzech obiektów danych, będzie nadal działać, gdy będziesz mieć trzydzieści obiektów danych. Z mojego doświadczenia wynika, że ​​równowaga jest zwykle szacowana na korzyść chrząknięcia, prawdopodobnie dlatego, że powtarzalne zadania są łatwiejsze do oszacowania, a tym samym niedoszacowane, podczas gdy refaktoryzacja, automatyzacja i abstrakcja są postrzegane jako mniej przewidywalne i bardziej niebezpieczne, a zatem przeszacowane. Zazwyczaj okazuje się, że automatyzacja wcale nie jest taka trudna.

A potem istnieje ryzyko, że zrobi się to zbyt późno: łatwo jest refaktoryzować trzy zupełnie nowe klasy obiektów danych i napisać skrypt, który generuje dla nich formularze internetowe, a kiedy to zrobisz, łatwo jest dodać 27 dodatkowych klas, które pracować również ze swoim skryptem. Ale jest prawie niemożliwe, aby napisać ten skrypt, gdy osiągniesz punkt, w którym istnieje 30 klas obiektów danych, każda z ręcznie napisanymi formularzami internetowymi i bez żadnej spójności między nimi (inaczej „wzrost organiczny”). Utrzymanie tych 30 klas za pomocą formularzy jest koszmarem powtarzalnego kodowania i półautomatycznego wyszukiwania z zastąpieniem, zmiana typowych aspektów zajmuje trzydzieści razy tyle, ile powinna, ale napisanie skryptu, aby rozwiązać problem, który byłby przerwą na lunch bez zastanowienia, kiedy projekt się rozpoczął, jest teraz przerażającym dwutygodniowym projektem z przerażającą perspektywą miesięcznego następstwa polegającego na naprawianiu błędów, edukowaniu użytkowników, a być może nawet rezygnacji i powrocie do stara baza kodów. Jak na ironię napisanie 30-klasowego bałaganu trwało dłużej niż czyste rozwiązanie, ponieważ przez cały czas mogłeś jeździć w wygodnym skrypcie. Z mojego doświadczenia wynika, że ​​zbyt późne zautomatyzowanie powtarzalnej pracy jest jednym z głównych problemów w długotrwałych dużych projektach oprogramowania. ponieważ mogłeś cały czas jeździć na wygodnym skrypcie. Z mojego doświadczenia wynika, że ​​zbyt późne zautomatyzowanie powtarzalnej pracy jest jednym z głównych problemów w długotrwałych dużych projektach oprogramowania. ponieważ mogłeś cały czas jeździć na wygodnym skrypcie. Z mojego doświadczenia wynika, że ​​zbyt późne zautomatyzowanie powtarzalnej pracy jest jednym z głównych problemów w długotrwałych dużych projektach oprogramowania.

Właśnie to zapamiętałem:

Problem polega na tym, że w rzeczywistej sytuacji nie można łatwo zmierzyć tych danych, aby wybrać odpowiednią komórkę w tabeli. I jak wspomniano w innych odpowiedziach, istnieją inne zmienne (ryzyko błędu, zadanie jest zbyt nudne, aby zrobić to choć raz, ...) należy dodać do równania.

Więc moja odpowiedź jest taka, że ​​to naprawdę zależy od sytuacji i nie można mieć nadziei na uzyskanie „poprawnej” odpowiedzi dla wszystkich sytuacji. W końcu życie byłoby nudne, gdybyśmy mieli książki kucharskie na wszystko.

To jest duży problem z mojego doświadczenia. Budowanie narzędzi jest zwykle pozostawione zmotywowanemu programistowi, który przerywa pracę nad budowaniem narzędzia. Często przeszkadza to w rozwoju, nawet jeśli zapewnia wartość. Budowanie narzędzi należy postrzegać jako integralną część procesu rozwoju.

Pamiętam, że uczestniczyłem w recenzjach kodu, w których błędy nagłówka skutkowałyby zaplanowaniem kolejnej recenzji. Wiele z nich mogło zostać wykrytych przez narzędzie. np. niepoprawna liczba bloków, brak wymagań, błędy formatowania. Moje narzędzie napisane w perlu wygenerowało nagłówek z dostarczonego kodu i zweryfikowało wymagania z bazy danych Oracle. Nie było to częścią naszego „Procesu”, więc w krótkim okresie budowanie narzędzia było postrzegane jako opóźnienie dostawy.

Cały zespół musi okresowo zatrzymywać się i sprawdzać, gdzie podejmowane są ręczne wysiłki, które można zautomatyzować poprzez tworzenie narzędzi.

Wszystkie pozostałe odpowiedzi są dobre, ale dodam jeszcze jeden powód, dla którego warto poświęcić czas na tworzenie małych narzędzi (i dostosowywanie .vimrc, .emacs itp.):

Czasami twórczo lub motywacyjnie „utkniesz w rutynie” i robienie czegoś, cokolwiek, „znów zacznie płynąć” (mieszanie metafor). Idealnie byłoby to coś, co produktywnie popycha projekt do przodu, ale jeśli jest to trochę styczne i to cię inspiruje, to też dobrze.

Być może nie patrzysz na pusty ekran, ale po prostu nie widzisz postępów w dużym zadaniu. W tej sytuacji odznaczenie czegoś namacalnego może powstrzymać cię od poczucia, że ​​nigdzie się nie dostaniesz.

Odmianą tego jest sytuacja, gdy ciągle myślisz o czymś, co powinno znaleźć się w „palniku wstecznym” - wystarczy poświęcić chwilę i zrobić to, by zmylić umysł i uwolnić cię od ponownego wykorzystania całej energii do głównego zadania.

To zależy od tego, co uważasz za tworzenie narzędzia. Prawdopodobnie robię ich mnóstwo w sposób, który inni deweloperzy uznaliby za niepoważny ... Ponieważ robię je dla prawie wszystkiego oprócz najbardziej podstawowych poleceń systemu plików.

Używam 2 uzasadnień do tego.

• To rozszerzenie zasady DRY. Jeśli chcemy coś powtórzyć, wysiłek manualny jest najmniej efektywnym wykorzystaniem zasobów ludzkich.
• Jest to skuteczny sposób na rejestrowanie tego, co zrobiłem, więc jeśli coś zbudowałem, to ja (lub ktoś inny) chciałbym powrócić do tego, jak to zrobiłem tygodnie lub miesiące później i przechowuje dziennik pracy z projektem.

Czasami stają się większymi narzędziami i zyskują funkcje interaktywne, ale jeśli nie, nadal mają wartość jako rekord.