Tak, rozumiem twoją frustrację głupią zasadą. Czytałem wiele programów z bezużytecznymi komentarzami, takimi jak
x = x + 1; // add 1 to x
I mówię do siebie: TO TO oznacza znak plus !! Wow, dzięki, że mi powiedziałeś, że tego nie wiedziałem.
Ale powiedziawszy, klient płaci rachunek. Dlatego dajesz im to, czego chcą. Gdybym pracował w salonie samochodowym, a klient powiedział, że chce pickupa, nie kłóciłbym się z nim o to, czy naprawdę potrzebuje pickupa, i nie wypytywałby go o to, czego się spodziewa. Sprzedałbym mu furgonetkę.
Okej, są chwile, kiedy klienci mówią, że chce i czego naprawdę potrzebuje, są tak daleko od siebie, że staram się z nim omówić tę sprawę, może przekonać go, by zgodził się na coś bardziej racjonalnego. Czasami to działa, czasem nie. Ostatecznie, jeśli nie mogę zmienić zdania, daję mu to, czego chce. Jeśli wróci później i powie: „Och, to naprawdę nie spełniało moich wymagań biznesowych, możemy obciążyć go więcej za to, co powiedzieliśmy mu za pierwszym razem. To, ile możesz negocjować z klientem, zależy od tego, jak bardzo ufa on twojej wiedzy, w jaki sposób jego umowa z tobą pasuje do organizacji, i, szczerze mówiąc, jak bardzo są byki.
Byłby to bardzo rzadki przypadek, w którym, zakładając, że to ode mnie zależy, straciłbym kontrakt, ponieważ uważałem, że wymagania były źle pomyślane.
Pamiętaj, że osoby, z którymi negocjujesz Twoja firma, mogą, ale nie muszą wymyślić tę zasadę 25%. Może to być reguła narzucona im z góry.
Widzę pięć możliwych odpowiedzi:
Jeden. Przekonaj swojego szefa lub osobę negocjującą z klientem, aby się o to spierać. Szanse są, że to nic nie da, ale możesz spróbować.
Dwa. Odmów tego. Prawdopodobnie spowoduje to zwolnienie z pracy lub, jeśli firma się z tobą zgodzi, spowoduje utratę umowy. To wydaje się bezproduktywne.
Trzy. Napisz bezużyteczne komentarze, aby wypełnić miejsce, takie komentarze, które powtarzają tylko to, co jest w kodzie i które każdy programista zdolny do modyfikacji kodu zobaczy w ciągu 2 sekund. Widziałem wiele takich komentarzy. Wiele lat temu pracowałem dla firmy, w której musieliśmy umieszczać bloki komentarzy przed każdą funkcją, która wymieniała parametry, takie jak:
/*
GetFoo function
Parameters:
name: String, contains name
num: int, the number
add_date: date, the date added
Returns:
foo code: int
*/
int GetFoo(String name, int num, Date add_date)
Zarzut, że takie komentarze stanowią obciążenie konserwacyjne, ponieważ musisz je aktualizować, jest nieważny. Nie ma potrzeby aktualizowania ich, ponieważ żaden poważny programista nigdy na nich nie spojrzy. W przypadku jakichkolwiek pytań należy wyjaśnić wszystkim członkom zespołu, że bezużyteczne, zbędne komentarze należy zignorować. Jeśli chcesz wiedzieć, jakie są parametry funkcji lub co robi linia kodu, przeczytaj kod, nie patrz na bezużyteczne komentarze.
Cztery Jeśli chcesz dodać zbędne bezwartościowe komentarze, być może warto poświęcić czas na napisanie programu do ich wygenerowania. Coś z inwestycji z góry, ale może zaoszczędzić sporo pisania na maszynie.
Kiedy zaczynałem w tym biznesie, firma, dla której pracowałem, korzystała z programu reklamowanego jako „Zapisuje dla ciebie dokumentację! Kompletna dokumentacja dla każdego programu!” System wymagał, abyśmy nadali wszystkim zmiennym w zasadzie bezsensowne nazwy, a następnie mieli tabelę podającą sensowną nazwę dla każdej zmiennej, więc w zasadzie to, co zrobiła „automatyczna dokumentacja”, zastąpiła bezsensowną nazwę, którą zmusiła nas do użycia znaczącą nazwą. Na przykład - działało to z COBOL - miałbyś w swoim programie wiersz, który powiedział:
MOVE IA010 TO WS124
i wygenerowaliby wiersz „dokumentacji”, który powiedział
COPY CUSTOMER NAME IN INPUT RECORD TO CUSTOMER-NAME IN WORKING STORAGE
W każdym razie można z pewnością napisać program, który dość łatwo wygeneruje równie bezwartościową dokumentację. Przeczytaj wiersz jak
a=b+c
i wygeneruj komentarz
// add b to c and save result in a
Itp.
Pięć. Jak najlepiej wykorzystaj tę głupią zasadę. Spróbuj pisać użyteczne i znaczące komentarze. Hej, to może być dobre ćwiczenie.
Aha, nawiasem mówiąc, dodam, że zawsze można zagrać w metrykę.
Pamiętam, gdy jeden z pracodawców powiedział, że zacznie mierzyć produktywność programistów na podstawie liczby wierszy kodu, które produkowaliśmy tygodniowo. Kiedy powiedziano nam to na spotkaniu, powiedziałem: Świetnie! Mogę z łatwością zwiększyć swój wynik. Nigdy więcej pisania
x=x+4;
Zamiast tego napiszę:
x=x+1;
x=x+1;
x=x+1;
x=x+1;
Pętle Zapomnij, skopiuję i wkleję kod dziesięć razy. Itp.
Więc tutaj, jeśli mają policzyć wiersze komentarzy, skróć każdy wiersz i kontynuuj pomysł w następnym wierszu. Jeśli nastąpi zmiana w komentarzach, nie aktualizuj istniejącego komentarza. Wpisz datę, a następnie skopiuj cały tekst i napisz „Zaktualizowano” i nową datę. Jeśli klient zadaje to pytanie, powiedz mu, że uważasz, że konieczne jest zachowanie historii. Itd itd.