Miałem wprowadzić poprawki błędów ortograficznych i gramatycznych w kodzie i nie wprowadzać żadnych zmian w rzeczywistej funkcjonalności kodu?

Przeczytaj uważnie.

Często wszelkie zmiany w kodzie mają skutki późniejsze. Może być wymagana weryfikacja kodu. Może być wymagane przeprowadzenie testów. Może być wymagany przegląd bezpieczeństwa. Itd. Zmiana błędów ortograficznych i gramatycznych może wywołać wiele niezaplanowanej pracy ze strony innych.

I chociaż Twoim zamiarem nie jest wprowadzanie żadnych zmian w rzeczywistej funkcjonalności, pojawiają się błędy.

Zanim zmienisz kod - zapytaj.

Czy będzie to uważane za złą etykietę lub błahostkę, jeśli:

• Edytowałem te dokumenty, aby poprawić gramatykę i pisownię, zwłaszcza w dokumentach, które nie są dostępne publicznie? oryginalny autor jest dyslektykiem?

To zależy głównie od kultury Twojej organizacji.

W niektórych firmach ciągła zmiana przez każdego, kto czyta takie dokumenty, jest Witamy. W innych firmach byłoby to uznane za niegrzeczne bez zgody autora.

Uważam tego rodzaju zmianę za poprawę jakości. Dokumentacja wewnętrzna ma wartość, chociaż nie jest skierowana do użytkownika końcowego, a poprawa jej jakości czyni ją bardziej wartościową. Osobiście bardziej ufam dokumentacji, jeśli nie zawiera ona dużej liczby literówek. Czasami literówka lub zła gramatyka mogą również zmienić znaczenie lub doprowadzić do nieporozumień.

Podsumowując: uważam to za raczej pozytywne.

Uważaj jednak, jeśli wydasz Robiąc to dużo czasu, ludzie mogą się zastanawiać, czy nie masz nic lepszego do roboty, jak kodowanie ...

Załóż najgorszą ze swoich zmian:

• Popełniasz błędy, które coś psują
• Twoje stosunkowo drobne zatwierdzenia mogą zaśmiecać dzienniki zmian itp.
• Twój pracodawca możesz pomyśleć, że spędzasz czas na robieniu bardziej pożytecznych rzeczy

Z tego powodu wprowadzam „niezamówione” zmiany tylko wtedy, gdy w zasadzie i tak zmieniałem kod / dokument. Więc jeśli mam za zadanie zmienić jakąś klasę i wiem, że jego funkcjonalność i tak będzie musiała zostać ponownie przetestowana, równie dobrze mógłbym ją zreformować i poprawić pisownię, jeśli naprawdę wierzę, że poprawi jakość lub zaoszczędzi każdemu czas na końcu. Jak wspomniano w innej odpowiedzi: „zasada harcerzy” - zostaw kemping bardziej uporządkowany niż wtedy, gdy tam dotarłeś.

Ale nie rozpalaj przypadkowo pożarów buszu niepotrzebnie :) Na każdy inny zmiany, przedstaw to temu, kto decyduje o tym, co robisz. Wyjaśnij korzyści płynące z poprawek i wszelkie ryzyko. Przykładami korzyści mogą być to, że błędnie napisany kod utrudnia przeszukiwanie bazy kodu, negatywne postrzeganie przez użytkowników błędnie napisanych wiadomości lub dokumentów itp. Niech zdecydują, czy warto poświęcić czas / podjąć ryzyko.

Jeśli mówimy o naprawdę drobnych zmianach, takich jak poprawianie literówek lub brakujących przecinków itp., Nie powiedziałbym, że źle jest po prostu poprawiać je, gdy je znajdziesz. To, czego nie zrobiłbym, to powiedzieć komukolwiek, że wprowadziłeś zmiany, ponieważ w najlepszym przypadku może to wydawać się poszukiwaniem uwagi, a w najgorszym bycie drobnym nazistą ortograficznym / gramatycznym.

Kolejna zaleta do naprawienia - jak się okazuje - nie chcesz wyglądać na kogoś, kto poluje na te błędy.

Kod może być trochę inny - chociaż podajesz że nie zmieniasz faktycznego kodu, więc zakładam, że są to tylko rzeczy takie jak komentarze, więc nie ma możliwości, aby wpłynęło to na funkcjonalność. W takim przypadku sugeruję, że jest w porządku.

Miałem wprowadzić poprawki błędów ortograficznych i gramatycznych w kodzie i nie wprowadzać żadnych zmian w rzeczywistej funkcjonalności kodu?

Czy są jakieś błędy widoczne publicznie (w interfejsie użytkownika) lub klienta (w dzienniku konsoli klienta)?

Jeśli tak, poproś kierownika zespołu / projektu o upoważnienie do ich poprawiania.

Jeśli nie, zrób nic lub zapytaj kierownika zespołu / projektu, czy możesz dokonać jakiejś refaktoryzacji i naprawić inne problemy, które mógłby mieć kod.

W każdym razie nie krytykuj swojego współpracownika, szczególnie jeśli jest dyslektykiem.

Nie zmieniaj kodu, chyba że jest powiązany bezpośrednio z błędem lub zgłoszeniem do rozszerzenia, nad którym pracujesz. (masz jakiś system biletowy do pracy w istniejących systemach, prawda?) Twoja zmiana powinna być również konieczna, aby zakończyć pracę związaną z biletem.

Jeśli mocno wierzysz, że ten kod powinien zostać zmieniony , stwórz bilet do recenzji i jeśli zostanie zatwierdzony, możesz wykonać pracę.

Jak mówi przysłowie: „Żaden dobry uczynek nie uchodzi bezkarnie”. Jest tak wiele sposobów, że to, co wydaje się trywialną edycją, może się nie udać, czasem z opóźnieniem.

Na przykład w mojej firmie zbudowaliśmy system ostrzegawczy oparty na monitorowaniu / skrobaniu plików dziennika. Komunikaty o błędach w dziennikach mogą generować wszystko, od drobnego ostrzeżenia do alertu wszystkich rąk. Przez lata niestety utworzyliśmy komunikaty o błędach w dziennikach ze wszystkimi odmianami literówek. Jeśli jakiś nadgorliwy programista „naprawi” komunikaty o błędach, nasz system alertów może nagle ucichnąć.

To naprawdę sprowadza się do kontekstu.

Na przykład pracuję dla międzynarodowej firmy w zespole zlokalizowanym w wielu krajach. Jestem jedynym rodzimym użytkownikiem języka angielskiego, więc codziennie napotykam błędy gramatyczne i ortograficzne w naszych nazwach kodowych i komentarzach.

Zazwyczaj zostawiam je bez zmian, ponieważ poprawianie błędów nie przynosi żadnych korzyści, a zrozumienie intencji autora jest zawsze bardzo łatwe w kontekście kontekstu. (Przychodząc mi na myśl, przychodzi mi na myśl folder, do którego dostęp ma kilka plików o nazwie „zasoby”.

Zmiana nazw może mieć efekt wodospadu, jeśli jest to rzeczywisty obiekt kodu, a nazwa to opisowe, choć błędnie napisane, nie widzę korzyści z zwiększenia własnego obciążenia pracą.

Nie sądzę, aby moi zagraniczni współpracownicy poczuli się urażeni, gdybym zaczął poprawiać ich błędy w moich zatwierdzeniach, ale z czasem gdybym miał to robić w kółko, mogą zacząć czuć, że uważam, że ich znajomość języka angielskiego jest niewystarczająca.

Podsumowując, zadaj sobie pytanie, czy kontekst sytuacji jest wart dodatkowej pracy i jeśli kontekst oznacza potencjalną krzywdę w stosunku do oryginalnego autora.

Nie wierzę, że poprawianie błędów ortograficznych i gramatycznych w kodzie innych osób sprawi wrażenie, że jesteś lepszym programistą. że lepiej rozumiesz język angielski.

Dokumenty i wpisy do dziennika dostępne publicznie powinny mieć znacznie wyższy standard pod względem pisowni i poprawności gramatycznej niż dokumenty wewnętrzne i kod. Oczywiście wskazane jest również ciągłe czyszczenie kodu, nad którym pracujesz. Oznacza to, że za każdym razem, gdy pracujesz nad funkcją / poprawką, powinieneś pozostawić dotkniętą część czystszą niż wcześniej (zasada boyscout). Nie powinno być tak, że kiedy edytujesz kod, zmiany zawierają tylko poprawki gramatyczne i ortograficzne.

Ponadto powinieneś zapytać swojego kierownika, zanim zaczniesz regularnie robić ten nawyk, ponieważ może on pomóc zwracając się do swoich kolegów, którzy mogą być wrażliwi na korygowanie ich wkładu.

Istnieją dwie kategorie, z którymi masz tutaj do czynienia: dokumenty dostępne publicznie oraz dokumenty wewnętrzne i kod.

W przypadku dokumentów i kodu wewnętrznego nie przejmuj się zbędnymi zmianami. Dopóki pliki są zrozumiałe i działają tak, jak powinny, tak naprawdę nie ma nic do zyskania. Takie zmiany tak naprawdę niczego nie dodają i mogą zaśmiecać historię kontroli wersji. Jeśli jednak już wprowadzasz zmianę w określonym dokumencie i widzisz kilka literówek do naprawienia, to śmiało. W takim przypadku jest to bardziej dodatek do już niezbędnej zmiany.

W przypadku dokumentów dostępnych publicznie i komunikatów interfejsu użytkownika ważne jest, aby upewnić się, że jest kilka błędów i wszystko jest poprawne gramatycznie. Jeśli jest to coś, co jest ewidentnie nieprawidłowe, z pewnością bym to zmienił. Jeśli jest to zmiana bardziej subiektywna (np. Zmiana sformułowania lub przecinek oksfordzki), przed zapisaniem jakichkolwiek zmian skonsultowałbym się z głównym autorem lub kierownikiem. Ponownie stwierdzam, że wiele drobnych zmian, takich jak ta, może zaśmiecać kontrolę wersji, więc osobiście wolę zapisywać zmiany z innymi ważniejszymi aktualizacjami lub odłożyć na bok zmiany i wykonać zbiorcze przesłanie kilku kopii edycji na raz . To jest coś, o czym możesz porozmawiać ze swoim menedżerem, aby zobaczyć, co wolą.

Pracuję w małej firmie deweloperskiej, która ma otwartą i przyjazną atmosferę i jestem najmłodszym pracownikiem.

Masz menedżera. To jest osoba, o którą powinieneś zapytać!

Nasze opinie mogą być traktowane jako rada, ale twój szef jest osobą, która musi podjąć decyzję. Muszą zdecydować, jak najlepiej wykorzystać Twój czas .

Spotykam się z prostymi błędami w pisowni, literówkami i niepoprawną gramatyką.

Jeśli masz upoważnienie do zmiany tych dokumentów i jesteś pewien , że nie zmieniasz zamierzonego znaczenia , to zakładam, że wszystko jest w porządku. Jednak pewność co do zamierzonego znaczenia jest nietrywialna i łatwo jest zmienić znaczenie bez zamiaru.

W innych przypadkach w kodzie napotykam wiele literówek w instrukcjach debugowania, dane wyjściowe i komunikaty, które są prezentowane użytkownikowi.

Błędy w kodzie (w tym wszelkiego rodzaju komunikaty) muszą być odpowiednio adresowane za pomocą systemu śledzenia błędów. Następnie można je odpowiednio określić priorytetami i na tej podstawie sobie z nimi poradzić.

I można to schrzanić i zepsuć kod. Dzieje się to cały czas.

Czy byłoby to uważane za złą etykietę lub drobną, gdyby:

Edytowałem te dokumenty, aby poprawić gramatykę i pisownię, szczególnie w dokumentach, które t publiczne?

Prywatne dokumenty wewnętrzne nie wymagają szczególnej naprawy w ten sposób. Priorytetowo nadaj innej pracy.

Pierwotny autor jest dyslektykiem?

Możliwości lub ograniczenia oryginalnego autora nie są istotne dla tego, jak wykorzystujesz Twój czas.

Miałem wprowadzić poprawki błędów ortograficznych i gramatycznych w kodzie i nie wprowadzać żadnych zmian w rzeczywistej funkcjonalności kodu?

Każda zmiana w kodzie jest formalną zmianą. Zmiany w komentarzach i innych elementach mogą wprowadzać błędy - ludzie popełniają przy tym błędy. Odradzam to bez wyraźnych instrukcji od przełożonych.

Jeśli dokument nie jest dostępny publicznie, jak wspomniałeś w przypadku niektórych z nich, to jakie są rzeczywiste korzyści z wprowadzenia tych poprawek, poza tym, że ci nie przeszkadzają?

Jeśli jesteś nie zmieniając funkcjonalności kodu, a poprawiona prezentacja gramatyczna w ogóle nie wpływa na wizerunek firmy, to nie dodałeś żadnej wartości do kodu.

Jeśli poświęcasz czas na „naprawianie” czegoś, co dodaje bez wartości, właśnie zmarnowałeś swój własny czas oraz czas i pieniądze swojego pracodawcy, co nie jest drogą dla nikogo, a zwłaszcza dla najmłodszej osoby w łańcuchu pokarmowym.

Prawdopodobnie irytuje ludzi, którzy będą pytać „dlaczego to wymagało naprawy?” i prawdopodobnie zadasz ogólne pytanie - „Czy ta osoba nie ma do wykonania dodatkowej pracy? Jeśli nie, to czy ta osoba jest dla nas niezbędna mieć w ogóle? ”

Nie pytaj nawet, czy można wprowadzić te poprawki, ponieważ nie ma problemu z naprawą, a wprowadzenie poprawki nie daje żadnej poprawy.

W przypadku wiadomości, które to robią zaprezentować się użytkownikom / klientom końcowym, zdecydowanie zidentyfikuj ich w celu naprawy, daj znać komuś wyżej, że je widziałeś, i zaproponuj poprawienie. Z pewnością podstawowe błędy tego rodzaju nie odbijają się dobrze na firmie, więc naprawienie ich wnosi znaczną wartość.