Etykieta Open Source

Zacząłem pracować nad moim pierwszym projektem open source na Codeplex i natknąłem się na okropny kod. (Dowiedziałem się, że C # nadal ma instrukcję „goto”). Zacząłem dodawać funkcje, których chciał „właściciel”, a po zbadaniu bazy kodu i zobaczeniu, jaki to bałagan (np. Używając „goto”), chciałem to wyczyścić trochę. Ale jestem trochę zaniepokojony i dlatego zwracam się do was wszystkich: czy to właściwa etykieta, aby „naprawić” „zły kod”, czy powinienem pozwolić i pracować nad nowymi funkcjami? Jak powiedziałem wcześniej, jestem nowy w całej scenie OSS i pracuję w zespole w ogóle, więc nie chcę tego popsuć.

Możesz to zrobić, jeśli jesteś skromny i nic nie psuje . Nie możesz ominąć formatowania kodu i wprowadzania błędów. Czy ma dobre testy jednostkowe? Jeśli nie, zacznę od dodawania testów jednostkowych, a następnie naprawię strukturę później.

Celem oprogramowania typu open source jest zwrócenie większej uwagi na projekt i jego ulepszenie. Obejmuje to ulepszanie kodu. To powiedziawszy, dobrą formą jest reklamowanie na liście tego, co zamierzasz zrobić. Możesz dostać odepchnięcie lub kilka + 1-ek. Te gotostwierdzenia mogą tam być, ponieważ oryginalny autor nie mógł wymyślić lepszego sposobu na wykonanie zadania. Jeśli zostaniesz odepchnięty, dobrze jest otworzyć okno dialogowe, aby dowiedzieć się, skąd pochodzi presja. Staraj się, aby nie było to osobiste i staraj się rozwiązywać problemy.

Podsumowując, testy jednostkowe mówią głośniej niż dogmat. Jeśli możesz udowodnić, że kod będzie działał nieprawidłowo w pewnych przypadkach tak, jak jest teraz, albo dostaniesz kciuki do góry, albo oryginalny autor wejdzie i naprawi wszystko.

Pamiętaj, że w otwartym kodzie społeczność jest ważniejsza niż kod. Jeśli nie ma społeczności (zarówno użytkowników, jak i programistów), nie ma projektu.

Ludzie, którzy zazdrośnie bronią swojego kodu, na ogół nie wysyłają go do świata, aby to zbadał, a jeśli tak, społeczność wokół niego nie potrwa długo. Bądź taktowny, ale nie martw się, że zranisz uczucia.

Po prostu powiedz im, co chcesz zrobić, zanim zainwestujesz w to zbyt dużo czasu. Czasami istnieją historyczne powody rzeczy, które nie są oczywiste. Powodem, dla którego gotos jest unikany, jest to, że mogą tworzyć nieprzewidziane ścieżki w kodzie. W związku z tym niebezpieczeństwo usunięcia gotos polega na tym, że nie zauważysz jednej z korzystnych ścieżek i przypadkowo pominiesz ją w reaktorze.

Z drugiej strony, być może pierwotny autor po prostu nie mógł wymyślić lepszego sposobu na napisanie go w tym czasie. W tym miejscu kod mówi głośniej niż słowa, ponieważ mogą nie wierzyć, że można to uczynić czystszym, dopóki ich nie pokażesz. Jednym z moich pierwszych wkładów typu open source była poprawka stosu cofania, która znacznie poprawiła wydajność, ale że niektórzy z głównych programistów twierdzili, że brzmiał zbyt skomplikowany, kiedy go po raz pierwszy opisałem. Krótki kod przyniósł ich na pokład.

Jeśli okaże się, że naprawdę istnieją dobre powody, aby to zostawić, zachęcam przynajmniej do komentarza wyjaśniającego te powody.

Mówiąc z doświadczenia ...

Pierwszy projekt Open Source, w którym uczestniczyłem, był pełen sików i octu, kiedy zaczynałem.

Od razu zrobiłem przeglądanie plików źródłowych i zacząłem stylizować różne rzeczy zgodnie z moimi osobistymi preferencjami, stworzyłem ogromną łatkę i przesłałem ją.

Jeśli pracujesz z kimś, kto jest „dobry” (tak jak ja), natychmiast odrzuci łatkę. Głównie dlatego, że kiedy bierzesz udział w projekcie open source, oczekuje się, że podzielisz swoje poprawki na kawałki wielkości kęsa, które rozwiązują jeden problem. „Usunięto wszystkie gotos” nie jest dobrym przykładem atomowego zatwierdzenia. Nawet jeśli najpierw podzielisz go na mniejsze, dobrze udokumentowane zatwierdzenia, nadal może zostać odrzucone.

Powodem jest to, że ponieważ kod jest przetwarzany przez wiele osób (z różnymi stylami) w czasie, zaakceptowanie zmian w całej bibliotece w celu dopasowania do stylu jednego programisty jest naprawdę niewykonalne. Jeśli zmiana stylu ze względu na styl byłaby możliwa, każdy projekt open source nigdy nie posunąłby się do przodu, ponieważ kod byłby stale edytowany, aby pasował do różnych stylów deweloperów.

Refaktoryzacja kodu i dodanie funkcjonalności (lub usunięcie przestarzałego crufta) zwykle ma pierwszeństwo przed kodem „czyszczenia”.

Najtrudniejsza i najbardziej satysfakcjonująca część pracy nad projektem typu open source polega na zapytaniu, dlaczego proponujesz wprowadzić zmiany, które przesyłasz. Jeśli możesz podać dobry powód, istnieje większa szansa, że ​​łatka zostanie przesłana.

Radzę wprowadzić kilka z tych zmian w jednym pliku źródłowym, aby zasmakować tego, co próbujesz zrobić w pierwszej kolejności. Jeśli zmiany są dobrze uzasadnione i zaakceptowane, zapytaj, czy więcej takich zmian poprawiłoby jakość projektu. W ten sposób nie zmarnujesz dużo wysiłku na nic, jeśli Twoje łatki zostaną odrzucone w przyszłości.

Rozwój open source to coś więcej niż pisanie kodu. Pracujesz nad budowaniem relacji zaufania, ponieważ zrobią to strażnicy (twórcy kontrolujący dostęp push) robić to, co oni mają na celu ochronę integralności projektu. Gdy prześlesz więcej łat, strażnik będzie lepiej wyczuwał twój styl i nie będziesz musiał tak bardzo uzasadniać swoich zmian.

To proces, który wymaga czasu, ale jest bardzo satysfakcjonujący. Dużo nie tylko będzie można dowiedzieć się z bycia w stanie patrzeć, a krytykowanie kod czyjeś ale będzie się krytyce na swoim własnym stylu.

Zanim zmarnujesz dużo czasu na „naprawienie niesprawiedliwości błędów w cudzym stylu kodowania”, zadaj sobie następujące pytanie:

Czy zmiany, które proponujesz, są oparte na dodaniu wartości do projektu, czy też są oparte na twojej wewnętrznej religii stylistycznej.

Na przepełnieniu stosu (i powiązanych witrynach wymiany stosów) jest wiele religii. Mam na myśli wiele . Ludzie myślą i mówią o stylu bez końca, jakby im więcej o nim mówiłeś, tym bardziej zbliżasz się do „idealnego, idealnego, niezniszczalnego, nieomylnego” stylu kodowania. Dużo o tym mówię, głównie dlatego, że jest fajnie.

W świecie Open Source styl nie jest tak ważny. Funkcja jest .

Uwaga: wszystkie te porady zakładają, że twój strażnik jest rozsądnym i utalentowanym programistą. Jeśli tak, to uważaj się za szczęściarza, że ​​nie utknąłeś z jednym z tych marudnych b @ & # & es, których jedyną troską jest ochrona ich „dziecka”. Oni nie istnieje w środowisku naturalnym, więc nie zdziw się, jeśli pojawią się jeden.

Jakość> Etykieta

Moim zdaniem nie powinieneś się martwić edytowaniem kodu innej osoby, gdy tylko odkryjesz, że ma on słabą jakość. Aby osiągnąć dobrą jakość oprogramowania, musisz dbać o czysty kod. Nie widzę problemu z wprowadzaniem ulepszeń w kodzie innych ludzi, inni ludzie powinni być świadomi i wdzięczni, że istnieją koderzy, którzy pracują nad ich kodem.

Jeśli potrafisz wymyślić lepszy sposób rozwiązania problemu bez użycia „goto”, sugeruję skorzystanie z niego. Trochę wysiłku, aby ulepszyć kod dzisiaj, może zaoszczędzić znacznie więcej wysiłku w przyszłości.

Komunikacja z oryginalnym autorem jest również dobrym pomysłem.

Nie ma w tym nic złego goto. Spójrz na kod asemblera - mnóstwo gotos (skoków i gałęzi) w każdym miejscu.

Powodem, dla którego gotow dzisiejszych czasach jest zła nazwa, jest fakt, że wypowiedź Go To uważana za szkodliwą wskazała zdanie Goto jako bardzo złą rzecz.

Zauważ, że to było 50 lat temu, kiedy inżynieria oprogramowania nie została jeszcze nazwana, a większość języków programowania była w istocie abstrakcjami podstawowej maszyny, ponieważ język maszynowy zawierał goto, podobnie jak oni. Możesz spróbować zaprogramować niektóre w Microsoft Basic (oryginalny, na Apple] [lub Commodore 64), aby dowiedzieć się, jaki był ten sposób myślenia.

Dijkstra argumentował, że aby uprościć sprawę, nie przeskakuj wszędzie, a zamiast tego utrzymuj prostszą ścieżkę programu ze wspólnym zakończeniem. Np. Powrót z metody. Innymi słowy - tylko skoki lokalne, a nie globalne.

Był to krok w kierunku wprowadzenia wywołań metod z argumentami, modularyzacji kodu, pakietów itp., Które zostały wprowadzone w celu oswojenia złożoności tworzenia oprogramowania. Oświadczenie goto było tylko pierwszym obserwatorem w tej wojnie.