Czy deweloper powinien argumentować przeciwko niepotrzebnym lub szkodliwym funkcjom?

Jakie jest dobre podejście deweloperów do omawiania nowych funkcji, a mianowicie funkcji niekrytycznych / wątpliwych?

Załóżmy, że rozwijasz język Java, a szef mówi: „Potrzebujemy wskaźników, aby programiści mogli bezpośrednio manipulować pamięcią obiektów!”

Czy deweloper powinien zlikwidować ten pomysł, ponieważ dodaje niewyobrażalną złożoność i luki w zabezpieczeniach, czy powinien zrobić to, o co prosił?

To może nie być dobry przykład, ale co z rzeczami, które są bardziej w szarym obszarze, takie jak dodawanie przycisków, które przerywają przepływ pracy lub są sprzeczne z wewnętrzną strukturą programu itp.?

Jaka jest optymalna dystrybucja „potrafi” a „nie może” dla zwykłego programisty?

EDYCJA: Pytanie nie dotyczy złego szefa: D

Byłem bardziej zainteresowany, w jaki sposób ludzie podchodzą do nowych problemów, które dodają zauważalną liczbę problemów, a jednocześnie mogą być mało przydatne.

Czy ogólne podejście powinno być następujące:

1. tak, zrobimy to, zepsujmy złożoność
2. może
3. nie, ogólna przeróbka i implikacje nie uzasadniają zmiany

Jaka powinna być reakcja dobrego programisty?

Najlepszą rzeczą jest spotkanie i przedstawienie plusów i minusów w grupie, a następnie omówienie najlepszego rozwiązania. Jeśli masz zespół, poproś go o uzgodnienie rozwiązania. Gdy zespół coś uzgodni, menedżerowie i „szefowie” zwykle wybierają rozwiązanie.

Jeśli twój szef nadal się nie zgadza, to zrobiłeś wszystko, co możesz: zjednoczyłeś swój zespół i menedżerów, omawiając wady i zalety, a mimo to szef wybrał potencjalnie gorsze rozwiązanie.

Kluczem do tego jest omawianie zalet i wad jako grupy. W ten sposób omawiasz najlepsze rozwiązanie ze swoim zespołem, a jednocześnie wskazujesz decyzję szefa (zanim on to zrobi) bez politycznej reakcji po tym, jak mówi się ludziom, dlaczego uważasz, że decyzja szefa był zły.

Jest to delikatna sytuacja związana z polityką pracy, ale można sobie z nią poradzić polubownie.

Jeśli twój szef każe ci robić głupie zadania, powinieneś (uprzejmie) wyjaśnić, dlaczego to jest głupie.

Jeśli on lub ona nie rozumie, musisz robić głupie rzeczy. to jest to! On jest szefem. W takim przypadku możesz po prostu zrobić to, co on / ona mówi lub porozmawiać z szefem lub zmienić pracę.

Możesz powiedzieć szefowi, że chociaż jest to technicznie możliwe, będzie kosztować X czasu i pieniędzy wydanych na wysiłek poświęcony analizie, projektowaniu, przepisaniu istniejącego kodu, testowaniu, testowaniu regresji, ... A następnie zapytaj, czy funkcja jest tego warta . Czasami odpowiedź brzmi „tak! Musimy to mieć!”, Czasem odpowiedź brzmi „nie, chyba nie”.

Jeśli żądana funkcja narusza niektóre podstawowe zasady aplikacji (takie jak „Dodaj niebieski przycisk!” Do interfejsu użytkownika, który został określony i ma tylko czerwone przyciski zgodnie z życzeniem klienta), to myślę, że jest OK zapytać „Dlaczego?” i wspomnieć, że jest to sprzeczne z wcześniej ustalonym projektem.

W końcu prawie wszystko można „zrobić” (z technicznego punktu widzenia dodanie czerwonego przycisku do niebieskiego interfejsu użytkownika może nie być trudne ), chodzi raczej o to, co należy zrobić?

Aby odpowiedzieć na twoje edytowane pytanie, myślę, że odpowiedź powinna brzmieć „2”, być może, w oczekiwaniu na dalsze badanie i analizę.

Nie chcesz odpowiedzieć # 1 „Tak, bezwarunkowo”, ponieważ możesz utknąć w zobowiązaniu do czegoś, czego nie jesteś w stanie dostarczyć w określonym czasie.

Nie chcesz odpowiedzieć # 3 „Nie, to za dużo pracy”, ponieważ wtedy wygląda na to, że jesteś niechętny do współpracy i niepotrzebnie trudny.

Z perspektywy programisty: NIGDY nie mów nikomu, kto płaci rachunki, że nie może mieć tego, czego chce. Zamiast tego możesz im powiedzieć, że nie mogą go mieć za tę cenę lub że nie mogą mieć dokładnie takiego, w jakim go pierwotnie wymyślili.

Do twojego „wskaźnika” przykład; .NET, środowisko kodu zarządzanego, ma wskaźniki. Są one niezbędne do zapewnienia dużej interoperacyjności z niezarządzanym kodem. Jednak „bezpieczne” korzystanie z nich jest ściśle regulowane, a jeśli jest używane w „niebezpiecznym” kodzie, kod ten wymaga wyższych uprawnień bezpieczeństwa w czasie wykonywania. Jeśli opracowujesz język zarządzany, który również wymaga bezpośredniego dostępu do pamięci za pośrednictwem wskaźników, możesz wymyślić podobny schemat zestawiania za kulisami, używając możliwych wskaźników tylko do odczytu, w których nie można automatycznie zestawiać, i zezwalając na „ true ”wskaźniki tylko w najbardziej zaufanych obszarach bazy kodu.

Do przykładów graficznego interfejsu użytkownika: jeśli wiesz, że nowa funkcja „przerwie” bieżący przepływ kodu, możesz go przetestować i rozwinąć w sposób bardziej niezawodny, aby cofnąć wszelkie wcześniejsze prace wykonywane przez przepływ pracy. Twoi klienci, a czasem nawet kierownik, zwykle nie mają pojęcia ani zainteresowania strukturą programu; jeśli coś, czego chcą, jest trudne ze względu na strukturę programu, to z definicji struktura jest zła, ponieważ nie pozwala ci robić tego, czego chce klient.

We wszystkich przypadkach ta nowa funkcja może zwiększyć zakres wymaganej pracy, wykraczając poza to, co myślał klient. To z kolei będzie wymagało albo przedłużenia harmonogramu, więcej pieniędzy i / lub ograniczenia innych planowanych prac.

Jeśli jednak znasz sposób na uzyskanie tego samego podstawowego wyniku w łatwiejszy lub bardziej logiczny sposób, możesz to zasugerować klientowi. Chociaż na pewno istnieją, na szczęście jeszcze nie widziałem klienta, który kategorycznie odmówił wysłuchania opinii programistów, szczególnie w środowisku Agile, w którym istnieje „właściciel produktu”, którego jedynym zadaniem jest komunikowanie się z programistami w zakresie różnych potrzebnych szczegółów, takich jak te.

Jeśli spędzasz wiele lat na programowaniu dla dużych aplikacji i po drodze zastanawiasz się nad tym krytycznie, rozwiniesz precyzyjnie dostrojone poczucie, kiedy dana funkcja spowoduje problemy, które przewyższą jej użyteczność. Innym słowem na ten temat jest mądrość i podobnie jak w przypadku innych rodzajów mądrości, wyzwaniem może być uczynienie tych, którzy nie widzą jej wartości.

Inne plakaty argumentowały, że powinieneś spróbować obliczyć koszt problemu, który zostanie wprowadzony przez problematyczną funkcję, i jest to dobry pomysł, gdy jest to możliwe, ale zwykle tak nie jest. Zazwyczaj możliwe jest jedynie oszacowanie natychmiastowych kosztów wdrożenia. Nawet to jest często trudne w przypadku większych funkcji. Jeśli chodzi o przyszłe koszty, jesteś w trudnym miejscu. Nie masz pewności, jakie inne funkcje będą wymagane ani jak długo produkt będzie konserwowany. Koszt zwykle jest znacznie wyższy niż można by poprzeć szacunkami opartymi na twardych faktach.

Im więcej kompetencji wykazałeś w przeszłości, tym więcej swobody będziesz musiał po prostu zadeklarować jako zły pomysł. To może nadejść tylko z czasem i udokumentowanym zapisem sukcesu. To powiedziawszy, zawsze powinieneś wyrazić gotowość spełnienia prośby, ponieważ jest to tym, czego chce twój klient. Powinieneś wyrazić zastrzeżenia w oparciu o swoje doświadczenie, a kiedy już to zrobisz, stanie się to problemem w 90% przypadków, ponieważ zaczniesz rozmowę, która doprowadzi do sedna problemu, a mianowicie: Dlaczego poprosili Cię o dodanie ta funkcja w pierwszej kolejności? W tym momencie możesz zaoferować alternatywy lub być może zgodzić się, że chociaż żądana funkcja spowoduje problemy, nadal jest konieczna.

Oczywiście możliwe jest również, że się mylisz. Czy inżynieria oprogramowania nie jest fajna?

Ponieważ pytanie jest dość niejasne, trochę uogólnię z moją odpowiedzią.

Zawsze pytaj ich, ale słuchaj ich uzasadnienia. Czasami ludzie po prostu zapominają o praktyczności danej funkcji lub o tym, jak długo zajmie programowanie. Z drugiej strony czasami uwikłani jesteśmy w mentalność programisty polegającą na byciu wydajnym / bez fanaberii / itp. I zapominamy, że to, co uważamy za nieistotne dla projektu, tak naprawdę nie jest dla klienta.

Jeśli mają dobry powód, daj im znać, ile czasu zajmie programowanie i wszystkie możliwe nierówności, które napotkasz podczas implementacji, i sprawdź, czy nadal będą chcieli to kontynuować. W przeciwnym razie podaj, dlaczego nie uważasz, że to dobry pomysł, i sprawdź, jaka jest ich reakcja. Wypłukać i powtórzyć.

Większość już powiedziano, ale w moim obecnym środowisku pracy chciałbym podkreślić jedną rzecz. Pracuję dla firmy, która jest kontrahentem dla innych firm, a nasze aplikacje są związane z procesami biznesowymi (w sporej wysokości napędzają sprzedaż i komunikację z klientem).

Procesy biznesowe wraz z towarzyszącymi im produktami mogą być (przynajmniej jeśli firma jest wystarczająco duża) bardzo złożone. W pewnym stopniu, jeśli modelujesz złożoną rzecz, wynikowa aplikacja będzie miała odpowiednią złożoność. Ponieważ większość ludzi biznesu widzi swoją część procesu, cała aplikacja / proces opiera się na większej złożoności niż to, co jest widoczne tylko dla jednego użytkownika.

Chodzi mi o to, że gdy pojawi się nowy wymóg biznesowy, będzie on działał dla ludzi biznesu, ponieważ nie podnosi to znacznie złożoności, ale może mieć większy wpływ na cały system. Moim zdaniem nie jest to powód do argumentowania przeciwko tej zmianie. To jest właściwy punkt, aby omówić wysiłki (i wydatki) z klientem. Prawdopodobnie nie powstrzyma to klienta przed zbudowaniem tej funkcji, ale z czasem wyczują aplikacje i dyskusje na temat „uuh, jesteś taki drogi!” będzie znacznie mniej wybredna.

Nie wiem, czy znajdujesz się w porównywalnej sytuacji, ale dowiedziałem się, że sytuacja interesariusza niekoniecznie wiąże się z tym samym wzrostem złożoności, jak w przypadku deweloperów i architektów systemu informatycznego. W tej sytuacji komunikacja pomaga obu stronom.

Przepraszam, ale to pytanie brzmi jak drobna prośba o ojcowską radę. W takim przypadku dobry programista będzie musiał przyjąć te przykazania:

• Pozostańcie sobie wierni. Jeśli twoje jelita czują się nieswojo z powodu funkcji, wypowiedz swoje obawy na głos. Są duże szanse, że zespół czeka właśnie na otwarcie.
• Nie próbuj zastępować doświadczenia regułami doświadczonego. Dla Ciebie każda sytuacja jest inna, każda funkcja jest nowa. To plus, którego nie mają twoi seniorzy.
• Tworzenie oprogramowania nie jest nauką ścisłą, nigdy nie będzie. Dlatego gromadzą mądrość, a nie zachowanie.
• Zaakceptuj porażkę. Jeśli zespół zgodzi się inaczej, nie powtarzaj swoich obaw ad nauseam.
• Myśl pozytywnie. Jeśli pomysł jest naprawdę błagający o „zestrzelenie go”, spróbuj znaleźć i nazwać go pozytywnymi aspektami, zanim wymienisz jego braki.
• Dowiedz się, jak wchodzić w interakcje z ludźmi. My, programiści, często stawiamy wiedzę techniczną na kompetencje społeczne. Umiejętności techniczne osiągają szczyt we wczesnym okresie życia, ale kompetencje społeczne mogą rosnąć aż do przejścia na emeryturę.

Wierzę w odsuwanie złych wymagań. Ale wierzę również, że kiedy postarałeś się jak najlepiej wyjaśnić, dlaczego są źli i nadal ich chcą, to zgadzasz się i wykonujesz swoją pracę.

Na przykład miałem ludzi, którzy chcą wymagań, które wykluczają się z czegoś, co aplikacja już robi. Jeśli to zrobię, będzie to, w 100% gwarantowane, przerwa. Odsyłam więc wymaganie z powrotem i mówię, że to złamie tę inną regułę biznesową, którą już mamy i czy oni też chcą zmienić tę regułę? Często mała grupa, która spełnia określone wymagania, nie ma dostępu do większego obrazu tego, co może zrobić reszta aplikacji. Przez większość czasu, gdy odesłałem jedną z nich, klient zdał sobie sprawę, że zasada intialna była bardziej krytyczna i zdecydował, że pożądana zmiana nie była tego warta. Kiedy zdecydowali się dokonać zmiany, zrobili to po konsultacji z ludźmi, którzy wprowadzili początkowy wymóg.

Czasami samo zadawanie pytań wyjaśniających sprawi, że zauważy, że problem nie jest tak prosty, jak im się wydawało. Czasami chcesz zapytać, dlaczego czegoś chcą i dojść do prawdziwej potrzeby, która napędza zmianę. Kiedy to zrozumiesz, często łatwiej jest znaleźć alternatywne rozwiązanie, które działa jako programista i spełnia ich potrzeby. Jeśli potrafisz przedstawić to rozwiązanie pod kątem tego, w jaki sposób lepiej zaspokoi ich potrzebę niż pierwotna sugestia, znacznie zwiększyłeś swoje szanse na zaakceptowanie zmiany.

Czasami, gdy zmiana spowoduje spustoszenie na podstawowym poziomie w twoim projekcie, wystarczy podać im nowy szacunkowy czas potrzebny na zmianę, aby ją wyłączyć. Jeśli połączysz to z oceną ryzyka, która wskazuje, na jaką krytyczną funkcjonalność możesz wprowadzać nowe błędy, mówiąc im, że zajmie to 6 tygodni poświęconego wysiłku przez 3 osoby, nagle nie jest to już tak ważne.

Ale czasami mówisz im, że to nie jest dobry pomysł i dlaczego, a oni wciąż mówią: „Szkoda, że ​​tego potrzebujemy”. Niektóre wygrywasz, a niektóre tracisz, a czasem potrzeby biznesowe naprawdę się zmieniły i aplikacja musi to uwzględnić. Po sfinalizowaniu decyzji nie ma już czasu, aby zadawać pytania o to, co robisz, i czas na zrobienie tego. Jeśli udokumentowałeś swoje zastrzeżenia, to osobiście powinieneś być w dobrym miejscu, gdy przekroczy budżet i spowoduje nowe i bardziej ekscytujące błędy. I mogą być nawet bardziej skłonni cię wysłuchać następnym razem, gdy osiągniesz dobre wyniki w tego rodzaju sprawach.

Kluczem do wygrania wielu z tych dyskusji (nikt ich nie wygra) jest przede wszystkim zdobycie doświadczenia w zakresie wiedzy o tym, o czym mówisz. Następnie wyślij pisemny dokument z informacją o swoich obawach (wielu menedżerów jest ryzykownych, częściej nie chcą, aby ktoś miał dokument potwierdzający ich późniejszy błąd, więc zwracają większą uwagę na to, co napisałeś) aby upewnić się, że rozumieją wszystkie koszty (nie tylko godziny, ale także zagrożenia bezpieczeństwa, wprowadzanie nowych błędów, niedotrzymywanie terminów itp.) wprowadzenia zmiany. Zmiana nie jest darmowa i muszą to zrozumieć. Następnym kluczem jest zrobienie tego jak dorosły, a nie jak jęczące dziecko („ale nie chcę używać ... bo mi się nie podoba”). Zrób uzasadnienie biznesowe, że tego nie zrobisz, a dostaniesz znacznie więcej, odpychając złe wymagania.

Jeśli dobrze cię przeczytam, prawdziwe pytanie dotyczy nieznanej złożoności. Początkowo czytam twoje pytanie: „Widzę niezwykle prawdopodobne ryzyko nadmiernej złożoności, ale szef nie”. Ale mówisz, że szef nie jest problemem, więc rozumiem, że nie jesteś pewien, jakie ryzyko dodawania niedopuszczalnej złożoności są.

W takim przypadku zaleciłbym jakąś strategię ograniczania ryzyka. Obraz, który zastanawiasz się nad dodaniem usług WCF / sieciowych do interfejsu API, co może być niesamowite lub skomplikowane bez nagrody:

• dodaj funkcję do oddziału. Jeśli to działa, połącz je. Jeśli zamieni się w gniazdo szczurów, zabij je.
• odpal nowy jednostronicowy projekt i zrób dowód koncepcji. Jeśli nie możesz zrobić dowodu koncepcji w krótkim czasie, upuść go. Jeśli dowód koncepcji działa, powiększ go i zintegruj ze swoim
• przeszukuj Internet w poszukiwaniu osób, które interesują się tą funkcją lub technologią. Tam, gdzie dzieje się wiele problemów, technologia może stanowić realne ryzyko nadmiernej złożoności. Java Beans i COM + są prawdopodobnie starymi, ale dobrymi przykładami funkcji, które naprawdę zwiększyły złożoność i mogły, ale nie muszą, dostarczyć korzyści po stronie równania

Argument nr Omów ewentualnie tak. Ale należy to traktować jako dodatek do specyfikacji i traktować priorytetowo z innymi funkcjami. Jeśli wiesz, że prośba doda nieuzasadnionego czasu i złożoności do wdrożenia, poinformuj o tym z góry. Nie jako sprzeciw wobec wykonania prośby, ale jako wyjaśnienie tego, co twoim zdaniem zajmie wdrożenie.

To bardzo zależy od żądania. Implementacja wskaźnika jest na tyle duża, że ​​ma wpływ na cały projekt, więc jego zalety należy rozważyć, jeśli zostanie podjęty wybór.

Wdrożenie przycisku, który przerywa przepływ. Może nie jest to taka wielka sprawa, jeśli formularz można ułożyć w taki sposób, że przycisk jest opcjonalny. Zrobiłem to w rzeczywistości. Dodałem przycisk, ale zebrałem też wystarczającą ilość informacji, zanim przycisk stał się opcjonalny. Użytkownicy, którzy spodziewali się, że tam będzie, korzystali z niego, a ci, którzy zdali sobie sprawę, że jest po prostu zbędny, nie korzystali.

Chodzi o równowagę i wiedzę, kiedy wybrać bitwy. Niektóre rzeczy i tak łatwiej jest po prostu wdrożyć niż zajmować się społecznymi aspektami ich nieuwzględnienia.

Problem, jaki widzę, polega na tym, że używasz słowa argument.

Musisz poruszyć problemy projektowe i ich uzasadnienie, ale bądź ostrożny, ponieważ programiści mają tendencję do obrony przed zajmowanymi pozycjami i argumentują punkty tylko ze względu na kłótnie (czasami). Muszę powstrzymać się od kłótni - i nie zawsze mi się to udaje. Również z wiekiem stwierdzam, że się mylę częściej niż kiedyś - albo, co gorsza, nie rozpoznałem, jak często się myliłem :)

Jeśli masz jasno określone wymagania (język musi być bezpieczny, potrzebujemy wskaźników, aby uzyskać dostęp do starszych procedur), możesz przedstawić, w jaki sposób oba wymagania kolidują i zapytać, co jest ważniejsze. Gdy masz już wymagania i powody, możesz nawet znaleźć zupełnie inne rozwiązanie, które obsługuje oba wymagania (JNI - kinda).

Jeśli tak się nie stanie, być może jest to dobry moment na ich skodyfikowanie!

1. Uświadom sobie, że nie wiesz wszystkiego i nie możesz zrobić wszystkiego.

2. Jeśli jesteś pewien, że to zły pomysł, powiedz, co jest złe.

3. Jeśli spróbują narzucić ci to, powiedz albo - Potrzebujesz więcej czasu na analizę, jeśli potrzebujesz więcej czasu lub powiedz, że nie znaleźliśmy dobrego rozwiązania tego problemu.

4. Jeśli nadal nalegają na wdrożenie złego pomysłu, uzyskaj od nich potwierdzenie, że odradzałeś go, podając powody. Możesz nawet wysłać wiadomość e-mail z podsumowaniem dyskusji z kopią do swojego kierownika. To może zaoszczędzić ** później.

W idealnym scenariuszu miałbyś wiodącego programistę, który podejmuje ostateczne decyzje po stronie technicznej, oraz biznesowego lidera, który podejmuje ostateczne decyzje po stronie biznesowej. Pozwoliłoby to odpowiedzieć na dwa główne pytania:

1 co? Czego chce klient?

2) Jak? Jak to osiągnąć z perspektywy technologii.

Klient chce ostatecznego decydenta, ponieważ to oni płacą rachunki

Jako programista nie powinieneś przejmować się, które wymagania należy wdrożyć.

Powinieneś jednak wyjaśnić, czy coś jest nierealne i czy istnieją lepsze sposoby.

Czasami jest to w rzeczywistości żądanie klienta (pochodzące z wewnętrznej polityki klienta). Wtedy jest to beznadziejne i musi zostać wykonane (ale kierownictwo powinno również rozważyć, czy kontynuować taki projekt, czy też powinny renegocjować cenę).

Jest to dla mnie prawie codzienne zadanie i tak naprawdę się cieszę.

Jeśli masz zamiar wydać opinię na temat tego, czy określone wymaganie powinno być częścią wniosku, osoby nietechniczne będą oczekiwać, że uzupełnisz swoją wiedzę techniczną (np. „Użycie wskaźników spowodowałoby niestabilność aplikacji” lub „użycie parametr GET dla X jest zagrożeniem bezpieczeństwa ”). Pracownicy techniczni również doceniliby Twoją opinię na temat określonych zalet lub wad, o których być może nie pomyśleli.

Oczywiście jest ciężko, gdy wszyscy chcą funkcji X, a ty w końcu mówisz „to może nie być dobre”, ale ostatecznie wszyscy starają się stworzyć bezpieczną, solidną i stabilną aplikację (łatwą w utrzymaniu, elastyczną itp.) ) i każdy głos powinien się liczyć.

Odpowiadając na twoje pytanie, nie jest to zadanie programisty (czyli programowanie), ale jest to „dodatkowe” narzędzie, które zapewnia jakość i pracę zespołową.

Jeśli jesteś w stanie zrozumieć wady robienia tego (złożoność, brak użyteczności itp.), To w najlepszym interesie wszystkich leży wyjaśnienie tego najlepiej, jak potrafisz. Często osoby niebędące programistami nie rozumieją problemów związanych z dodawaniem nowych funkcji. Jest to dla nich łatwe, ponieważ nie muszą nic robić ani nawet o tym myśleć.

Jeśli jednak moce decydują o dodaniu nowej funkcji, powinieneś wykonać najlepszą możliwą pracę. To wyzwanie.

A jeśli nowa funkcja jest zbyt głupia lub środowisko pracy jest zbyt kiepskie, nadszedł czas, aby znaleźć inną pracę.