Czy to oznaki złego programisty? [Zamknięte]

Kiedyś obwiniałem zmieniające się specyfikacje klientów za zgniliznę kodu, nie zdając sobie sprawy, że modele biznesowe się zmieniają i moim zadaniem jest rozwijać się w sposób dostosowywalny. Widzę to teraz jako znak złego programisty (zmieniłem się!).

Ale teraz widzę w sobie inne „wady”. Kilka razy ostatnio stwierdziłem, że „to tak, jakby próbować dopasować kwadratowy kołek do okrągłej dziury”, a także obwiniam niezdecydowanie klienta za projekt, który nie postępuje.

Czy są jakieś znaki, na które powinienem zwrócić uwagę, gdzie powinienem zmienić swoje nastawienie? Czy klient ma zawsze rację, czy czasem jestem usprawiedliwiony sfrustrowaniem?

Nie powiedziałbym, że jesteś złym programistą. Świadomość problemów już wykracza poza tę definicję.

Wymagania się zmieniają. To jest dane. Dobry deweloper musi wziąć to pod uwagę. Wiele nowoczesnych technik programowania pomaga sobie z tym poradzić.

Zachowanie wierności oryginalnej specyfikacji nie jest realistyczne. Również nierealne jest zmienianie wymagań przez cały czas.

Klient zdecydowanie nie zawsze ma rację. Jest to jednak „racja” częściej, niż chcemy, aby był / ona (jak w środku, spróbuj go dostosować, jeśli nie jest całkowicie wyłączony). Ale kiedy zobaczysz, jak kieruje projektem w niewłaściwym kierunku, postaraj się popierać to, co uważasz za słuszne.

Nie ma twardych zasad dotyczących tych rzeczy, a nawet dobrzy i doświadczeni programiści nie osiągnęli idealnego „Zen”. Jedynym złym podejściem nie jest poprawienie tych.

Są przypadki, w których jest klientem. Ale to także twój problem

Są przypadki, w których jest deweloperem, i są przypadki, w których jest klientem. Ale zazwyczaj oba są twoim problemem, więc postawa obwiniania się jest bardziej skuteczna, ponieważ popełnianie błędów polega na rozwiązywaniu problemów zamiast na bezradnym wskazywaniu palcem. Dlatego często znajdziesz go u bardziej doświadczonych programistów.

Jeszcze lepszym podejściem jest IMHO, aby spojrzeć na to bez winy: „to wina klientów, że mam kiepski kod, ponieważ on zawsze zmienia wymagania”, a następnie staje się „ten klient zastanawia się, czego chce, więc opinie, szybkie prototypowanie i elastyczność są bardziej ważne niż kompletność, solidność i szybkość ”.

Rodzaj umysłu Zen: nie oceniaj go, po prostu zobacz, jak jest.

Po pierwsze, klient nie wie, czego chce, dopóki go nie zobaczy. Jest to część odwołania niewielkich iteracji paradygmatu Agile z dużym zaangażowaniem klientów. Po drugie, nie oczekuj, że produkt będzie „kompletny” po skompletowaniu kodu.

Firma Microsoft stosuje produkt o nazwie „Watson” (wyślij wiadomość zwrotną, gdy pojawi się okno systemu Windows) w celu śledzenia problemów bezpośrednio z powrotem do klienta. Identyfikowalność to dobry sposób na śledzenie problemów wśród użytkowników, którzy ich doświadczają. Identyfikowalność można uzyskać, pytając. Lub, jeśli masz zasoby, zintegruj funkcjonalność z produktem (produktami). Kluczem jest śledzenie problemów / ulepszeń, aby można je było rozwiązać.

Wreszcie, na pewno klient może być kapryśny. W takich przypadkach staram się skupić na tajemnicy góry lodowej .

Zmieniające się wymagania to trudny fakt; ale zgnilizna kodu nie jest przez to spowodowana.

Zgnilizna kodu ma miejsce, gdy są fragmenty kodu, których nie ćwiczysz często; więc kiedy wprowadzisz jakieś zmiany, które „nie powinny wpłynąć na nic innego”, możesz wprowadzić błędy. Innymi słowy, kod, który nie widzi światła dziennego, powoli się rozkłada i nie można powiedzieć, kiedy przestał działać.

Tak, to twoja wina, a nie twój użytkownik.

Prawdziwe rozwiązanie? często testuj cały swój kod. Oczywiście najlepszym sposobem są automatyczne testy z dobrym zasięgiem.

Niezdecydowanie klienta może być dużym problemem, a jeśli nie jesteś tym, który jest odpowiedzialny za zarządzanie relacjami z klientem, może być bardzo trudno sobie z tym poradzić. Możesz porozmawiać z osobą, która zajmuje się klientem i spokojnie wytłumaczyć, że postęp nie może nastąpić, dopóki klient nie podejmie decyzji. Jeśli jesteś odpowiedzialny za relacje z klientami, trzeba powiedzieć klientowi, że trzeba podjąć decyzję, zanim projekt może być kontynuowany. Może nie być tak, że twoje nastawienie wymaga przeglądu, wystarczy minuta medytacji, aby się uspokoić. ;)

Javier podkreśla, że ​​zmieniające się wymagania to trudny fakt. Te sytuacje mnie frustrują, ponieważ zbyt często pracuję nad produktem, w którym programista musi podejmować decyzje. Moja opinia brzmiała: „Dlaczego kierownictwo nie może tego rozgryźć z klientem?” Lub „Dlaczego rozpoczęliśmy ten projekt, jeśli klient nie wie, czego chce?”, „Tak bardzo boli mnie głowa, kiedy się zmieniają. późno w rozwoju ".

Prosty fakt: zawsze tak będzie , nie tylko podczas programowania / tworzenia oprogramowania, ale na każdym etapie życia. Świat byłby po prostu bardzo nudnym i zupełnie innym miejscem, gdyby ludzie nigdy nie zmienili zdania, nigdy się nie dostosowali, nigdy nie zajęli się zmianami. Ludzie mają tendencję do patrzenia na to, co otrzymują, i ulepszania tego. Czy nie robisz tego samego z kodem? Jeśli mam blok kodu, z którego nie jestem zadowolony (jest nieefektywny, niechlujny), poprawię go. (Czy system operacyjny narzeka na mnie? ... czasami, jeśli używam określonego nienazwanego systemu operacyjnego, ale ogólnie nie)

Jako programiści musimy wykorzystywać możliwości poprawy sytuacji, a nie wpadać w depresję lub zirytować ich. Skorzystaj z okazji, aby porozmawiać z ludźmi, poprawić swój styl, poprawić etykę pracy, podchodzić do rzeczy z otwartym umysłem, dążyć do bycia lepszym niż byłeś wczoraj. Rób postępy w swojej karierze i nie osiedlaj się zbyt łatwo.

Rozumiem, że nie wszyscy zgodzą się z tą odpowiedzią, ale myślę, że ważne jest, aby odpowiedzi na to pytanie obejmowały szerszą perspektywę.

Podczas interakcji z klientem nie programujesz; uczysz się i uczysz.

Informuj klientów i edukuj ich o tym procesie. Zmiana nastąpi. Poinformuj ich, że spróbujesz je wdrożyć, ale będzie to kosztować więcej. Niech zdecydują.

Nie wchodź w szczegóły techniczne, nawet jeśli pytanie, które zadają, ma charakter techniczny. Kusi cię, ponieważ poczujesz się trochę defensywnie i będziesz chciał podjąć wyzwanie / zdobyć maniaka. Nie rób tego; nie dbają o szczegóły i przestaną słuchać po 45 sekundach.

Jeśli nie powiedziałeś im z wyprzedzeniem, nie oczekuj, że dowiedzą się o standardach branżowych i najlepszych praktykach lub jakiejkolwiek innej wymówki do robienia tego, co robisz. Nienawidzę tego, gdy nie widzę opłaty do samego końca, tylko po to, żeby sprzedawca powiedział mi, że to standard w branży. Nie powinienem się tego spodziewać. Moja odpowiedź brzmi: „Czy sprawianie, że czuję się jak głupek też jest standardem?”

Kiedy jesteś z klientem, zwracaj na niego większą uwagę niż ktokolwiek lub cokolwiek innego w pokoju. Udomowione psy są w tym geniuszami; szczególnie jeśli masz jedzenie.

To złe zarządzanie wymaganiami lub zła analiza. Twój analityk biznesowy (jeśli taki posiadasz) lub ktokolwiek uzyska wymagania, musi usiąść z klientem i spróbować uzyskać wszystkie wymagania, nawet te, o których klient może nie pomyśleć. Klienci zwykle nie wiedzą wszystkiego, czego chcą, świetny analityk biznesowy pomoże im to wszystko rozwiązać.

Dlatego zawsze powinieneś uzyskać konfigurację Dokumentu wymagań biznesowych i wylogować się, zanim jakakolwiek aplikacja wyjdzie poza fazę prototypowania / badania.

Pomysł, że ten dokument jest rzeczywiście ostateczny, jest wadliwy, ale powinno to pomóc lepiej zrozumieć, czego tak naprawdę chce klient. I tak długo, jak piszesz kod z myślą o łatwości konserwacji, możesz ograniczyć swoje problemy do minimum.

A jeśli kiedykolwiek będziesz potrzebować pretekstu, aby się wycofać, możesz obwiniać BRD za opóźnienia, które wylogował się klient, nie uwzględniając takiej i takiej funkcji itp.

(Oczywiście jest to tylko wymówka na wypadek, gdybyś jej potrzebował. Zawsze powinieneś planować, żeby coś zmieniali )

W cytacie Emersona: „Głupia konsekwencja to hobgoblin małych umysłów ...” najczęściej pomijane słowo jest głupie . Spójność nie podlega negocjacjom w niektórych sytuacjach, ale często zastępuje krytyczne myślenie i analizę.

Z jednej strony wiele modeli programistycznych zaprojektowano specjalnie z myślą o środowisku, które opisujesz; więc jeśli okaże się, że musisz naruszyć swój model, to albo nie wdrażasz go prawidłowo, albo masz niewłaściwy model.

Ale z drugiej strony, jeśli masz uzasadnione i możliwe do uzasadnienia uzasadnienie naruszenia reguł i możesz wykazać, że twoja nieuczciwa metoda produkuje czystszy, łatwiejszy do utrzymania kod, nie powinieneś obawiać się rozsądnej drogi.