Kiedy staje się przesada?

10

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 ?!

Theofanis Pantelides
źródło
1
Czy mówimy o skalowaniu go dla miliona użytkowników od pierwszego dnia, kiedy nie masz obecnie klientów? Lub bardziej funkcjonalne rzeczy, takie jak uczynienie sposobu obliczania podatków „konfigurowalnym”, gdy nie ma sugestii, że mogą się kiedykolwiek zmienić, a nawet jeśli nikt nie miał pojęcia, jak mogą działać w tym hipotetycznym nowym świecie?
Jon Hopkins
1
Społeczność Wiki jest przestarzała. To nigdy tak naprawdę nie działało zgodnie z planem. Nie martw się o to.
David Thornley
Kiedy mówisz o milionie użytkowników, przesada nie powinna być w twoim słowniku.
Theofanis Pantelides,

Odpowiedzi:

12

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).

Społeczność
źródło
5
Walczę ze
2
Niekoniecznie się z tym zgadzam (praktycznie), biorąc pod uwagę nierówny poziom programistów. Wiele razy refaktoryzuję podobne projekty, aby korzystać ze wspólnej biblioteki, która nie zawsze jest tak czytelna jak wcześniej.
Theofanis Pantelides
1
Myślę, że bardzo ważne jest, aby każdy członek zespołu dobrze rozumiał kod źródłowy, nad którym pracują. Dla bogactwa twojego projektu, a także, aby architekt nie był niewolnikiem własnych wdrożeń. Więc jeśli jest zbyt duża różnica w wiedzy, napraw to najpierw.
1
Lubię twoje pierwsze zdanie; jasność kodu jest ważna. Ale częste recenzje kodu? Dyskusje architektoniczne na codziennych spotkaniach ... Naprawdę? A co dokładnie oznacza „architekci napędzani CV”?
Robert Harvey
1
Częste przeglądy kodu oznaczają, że muszą być automatyczne. Piszesz funkcję, jedna z twoich koleżanek recenzuje ją i musi ją zrozumieć, aby ją zweryfikować. Jeśli zadaje ci pytania, pracujesz razem, aby ulepszyć kod. Wspominasz o swoich problemach architektonicznych podczas stand-up, ale dyskusja następuje później. Przeczytaj Kto potrzebuje architekta ( martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf ). Napędzany CV oznacza, że ​​wybierzesz technologię, ponieważ chcesz ją w swoim CV
11

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.

stacja końcowa
źródło
4

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.

Jon Hopkins
źródło
Co powiesz na modularyzację wszystkiego, a następnie po prostu wymianę modułów podczas skalowania? czy to też jest przesada !?
Theofanis Pantelides
1
@ Theofanis Patelides - Dobrze skonstruowany kod jest oczywiście zawsze dobrym pomysłem, ale jak w przypadku większości rzeczy z pewnością możesz posunąć się za daleko. Myślę, że z wieloma z tych rzeczy z czasem staje się instynkt - wiesz, co zrobiłeś wcześniej, co się udało i co było stratą czasu.
Jon Hopkins
1

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.

gablin
źródło
Zgadzam się, ale wielokrotnie zdarzało mi się spędzać wiele godzin na funkcjonowaniu, a następnie przekazywać go nietechnicznemu użytkownikowi i odrzucać z powodu drobnych rzeczy!
Theofanis Pantelides
1

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.

Rachunek
źródło
1
Dla mnie nie ma nic bardziej irytującego niż odstąpienie od planu A
Theofanis Pantelides,
1

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! :)


źródło