Dlaczego usuwanie kodu wywołuje niesmak?

Dla klienta większe znaczenie ma programista, który dodaje nowe funkcje niż ten, który poprawia po innych.

Z tego też względu mało który programista przywiązuje uwagę do czystości kodu. Kodzi się bardziej na szybko, bardziej dla maszyny niż dla człowieka. Wtedy spojrzenie w kod wywołuje zamroczenie, a jedynie autor wie (chociaż to i tak wątpliwe) jakie tajemnice, kryją się w jego kodzie.

Ja lubię upraszać i minimalizować kod, ale jak współpracować z innymi programistami program, gdy każdy cechuje się odmiennym podejściem?

Też się borykam z tym problemem, i jeszcze nie znalazłem dobrego sposób na to. Generalnie wychodzę z założenia, że lepiej nie walczyć z wiatrakami, tylko zmienić otoczenie.
Najgorsze w sumie nie jest to, że inni programiści robią chlew, tylko to, że jak się im zwróci uwagę, to walą focha.

0. Nie rozumiem co tytuł ma wspólnego z pytaniami w wątku...
1. To że klient nie lubi płacić za poprawianie błędów jest chyba dość oczywiste. Klient uważa że skoro zapłacił za napisanie funkcjonalności X to ma prawo oczekiwać że jest napisana dobrze. Wyobraź sobie że kupujesz samochód i okazuje się że jedno z kół się nie kręci i musisz dopłacić za taką poprawkę ;)

Z tego też względu mało który programista przywiązuje uwagę do czystości kodu

2. o_O? Mów za siebie i za swoją firmę. Firma w której aktualnie pracuje dość mocno przykłada uwagę do jakości kodu - review każdej zmiany, częsty refaktoring słabego kodu, sonar, checktyle etc. Ale to jest sprawa organizacji pracy twojej firmy / twojego zespołu.

jak współpracować z innymi programistami program, gdy każdy cechuje się odmiennym podejściem

3. To dość jasne - ustalić pewne zasady i standardy. Są przecież narzędzia które mierzą "jakość kodu" (checkstyle, findbugs, sonar). Można robić inspekcje każdego commita. Można też kazać pisać testy jednostkowe. Testy mają to do siebie że napisanie testów (które mają 100% pokrycia) dla slabego kodu jest bardzo bardzo trudne i często okazuje się że bez refaktoringu słabego kodu nie uda się napisać testów.

Dla klienta nie ma znaczenia co robi programista -dla niego ma znaczenie końcowy produkt który otrzymuje. Wymaga aby został on wykonany szybko, tanio oraz w wysokiej jakości. Oczywiście mocno utopijnym założeniem jest możliwość 100% spełnienia tych wszystkich 3 warunków. Należy znajdować kompromisy i dostosowywać je do sytuacji. Zupełnie inaczej patrzy się na jakość kodu w 2 tygodniowym projekcie w agencji interaktywnej (chociażby konkurs na FB czy jakaś 5 zakładkowa strona na temat akcji promocyjnej) a inaczej tworząc produkt który ma być utrzymywany i sprzedawany przez następne 2 lata.
Jeśli osoba zarządzająca projektem ma chociaż elementarną wiedzę na temat sposobów wytwarzania oprogramowania, to zdaje sobie sprawę, że w dużych systemach błędy popełnione na początku prac lub bałagan w kodzie po kilku tygodniach okażą się wielokrotnie droższe niż dbanie o dobrą jakość kodu. Jeśli u Ciebie w firmie jest inaczej to polecam już zacząć szukać innego pracodawcy, bo lada moment utoniecie w żmudnej walce z kodem, która dla żadnej ze stron nie będzie komfortowa (koderzy, firma, klient).

Z drugiej jednak strony jak widzę gościa, który w mega prostym, 3 dniowym projekcie rozmyśla całymi dniami nad jego architekturą, rysuje pełne diagramy UML, rozpisuje architekturę na kilku stronach w Wordzie i wydłuża tym samym czas projektu o 500% to jest już ewidentny przerost formy nad treścią.

Ja lubię wycinać kod, zwłaszcza jeśli to nie ja go pisałem. Specjalizuję się w usuwaniu "wzorców projektowych" :-)

Ja lubię dzielić kod na mniejsze kawałki. Np. wywlić jedną dużą funkcję na 100 linijek i zastąpić dzisięcioma mniejszymi. Już mi się klawisze Ctrl-Alt-M od tego w klawiaturze wytarły.

A co powiecie na ponad 1000 linijkowe funkcje :P? Z takimi to dopiero jest ubaw.

Ogólnie praca w domu jest dużo lepsza i na pewno ładniejsza pod względem kodu, niż praca w firmie. Wynika to z prostego powodu:

• łatwiej pracować w pojedynkę będąc dobrym programistą i dbać o kod, niż znaleźć dziesięciu lub więcej programistów o podobnym podejściu do programowania. Zawsze znajdzie się (i takich jest więcej) łebków co zepsują kod jak to tylko możliwe. A klepanie ctrl + c oraz ctrl + v to powszechna ich metodyka działań :)

niż znaleźć dziesięciu lub więcej programistów o podobnym podejściu do programowania
Dlatego muszą być ścisłe wytyczne co do stylu kodu i nie ma że każdy ma inne swoje upodobania.
Po swojemu to na swoim :-)

Zawsze znajdzie się (i takich jest więcej) łebków co zepsują kod jak to tylko możliwe.
A grzebałeś kiedyś w kodzie po Chińczykach? ;-)

Prawda jest taka, że jak przychodzi się do jakiegoś projektu i widzi jakiegoś babola, to wtedy lepiej nie dotykać tego. Po prostu nie ma się jeszcze dostatecznej wiedzy o danym kodzie co dokładnie robi i za co odpowiada, więc próba naprawienia prawie na pewno skończy się jakimś poważniejszym błędem.
Dopiero, gdy dłużej się pracuje z jakimś kodem wtedy, warto się brać za takie cuda.

Klient płaci za nowe funkcjonalności, a nie za poprawianie już istniejących (m.in. usuwanie starego kodu). Poza tym masz zasadę - Działa nie ruszaj!