Kiedy staje się przesada?

Po pierwsze przepraszam, bo nie wiem, jak zrobić wątek społeczności; więc niech ktoś mi pomoże.

Jako programista na wielu platformach, technologiach, a nawet na poziomie infrastruktury; Zawsze zastanawiam się, kiedy robię ZA DUŻO?!?

To był niekończący się proces uczenia się, odkąd zacząłem. Jedną (1) rzeczą, której się nauczyłem, jest to, że wymagania nie są ważne przez dłuższy okres czasu i dlatego taka krótka dalekowzroczność może przejść długą drogę.

Ale gdzie jest równowaga i skąd wiesz, kiedy tracisz czas, a nie zyskujesz go ?!

Robisz za dużo, gdy przeciętny programista nie może zrozumieć, co zrobiłeś , czytając kod.

• Dokonuj częstych recenzji kodu ze swoim zespołem.
• Omów z architekturami, technologiami lub wzorcami, których planujesz użyć. (w codziennych spotkaniach stand-up, jeśli je masz)

Walczę ze wszystkimi „architektami”, których napotyka CV . Chciałbym, żeby kopuła istniała! ;)

Wierzę, że świat marnuje ogromny stos pieniędzy, które moglibyśmy wykorzystać na ulepszenie życia (programisty).

Kiedy procesy wyprzedzają wyniki.

Zbyt wiele razy widzieliśmy, że jeśli programiści bardziej koncentrują się na procesie, a nie na wynikach (jak na jakości, dotrzymywaniu terminu itp.), Zaczynają się złe rzeczy.

Dlatego nigdy nie należy zapominać, że celem przeglądów kodu, wzorców projektowych itp. Jest ulepszenie kodu, ale same nie są celem.

Dla mnie podoba mi się podejście, które Kent Beck proponuje w XP (nie jestem pewien, czy to „jego” pomysł czy ktoś inny, ale właśnie tam go usłyszałem):

Wystarczająco trudno jest rozwiązać dzisiejsze problemy, nie próbując dowiedzieć się, jakie są jutrzejsze problemy, a także je rozwiązać.

Deweloperzy mogą poświęcić dużo czasu na rozwiązania nieistniejących wymagań, wyjątkowe przypadki, które nigdy nie wystąpią, a nawet autentyczne problemy, których wpływ jest znacznie mniejszy niż koszt zapobiegania.

Jest to czas, który można poświęcić na rzeczy, których użytkownicy naprawdę będą chcieli i używają, rzeczy, które dadzą im korzyści, które znacznie przewyższą nawet niedogodności, które zostaną spowodowane w mało prawdopodobnym przypadku, gdy jedna z tych rzeczy się wydarzy.

Poza tym nieoptymalnym rezultatem dla użytkownika, wpływ na programistę nadmiernej inżynierii w ten sposób jest zwykle złożony na złożonym kodzie, który jest trudniejszy do obsługi i trudniejszy do ulepszenia.

Więc dla mnie, jeśli wiesz lub możesz być całkiem pewien, że coś jest wymogiem lub spowoduje problem, rozwiąż je, jeśli nie, to nie.

Być może będziesz musiał wrócić i przerobić go, gdy okaże się, że wymaganie było szersze niż pierwotnie wprowadzone, ale ogólnie całkowity wysiłek włożony w projekt będzie nadal mniejszy, ponieważ w większości przypadków tak się nie stanie.

Twoje pytanie jest dość otwarte, dlatego zinterpretuję je jako „robienie zbyt wiele w jednej części projektu”:

Dla mnie łatwo jest spędzać zbyt dużo czasu na czymś, co tak naprawdę nie zapewnia dużego zysku klientowi. Często są to drobne rzeczy, takie jak „Cóż, działa, ale nie do końca tak, jak ja tego chcę”, gdzie klient prawdopodobnie nie dbałby o to, czy zadziałałoby w ten czy inny sposób.

Kiedy to się stanie, powinienem to zatrzymać i poświęcić czas na rzeczy, które są ważniejsze. Lepiej jest, aby produkt działał jako całość niż nie, ale masz te mniejsze części, które działają idealnie.

Pisanie kodu śledzenia (z Code Complete ) jest prawdopodobnie dobrym pomysłem na uniknięcie tego: Rozpocznij swój projekt od napisania kodu, który łączy cały kod - od GUI (lub w jego pobliżu) aż do backendu, a następnie z powrotem. W ten sposób zawsze masz coś, co działa i nie spędzasz czasu na doskonaleniu drobiazgów, dopóki wszystko się nie skończy.

Ale nadal jest to kwestia dyscypliny i ustalania priorytetów.

Kiedy odpowiadam „nie, oszaleję”, nie zrobiłem tego później i to mnie gryzie.

IRL Zasoby i ograniczenia czasowe zwykle powodują, że muszę dużo zadawać to pytanie. W tym momencie skupiasz się na najważniejszych / osiągalnych bitach i masz nadzieję na najlepsze.

naprawdę niekończący się proces uczenia się! ... i myślę, że tak pozostanie! Bilans jest wtedy, gdy wszystko jest wystarczająco wydajne i masz czas na zrobienie czegoś innego oprócz programowania. Zgadzam się z gablin „kwestią dyscypliny i ustalania priorytetów” i Jimem Hopkinsem, że po pewnym czasie staje się instynktem. Wiem, że udoskonalanie małych części jest tym, co nas cieszy, ale ostatecznie chodzi o to, co sprawia, że ​​użytkownik końcowy jest szczęśliwy. więc powiedziałbym, że równowaga (a może kompromis) sprawia, że ​​użytkownik końcowy / klient / klient jest najpierw szczęśliwy (co powinno być planem A), a następnie, jeśli jest czas na doskonalenie - zwiększenie wydajności „małych części” i / lub wszystko, co chcesz. W pewnym momencie musisz powiedzieć „dość” :) w przeciwnym razie tak, stanie się to przesada!

najgorszym scenariuszem jest oczywiście sytuacja, w której użytkownik końcowy / klient / klient to Ty! :)