somekind napisał(a):
Nie wiem, co właściwie próbowałeś osiągnąć wrzucając przykład SQLite do dyskusji o korporacyjnych koszmarkach, ale to już teraz nieważne.
Nie przytaczałem SQLite.
Widzę, że zaczęło się ad personam, więc argumenty merytoryczne zostały wyczerpane.
No zaczęło. Nie wiem w sumie po co ci one były.
danek napisał(a):
Generalnie chyba rozmawiacie o różnych rzeczach. Jest kod który ma działać szybko i jest kod który ma być czytelny. I to nie zawsze ten sam kod
Pisałem o dobrej literaturze w sensie kodu posiadającego unikalne konstrukty i rozwiązania, a o "dobrej" obiektówce z jej wzorcami jako o sztampie, czyli powtarzalnej masówce. Somekind zaś zaczął coś pisać o tym, że to dobra literatura, bo nietechniczni mogą jego zdaniem czytać. Co raz nie przeczy samo w sobie posiadaniu przez taki kod sztampowości, dwa nie jest prawdą moim zdaniem. Teraz zaś się obraził, bo nie zrozumiał co przeczytał. Whatever...
Mam propozycje, napiszcie "Hello World." w Javie i Assemblerze, a potem dyskutujcie na temat tego, która implementacja jest czytelniejsza.
Pędzący Młot napisał(a):
Nie przytaczałem SQLite.
Wybacz, myślałem po prostu, że to Ty, skoro tak aktywnie kontynuujesz.
No zaczęło. Nie wiem w sumie po co ci one były.
Jeśli zatem nie chcesz brać udziału w dyskusji, to najlepiej w ogóle nie zaczynaj. Oszczędzisz czas - swój oraz innych.
Pędzący Młot napisał(a):
Teraz zaś się obraził, bo nie zrozumiał co przeczytał.
Ty postawiłeś tezę, że za dobry kod w językach obiektowych uważa się kod sztampowy, czyli że sztampowość kodu decyduje o jego jakości. Tymczasem ja odpowiedziałem jaki faktycznie kod jest uznawany za dobry w językach obiektowych. To jest kod CZYTELNY. To, czy DOBRY I CZYTELNY kod jest sztampowy, czy nie, jest kwestią ortogonalną.
Somekind zaś zaczął coś pisać o tym, że to dobra literatura, bo nietechniczni mogą jego zdaniem czytać. Co raz nie przeczy samo w sobie posiadaniu przez taki kod sztampowości, dwa nie jest prawdą moim zdaniem.
Ale co nie jest prawdą? Możliwość pisania kodu biznesowego zrozumiałego dla biznesu? Jeśli tak, to współczuję.
._. napisał(a):
Mam propozycje, napiszcie "Hello World." w Javie i Assemblerze, a potem dyskutujcie na temat tego, która implementacja jest czytelniejsza.
Nie w Javie, nie w assemblerze, tylko w języku do tego wyspecjalizowanym trzeba napisać. HQ9+ wymiata.
jarekr000000 napisał(a):
._. napisał(a):
Mam propozycje, napiszcie "Hello World." w Javie i Assemblerze, a potem dyskutujcie na temat tego, która implementacja jest czytelniejsza.
Nie w Javie, nie w assemblerze, tylko w języku do tego wyspecjalizowanym trzeba napisać.
HQ9+wymiata.
nie da sie
chciał bez przecinka...
ujednolicenia systemu komentarzy (o ile są potrzebne / wymagane)
jedyne sensowne ujednolicanie systemu komentarzy to ich usuwanie, reszta tego typu inicjatyw to strata czasu
usłyszałem od przełożonego coś w stylu "jak się wyrobisz i jeszcze znajdziesz na to czas to ok"
to nie przelozony jest specjalista od twojego kodu a ty wiec takie dyskusje generalnie maja malo sensu i prowadza glownie do frustracji. rob swoje, porzadnie.
nikt nie płaci za jednolite zasady stawiania średników, nowych linii i odstępów, to tylko nasza sprawa byśmy się połapali w tym co robimy
to akurat racja - nikt normalny sie w to nie bawi, to zadanie IDE
Czy dbanie o czytelny, dobry kod jest tak ważne by spowalniać proces developmentu
dbanie o czytelny, dobry kod przyspiesza development. jak ktos tego nie ogarnia to go to z miejsca dyskwalifikuje do do dyskusji na ten temat.
Zastanawiam się w jaki sposób pisanie kiepskiego kodu jest szybsze od pisania go dobrze. Trzeba być leniwym mądrze, oszczędzanie na nazwach zmiennych, tworzeniu nowych metod czy klas jest bez sensu, bo prowadzi do większych nakładów pracy na pisanie kodu, nie mówiąc już o jego poprawianiu. Uwaga, niespodzianka: clean code, testy jednostkowe, wzorce projektowe i reszta tych zabawek została wymyślona po to, żeby narobić się mniej, a nie więcej.
A ja nie rozumiem, czemu ludzie się uczepili tego "pisania kodu" (wszystko jedno czy ładnego, czy brzydkiego), jakby praca programisty polegała po prostu na siedzeniu i klepaniu.
Z moich doświadczeń o wiele więcej czasu zajmuje myślenie, projektowanie w głowie rozwiązań, rzeczy, które są ponad/poza kodem. Czy to będzie projektowanie architektury aplikacji, czy zastanawianie się nad algorytmem czy konkretną metodą implementacji (te wszystkie małe decyzje, nawet te czysto techniczne, jak np. czy użyć biblioteki X czy Y albo "czy obrazki powinny być wektorowe czy rastrowe' ).
Chociaż owszem, czasami trzeba napisać jakiś "throw away code", jakiś PoC, żeby sprawdzić pewne rozwiązania w praktyce - ale mimo wszystko samo "pisanie kodu" to najmniejszy problem czasowy. To co zajmuje czas, to zdobywanie wiedzy, know-how, design rozwiązania, i nie zależy to od szybkości słów na minutę, czy liczby naklepanych słów w IDE.
Moim zdaniem błędem wielu ludzi jest to, że od razu próbują napisać kod produkcyjny, zamiast przemyśleć sprawę na spokojnie, ew. napisać jakiś prototyp na szybko, i dopiero potem myśleć o pisaniu kodu produkcyjnego.
Widzę duży odzew, dobrze. W sytuacji że robi się coś by tylko działało, ale było zrobione szybko to klient odbiera, zatwierdza, sprawa zamknięta to rzeczywiście nie warto dbać o jakoś kodu bo klient oczekuje tanio, szybko i jakoś-tam działać ma. Porównując do knajp to czekając na pociąg lub robiąc zakupy chce dostać coś tanio, by zabić głód sporo i się od tego nie rozchorować, a jak jeszcze ciepłe i ma smak to już super.
W opisanej na początku sytuacji sprawa wygląda tak: jeden kilku osobowy zespół z bardzo małą rotacją, program na wewnętrzny użytek klienta, prawie dwa lata temu kod przejęty po innej firmie. Kod masakra spaghetti, od tego czasu dużo rzeczy powstało od nowa. Na tym kodzie zespół będzie pracował jeszcze przez rok co najmniej. Szacowanie czasu na taska odbywa się patrząc na proces od góry tak: Klient mówi chce mieć taką i taką dodatkową funkcjonalność, na kiedy i za ile, chcę by kierownicy po zalogowaniu się do systemu mieli możliwość zobaczenia bardziej szczegółowych danych dotyczących tras kierowców, zwłaszcza zależy mi na danych naniesionych ma mapę, na kiedy i za ile, potem ustalanie szczegółów, ale o tym już nie wiem nic jak to wygląda. Potem na podstawie terminów i stopnia skomplikowania szacowanie poszczególnych tasków decyzja czy robić byle jak by działało, czy przywiązywać większą uwagę do kodu. Więc nie są to ani rzeczy, zrób, zapomnij, następny PSD, ale też nie robione z myślą o rozwijaniu przez następne kilkanaście lat przez kilkuset programistów. Klient świadomie czasem woli mieć coś gorszego ale już za miesiąc jak za pół roku.
Jak to rozumieć "ma jakoś tam działać"? W sensie są pewne błędy albo nawet baza gdzieś tam nie wyrabia na pewnych zapytaniach ale to nie przeszkadza klientowi? To nie taka prosta sprawa coś przepisać, bo żeby to było możliwe trzeba dobrze ogarniać cały projekt. Nie wiem czy ktoś próbował cokolwiek przepisywać np. z samego Wordpressa na jakiś framework. Tragedia. I np. pierwotny twórca serwisu czyli firma która opiera się np. w całości o Wordpress i na tym realizuje różne projekty. Później np. coś tam się wywala albo klient chce nowe funkcjonalności, przychodzi do realizacji przez kolejną firmę gdzie programiści specjalizują się w czymś innym. To nawet nie musi być Wordpress ale cokolwiek innego i nie mówię o samym PHP. Współczuję.
Zresztą przepisywałem kiedyś też taką aplikację na desktop z DELPHI na Lazarusa, gdzie niby jest możliwość importu ale to też nie taka prosta sprawa a później na .NET C# i też już sprawa wyglądała inaczej. Czyli ogarnąć projekt pisany przez pierwotnego twórcę żeby to później w miarę szybko przepisać a to i tak zajmie X czasu. Klientowi można próbować tłumaczyć albo twardo postawić sprawę, co też jest możliwe w przypadkach gdy nie ma chętnych do rzeźbienia w jakimś syfie ale to i tak w ostatecznym rozrachunku musi się skalkulować.