Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Tworzenie oprogramowania dobrej jakości

Wielokrotnie przeglądając forum, konkretnie wątki poświęcone problemom programistów, bardzo często ręce mi opadają i wcale nie dziwię się, że ludzie mają problemy a ich kod nie działa. Kod ten jest pisany bez większego planu i pokazuje braki programisty z zakresu podstaw inżynierii oprogramowania. Jednak nie to najbardziej kłuje w oczy. Największym problemem który dostrzegam to braki w znajomości podstawowych wzorców projektowych w związku z czym i brak podziału na warstwy w pisanych aplikacjach. Drugi z problemów najczęściej dotyczy koderów PHP, u innych pewnie nie byłoby o wiele lepiej gdyby platforma nie wymuszała uruchamiania np. komunikacji przez sieć lub operacji I/O na innym wątku.

Opiszę dziś jeden z podstawowych problemów czyli umieszczanie w plikach widoków (zawierających kod HTML) kodu odpowiedzialnego za walidację oraz komunikację z bazą danych. Poniżej przedstawiam odnośnik do przykładu z życia wziętego.

Przykład złego kodu z życia wzięty

Jak widać na poniższym przykładzie mamy całkiem niezły makaron, pomieszanie widoku i zagnieżdżone kilka odwołań do funkcji komunikacji z bazą danych. Być może dla początkującego programisty nie wygląda to najgorzej. Jednak gdy spojrzeć na ten kod z perspektywy osoby która miałaby go rozwijać przez najbliższe kilka lat nie jest już tak kolorowo. Pozwolę sobie opisać najbardziej złe nawyki oraz podać informację jak pisać się powinno aby uniknąć problemów.

Wielokrotne odwoływanie się bezpośrednio do funkcji mysqlowych.

Przypuśćmy że mamy takich „widoków” 20 i w każdym odwołujemy się bezpośrednio do funkcji mysql. Nagle po roku przychodzi klient i mówi że przepinamy się na bazę postgresa, oracle lub Bóg wie co jeszcze. Chyba potraficie sobie wyobrazić ile pracy was czeka aby zrobić taką przepinkę. Co można zrobić żeby uniknąć takiej sytuacji? Mamy kilka opcji.

  • Możemy skorzystać z pomocy ORM’ów, w PHP osobiście używam Propela. Oprócz niego istnieje Doctrine, z którym nie miałem nigdy styczności. ORMy poza pośredniczeniem między bazą danych, mapowaniem wyników zapytań na obiekty itp., oferują jeszcze zabezpieczenie przed atakami SQL Injection. ORMy to podstawa w większości zintegrowanych frameworków PHP takich jak Symfony, Zend, Kohana.
  • Jeśli z jakiegoś powodu nie możemy/chcemy korzystać w projekcie z ORM’a możemy napisać prosty adapter w którym uwzględnimy zapytania sql, oraz który będzie nam zwracał konkretne wyniki.
    Np. Tworzymy klasę UserDao (DAO – Data Access Object) z metodą createUser, której parametrami będą: nazwa użytkownika, imię, nazwisko, hasło itp. W body owej metody wpiszemy: mysqli_query($link, "insert into users (login, haslo, imie, nazwisko, email) values ('$login',md5('$haslo'),'$imie','$nazwisko','$email')"); Później zamiast wywoływać wszędzie mysqli_query możemy wywołać metodę z naszej klasy. Dzięki temu wystarczy zastąpić naszą klasę odwołującą się do mysql inną odwołującą się do np. postgresa, ale implementującą ten sam interfejs, aby zmienić silnik bazy danych w naszej aplikacji. Klasa UserDao, powinna mieć metody wyszukania, skasowania oraz wylistowania użytkowników.

Pomieszanie widoku z kodem biznesowym.

Wyobraźmy sobie że tworzymy naszą aplikacje w sposób taki jak w linku, który podałem wcześniej. Po jakimś czasie okazuje się, że nie jesteśmy już w stanie rozwijać aplikacji w pojedynkę i postanawiamy zatrudnić webdeveopera i fachowca od HTML, CSS, JS czyli frontendu. Aby podrasował wizualnie naszą aplikacje. Problem w tym że ów fach nie ma zielonego pojęcia o PHP i bazach danych. Wystarczy że wytnie przez przypadek jedną linie za dużo i katastrofa gotowa. Rozwiązań jak zwykle jest kilka.
  • Możemy skorzystać z gotowego systemu szablonów np. Twig lub Smarty. Dzięki czemu część biznesową przetworzymy w PHP, do szablonu przekażemy jedynie to co niezbędne do wyświetlenia informacji dla użytkownika. W takiej sytuacji jeśli webdevoloper popełni błąd logika biznesowa, walidatory itp., dalej będzie działać bez problemu.
  • Jeśli nie możemy/chcemy skorzystać z systemu szablonów możemy część widoku umieścić w osobnym pliku PHP, który zostanie dołączony na końcu przetwarzania naszego skryptu i który wyświetli jedynie wynik naszemu użytkownikowi.

Podsumowując

Brak sensownej architektury w aplikacji może doprowadzić w późniejszym etapie jej rozwoju do wielu błędów i niejednokrotnie zwiększy nam koszty (to nie tylko pieniądze ale też czas, który można by wykorzystać na coś innego) utrzymania takiej aplikacji. Osobiście polecam wykorzystać do tworzenia aplikacji webowej jakiegoś frameworku. Jeśli Zend lub Symfony jest zbyt ciężki polecam Kohane.

Osobiście zawodowo programuje w wielu językach programowania min. Java, ActionScript3, PHP, JavaScript. Z własnego doświadczenia wiem, że jeśli ktoś potrafi dobrze programować to nie powinien mieć problemu z programowaniem w żadnym języku. Mam nadzieje że mój wpis się wam spodobał. Jeśli tak, postaram się w przyszłości stworzyć więcej poradników jak tworzyć dobrej jakości kod. Jeśli macie jakieś pomysły na kolejny odcinek zapraszam do komentowania.
 

bezpieczeństwo porady programowanie

Komentarze

0 nowych
kostek135   8 #1 15.08.2014 21:51

Programować każdy może, trochę lepiej lub trochę gorzej, ale nie o to chodzi code-fix'em się wszystko zakodzi.

Autor edytował komentarz.
Frankfurterium   10 #2 15.08.2014 23:18

Taka wiedza przychodzi z doświadczeniem, a to z kolei najłatwiej nabyć, osiem godzin dziennie zasuwając na etacie, gdzie jest się od kogo uczyć i ma się od kogo dostać po łapach za potworki.

mordesku   8 #3 16.08.2014 07:00

@Frankfurterium: Masz rację, chociaż ja żałuje, że gdy zaczynałem nie trafiłem na taki właśnie tekst. Często ludzie początkujący bagatelizują jakość a później ciężko jest im się wyzbyć złych nawyków (wiem z własnego doświadczenia ;)).

Frankfurterium   10 #4 16.08.2014 10:40

Jak to ktoś napisał wczoraj na forum - w PHP może napisać coś każdy i będzie to jakoś działało. Niby zaleta, ale właśnie przez tak niski próg wejścia powstał popularny żart: "Najkrótszy żart programistyczny? Programista PHP".

(Btw. żart o żarcie... Meta-żart?)

mordesku   8 #5 16.08.2014 12:46

@Frankfurterium: To prawda, że łatwo można zacząć. Niestety można przez niewiedzę można się doś szybko zapędzić w kozi róg, w którym łątwiej będzie zacząć od nowa niż zmodyfikować to co mamy. Co do żartu - widziałem taki kod w javie i as3, przy którym takie makarony PHP'owe wcale tak źle nie wyglądają. Ale to wynika z uczenia programowania przez tzw. "tutoriale/szkółki". Według mnie lepiej jak by taki początkujący poczytał o podstawowych wzorcach Gangu Czterech niż miałby czytać te "szkółki", które nauczą go złych praktyk.

Frankfurterium   10 #6 16.08.2014 14:22

Tu się nie do końca zgodzę. Pamiętam moje pierwsze zderzenia z kanonicznymi wzorcami projektowymi. Niby rozumiałem kod, wiedziałem, o co mniej więcej biega, ale nijak nie mogłem wymyślić, gdzie i jak miałbym tego użyć. Wszystko przyszło z czasem i wypłynęło prawie że samo z siebie. Np. przy implementacji wielowątkowego bufora ktoś polecił użycie producenta-konsumenta i bum, oświecenie. A kiedy czytałem o tym wzorcu na sucho, wydawał mi się fanaberią.

kostek135   8 #7 16.08.2014 14:27

@mordesku:
Co do Javy, też nie musisz daleko szukać: http://forum.dobreprogramy.pl/java-jsf-mysql-od%C5%9Bwie%C5%BCanie-tabeli-obiekt.../

Przy czym sam fakt, że to Java, sprawia, że da się po dłuższej chwili ogarnąć co się dzieje.

Podoba mi się stamtąd najnowsza uznana przez wiele wybitnych umysłów świata programistycznego, metoda zabezpieczeń przed SQL Injection.

"INSERT INTO //SQL zapisujący do tabeli"

Można rzecz nie pokaże wadliwej SQL-ki, nie będzie problemu ;) można by o tym doktorat zrobić...

PS Mój pomysł na wpis, to często widuje się tu, jakieś podsumowanie miesiąca. Być może podsumowanie co miesiąc 5-10 najgorszych fragmentów programów? Tak, żeby wytknąć co jest źle, być może się kiedyś nauczą.

Autor edytował komentarz.
mordesku   8 #8 16.08.2014 14:41

@Frankfurterium: Zależy od tego z jakich źródeł czerpie się wiedze. Osobiście polecam książkę "Head First Design Patterns". Bardzo fajne i życiowe przykłady. Często do niej wracam :). Poza czytaniem warto też sobie implementować wzorce w miarę ich poznawania i jeśli to możliwe konsultować ich implementacje z bardziej doświadzczonymi. W końcu tak wygląda nauka, Czytamy, ćwiczymy i jesteśmy Masterami :D. Samo czytanie to za mało.

mordesku   8 #9 16.08.2014 14:43

@kostek135: Dobry temat, top 5 najgorszych kodów, takie review ze wskazaniem dlaczego jest źle. Mam nadzieje że czasu mi starczy :D

enedil   9 #10 17.08.2014 00:35

Ciekawy temat, zajrzałem ale...! Napisałeś w jednym zdaniu "PHP" i "programowanie" ;)

Mam jednego znajomego, który twierdzi, że programuje, ale przodukuje kod-makaron. Moim zdaniem w kodzie produkcyjnym jak najwięcej elementów powinno być wywołanych jawnie. On polega na rozszerzeniach języka i trikach.

Jusko   13 #11 17.08.2014 01:31

Ja z kolei myślę, że przyda się więcej dystansu do całej sprawy i pewny podział.

Istnieją bowiem programiści zawodowi, którzy pisaniem kodu zarabiają na życie - praca wymusza, aby ten kod działał jak ma i był czytelny do tego, trzymając pewne standardy jakości. Delikatne napomknięcie się przyda, bo dobry kod to cenna rzecz.

Istnieją też drudzy, którzy piszą z własnej ambicji - po prostu kodują dla hobby w myśl zasady: "ważne, że działa". Taka osoba nigdy nie zostanie programistą, nie ma ku temu ambicji, może ma inne kompetencje zawodowe przy których programista-specjalista wymięka (bo jest właśnie programistą a nie np. biologiem). I potępianie takich osób oraz narzekanie na makaron byłoby niesprawiedliwe, bo dobrze pisać ładny kod, ale to nigdy nie będą profesjonalni zawodowcy, którzy muszą trzymać wszelkie standardy korpo-jakości kodu ;-) Za to mają chęć od czasu do czasu coś sobie napisać ;-)

Niemniej makaron zdarza się każdemu. Pracowałem np. w firmie, która produkuje oprogramowanie chyba od 20 lat i choć wiadomo, że kod jest nieco kaszana, ale robi co ma i nikt teraz tego nie tknie (choćby aby unowocześnić kod), aby soft nie zawalił się jak domek z kart :-) Niemniej kod jest zamknięty, no to nikt go nie widzi, zatem sprawy "nie ma" ;-) Podejrzewam, że tak bywa częściej - choćby dlatego, że pewnie ilu by nie zajrzało w kod, tak większość chciałaby go poprawić po swojemu, zatem nikt nie rusza tego, co działa :-)

Autor edytował komentarz.
kostek135   8 #12 17.08.2014 03:08

@Jusko:
Odnośnie twojego 3 akapitu.
Nie masz racji. Ja z młotkiem i wiertarką nie chodzę po forach dla mechaników samochodowych i nie dopytuje się jak naprawić silnik z użyciem tego co mam, wstawiając filmiki z tego jak uderzam młotkiem w tył wiertarki przy wlewie z paliwem. A tak to wygląda w przypadku wstawianego kodu przez tych jak ich nazwałeś "hobbystów".

Co do ostatniego. Zdarzają się wypadki, a nie zły kod.
Współczuję też organizacji w firmie. Myślałem, że decyzję w sprawie takich rzeczy jak code refactoring powinien podjąć PM w konsultacji z PA. W ogóle przez myśl by mi nie przeszło, żeby pytać któregoś z programistów o plan działania. To trochę tak jakby kierownik budowy do spółki z architektem, pytali się tych co mieszają zaprawę i noszą cegły, co należy zrobić z danym problemem. Ogólnie do dobry b...ałagan musi tam być, jak każdy ma swoją wizję świata. Smutne to.

Autor edytował komentarz.
mordesku   8 #13 17.08.2014 09:55

@Jusko: Akapit 3 przeczy pierwszemu akapitowi :). Niestety bardzo często taki "hobbysta programista" zaczyna szukać pracy w fachu. Zatrudnia się w firmie i tworzy makaron. Jeśli chodzi o zamknięcie kodu to niestety czasami przez błąd administratora serwera (http://niebezpiecznik.pl/post/allegro-wyciek-kodu-zrodlowego-niektorych-plikow-php/) kod zostaje "otwarty" co prawda dotyczy to głównie języków skryptowych takich jak php. Prawda jest taka że nawet jeśli coś robimy tylko hobbystycznie to nie oznacza, że musimy to robić źle. Mój wpis powstał po to aby zwrócić uwagę tym osobom, którym nie raz nie ma kto jej zwrócić, a które chcą się rozwijać w fachu lub hobby.

Autor edytował komentarz.
flaszer   10 #14 17.08.2014 10:50

Niestety, początkującego taki wpis nie uświadomi, on musi nauczyć się na swoich własnych błędach ;) O nie pisaniu spaghetti-code i innych potworków jest wiele pozycji, na start dobrze też przeczytać np. "Czysty Kod" Roberta Martina. Co do stosowania samych wzorców projektowych, może wypuściłbyś jakąś serię o tym traktującą? Niekoniecznie w PHP ;)

SebaZ   16 #15 17.08.2014 10:54

@mordesku piszesz dużo o widokach, pomieszaniu kodu biznesowego z widokiem. Bierzesz tu pod uwagę tylko jeden wzorzec projektowy (no może 2 jeśli rozdzielić MVC i MVP)? Chyba mało trochę to ma wspólnego z inżynierią oprogramowania czy właściwą analizą systemu informatycznego.

mordesku   8 #16 17.08.2014 11:21

@flaszer: zastanawiałem się właśnie czy nie zacząć od jakiegoś konkretnego wzorca czy może napisać bardziej ogólnie. Postawiłem na bardziej ogólny temat. Postaram się w takim razie w miarę możliwości opisywać różne wzorece w kolejnych wpisach.

@SebaZ: MVC/MVP w zasadzie definiuje architekture aplikacji. Nie chciałem pisać o innych wzorcach bo co za dużo to nie zdrowo. Postaram się w kolejnych wpisach opisywać kolejne wzorce. Ale przyznaje wpis wprost nie mówi jak pisać oprogramwanie dobrej jakości ;)

flaszer   10 #17 17.08.2014 11:27

@mordesku: Wydaje mi się, że dobrze by było opisać po prostu najczęściej używane wzorce wraz z jakimiś realnymi zastosowaniami.

enedil   9 #18 17.08.2014 12:08

@Jusko w tym problem, że ten kolega planuje iść na studia programistyczne.

mikolaj_s   14 #19 17.08.2014 12:38

@Jusko: "Niemniej kod jest zamknięty, no to nikt go nie widzi, zatem sprawy "nie ma" ;-) "
Póki działa nie ma problemu, ale to jak zamiatanie brudów pod dywan. Kiedyś wreszcie wylezie. Oprogramowanie IT to bardzo dynamiczny rynek, jak coś się zmienia to w tym rynku to taki program trzeba przepisać. Dobrze jeśli duża część kodu może być ponownie użyta. Niestety takie firmy działają bardzo krótkowzrocznie.

". I potępianie takich osób oraz narzekanie na makaron byłoby niesprawiedliwe, bo dobrze pisać ładny kod, ale to nigdy nie będą profesjonalni zawodowcy, którzy muszą trzymać wszelkie standardy korpo-jakości kodu ;-) "

Potępianie nie jest sprawiedliwe, ale pokazywanie, że można lepiej ma sens. Nawet hobbysta chciałaby wykonywać swoje hobby coraz lepiej.

GioWDS   14 #20 17.08.2014 13:17

Mam być szczery? 8h na etacie dopiero uczy pisania makaronu - pokaż mi firmę gdzie zamiast zarabiać pieniążki przykłada się uwagę do jakości kodu- jak mamy klienta na jeden strzał nikt nie będzie się specjalnie martwił o to, że potem seowcy będą się z tym bawić :) Większy klient na długą mętę? Jeśli CRM na który 2-3 osobowy team potrzebuje 3-2 miesiące powstaje w tydzień klepany przez jedną osobę. Jak miałem to optymalizować to złapałem się za głowę jak coś takiego można napisać. Zapytania robione na szybko, 2-3x pobierane te same treści, ogólnie SELECT * FROM * i to wykonujące się po 30-40s gdzie właściciel firmy musiał te zapytania tyle razy ile jest pracowników we wszystkich oddziałach, potem jeszcze to samo ale przy wyliczaniu statystyk oddziałów no i potem przy całej firmie. Jak właściciel wchodził to serwer (6x3.2GHz, 32giB DDR3) po prostu przestawał odpowiadać [po HTTP] na 2-3 minuty :)

mordesku   8 #21 17.08.2014 13:26

@GioWDS: chyba czas zmienic pracę ;)

  #22 17.08.2014 15:32

@GioWDS: Po emotikonie na końcu ma się rozumieć, że tobie ten stan rzeczy odpowiada i czujesz się jak ryba w wodzie?

"pokaż mi firmę gdzie zamiast zarabiać pieniążki przykłada się uwagę do jakości kodu"
Dlaczego uważasz, że to się wyklucza?

SebaZ   16 #23 17.08.2014 15:44

@GioWDS Przy jednorazowych klientach rzeczywiście nie warto pisać dobrej jakości kodu - on ma robić to co ma robić i koniec kasa na koncie ma się zgadzać... i tyle. Z drugiej strony w firmach jednostrzałowych nie tworzy się własnego oprogramowania, a wykorzystuje i modyfikuje jakiś open source, CRM to SugarCRM, sklep to magento, PrestaShop lub (o zgrozo) oscommrece.

@mordesku pracę trzeba zmieniać kiedy ktoś musi, potrzebuje lub czuje, że powinien. Przez prawie 2 lata byłem jedynym programistą w firmie z kilkoma dużymi serwisami internetowymi. Pisałem, kodowałem co trzeba było i... miało to działać - nie ważne jak. W dodatku nie było nikogo kto by to skontrolował, poza klientem (pracodawcą), który poklikał i sprawdził czy działa tak jak on chciał. Problemem jest tutaj bycie panem i władcą, nie ma cię kto skontrolować i lecisz tak jak poprzednik albo jak sam to kiedyś napisałeś, żeby nie tracić czasu na refaktoryzację kodu - choć byłaby wskazana. Nie oszukujmy się - programista to leniwa bestia :P

kostek135   8 #24 17.08.2014 16:06

@SebaZ: "Przy jednorazowych klientach rzeczywiście nie warto pisać dobrej jakości kodu - on ma robić to co ma robić i koniec kasa na koncie ma się zgadzać... i tyle."

Problem zaczyna się wtedy, kiedy musisz wprowadzić jakąś zmianę, np. okazało się, że biznes licencji na DB2 nie da rady załatwić i lecimy na Oraclu, a ty wszędzie hard-kod pod DB2. Who cares?

"Nie oszukujmy się - programista to leniwa bestia :P"
I ta leniwość przejawia się tym, że w 50 miejscach machasz String "SELECT a,b,c FROM tabela" i jak trzeba wyciągnąć potem jeszcze kolumnę d, to zmieniasz to w 50 miejscach? Przy czym o dwóch prawdopodobnie zapomnisz i spędzisz leniwie następne 2 godziny na debugowaniu czemu to nie działa. Lenistwo, tak bardzo... Ja to z czystego lenistwa zrobił bym to DAO, tylko po to, żeby wystarczyło zmienić jeden String.

Autor edytował komentarz.
mordesku   8 #25 17.08.2014 17:02

@kostek135: @SebaZ: może leniwość owa polega pewnie na copy/paste? W myśl zasady nie ważne co tam jest, ważne że dostaje stamtąd to czego chcę, więc to skopiuje :D.

  #26 17.08.2014 20:47

@mordesku: przykra sprawa, ale duże pieniądze nie leżą w korpo, gdzie możesz ewangelizować ze wzorców projektowych, algorytmów, niewybrednych struktur danych i innych wzniosłych tematów. W cenie są ludzie, którzy potrafią skutecznie i SZYBKO rozwiązywać problemy oraz dostarczać na czas. Owszem, wspomniana wiedza jak najbardziej się przydaje, ale nie w takim stopniu jak na to kładziesz nacisk.

Obecnie niewiele nowego kodu powstaje. Często i gęsto pracujesz z kodem kogoś innego. Refaktoryzacja to czasochłonne zajęcie i zawsze istnieje szansa, że nie ogarniesz wszystkich przypadków generując przy tym inne problemy...

Także jeżeli chcesz wykazać się profesjonalizmem to polecam nie wybrzydzać przy nadmiarze "makaronu", bo zaręczam Ci, że Twój kod dla kogoś innego też może awansować do stopnia "makaronu". Weźmiesz na warsztat projekty z Bangalore to odkryjesz, że najlepszy makaron nie pochodzi z Włoch ;-)

Sumując. Nie znam firmy, która pedantycznie dba o "piękny kod" i nadal trzyma się na powierzchni sowicie płacąc programistom. Bynajmniej nie taka, której software stanowi trzon strategii biznesowej. Ale może jeszcze mało widziałem.

  #27 17.08.2014 22:00

Co do ba danych, nie wyobrażam sobie życia bez odm (nieudana przesiadka z mysql do oracle trwał mniej więcej 5 minut, siadła wydajność, ale działało z kraulem). Co do doświadczenia, na początku pisze się prosty kod, potem coraz bardziej skomplikowany (a czasem przekominowany) by na koniec znów wrócić do najprostszej formy.

kostek135   8 #28 18.08.2014 08:22

@Ja, programista (niezalogowany): Jeśli dla ciebie pedantycznymi są, enkapsulacja odwołań do BD oraz rozdzielenie widoku od logiki, to winszuję. I chyba tu powinna zakończyć się dalsza dywagacja.

Poza tym pochwal się z jakimi to tuzami wielkiego świata biznesu outsourcingowanymi do Indii, miałeś do czynienia, a które są makaronem. Bo jak do tej pory nie widziałem takich. Widziałem za to masę ludzi, którzy na nie płaczą, a nie rozumieją nawet podstaw działania systemów IBM czy Oracle. W myśl zasady, nie rozumiem, nie nauczę się, za trudne, skrytykuje.

Autor edytował komentarz.
  #29 18.08.2014 09:13

@kostek135: Ło matko...ależ poczułem się osaczony. Ja powinszuję Ci w momencie osiągnięcia oceny choćby dostatecznej z przedmiotu "czytanie ze zrozumieniem".

"Jeśli dla ciebie pedantycznymi są, enkapsulacja odwołań do BD"

Czytanie ze zrozumieniem #1. Albo w ogóle czytanie w tym przypadku.

"pochwal się z jakimi to tuzami wielkiego świata biznesu outsourcingowanymi do Indii"

Czytanie ze zrozumieniem #2. A może nie było outsourcingu, a bezpośrednia współpraca? I owszem, bardzo duża i powszechnie znana marka.

"podstaw działania systemów IBM czy Oracle"

IT to nie tylko systemy bazodanowe...prawda?

Śmieciowy komentarz, ale rozumiem, że chciałeś coś mocnego przekazać, tyle że nie wyszło. Życie.

mordesku   8 #30 18.08.2014 09:59

Czytam te komentarze usprawiedliwiające tworzenie złego kodu. Żaden z tych argumentów do mnie nie przemawia. Ostatecznie za kodem stoi programista, który go stworzył. Pozatym to że wcześniej ktoś zrobił kupe na środku pokoju to nie znaczy że ja też muszę. Wypadało by wręcz posprzątać.

Jeśli komuś nie pasuje nauka dobrego kodowania nie zmuszam. Ten wpis powstał dla tych którzy CHCĄ się rozwiajć.

GioWDS   14 #31 18.08.2014 13:43

Oż ty, ileż to razy zostałem oznaczony w postach :P
W pracy korzystamy z bardzo fajnego narzędzia jakim jest Asana - liczy się stosunek odznaczonych zmian do czasu pracy. @mordesku jak myślisz ktoś interesuje, że żeby wprowadzić drobną zmianę chesz przerobić 5000 linijek kodu [po czym będzie ich 300] bo tak będzie fajnie w zgodzie z PSR, etc? Nope, masz wprowadzić zmianę.
Pracodawce bardzo szybko zainteresuje dlaczego zmianę, którą inny pracownik wprowadza w 5 minut ty wprowadzasz w 2 godziny. Jak klient dostanie fakturkę na 2-3 tysie zamiast na 2 stówki to daj wiarę ktoś tu zrezygnuje - najpewniej klient z firmy, a firma z Ciebie.
Na potrzeby firmy tworzyłem CMF z całym podstawowym toolkitem, orm, itp.
Przez pierwszy tydzień musiałem się tłumaczyć dlaczego strona jeszcze nie skończona. Przy wprowadzaniu zmian już nikt takich pytań nie zadaje kiedy spore zmiany wprowadzam w kilkanaście minut grunt, że przy małym nakładzie czasu można wystawić zdrową fakturę.

Draqun   9 #32 18.08.2014 13:50

Akurat z PHP jest taki problem, że większość tutoriali w sieci jest zwyczajnie nieaktualna. Dodatkowo uczą one w większości tylko i wyłącznie języka a nie jak poprawnie programować.

Jeśli masz czas możesz opisać najczęściej wykorzystywane wzorce projektowe w programowaniu webowym. Wiem, że jest tego sporo więc na początek jak możesz opisz MVC i jego odmianami (Model1, Model2, MTV) a także w jakich frameworkach można je spotkać.

mordesku   8 #33 18.08.2014 13:51

@GioWDS: Ciekawe co by powiedział klient gdyby na starcie dostał informacje zrobimy dobrze przez 0,5 roku - pozniej praktycznie koszty utrzymania żadne. Albo zrobimy w 2 miesiące i przez dwa lata bedziesz nam płacił za serwis :D

GioWDS   14 #34 18.08.2014 14:42

Kwestia jak kto pisze, jeśli to jest makaron, ale dobry makaron, nie wiem, Lubella? I działa to dobrze, mimo, że dużo zbędnego kodu, że niezgodne z żadnym standardem i tak jak u nas, jeśli są jakieś poprawki to raczej doprecyzowanie wizji klienta. Jeszcze nikt klientowi nie kazał płacić za błędy programisty.
No, ale liczmy, że jeden programista będzie pracował na projektem. Nie zakładam żadnego zysku dla firmy.
Przy pracy przez pół roku:
koszt = [pensja] * 6 [czas] * 2 [podatki]
Koszt pracy przez 2 miesiące i nawet doliczmy, że dodatkowy m-c w sumie zejdzie na poprawkach:
koszt = [pensja] * 3 [czas] * 2 [podatki]
Nawet jeśli koszty całościowe miałyby być identyczne to daj wiarę, że klient szybciej zapłaci tą samą kwotę w ratach niż w jednym strzale. Pomijam fakt, że w trakcie realizacji projektu 3/4 rzeczy i tak zmienisz.
Nie twierdzę, że takie podejście jest dobre - jest złe to jasne jak słońce, ale takie są realia rynku i klient często mając nowatorski pomysł często i gęsto woli puścić produkt nie dopracowany do końca lub z ograniczonymi możliwościami. Ustalmy coś: 90% stron firmowych to wizytówki, które nie potrzebują CMS-a, a grafik zrobi szablon za 5 stówek.

mordesku   8 #35 18.08.2014 15:06

Jeśli mówimy o stronie wizytówcie z cms'em lub bez to czas wdrażania takiego projektu opartego o dobry cms nie powinien trwać według mnie dłużej niż tydzień (nie licząc pracy grafika i wliczając poprawki) - wiem z doświadczenia. Oczywiście są wyjątki. Jeśli mamy makaron i pomieszanie widoków z kodem biznesowym w naszym cms wtedy czas rosnie bo taki webdeveloper musi uważać żeby za dużo nie pousuwać a jak po usuwa to musi poprawiać - wiem również z doświadczenia.

Autor edytował komentarz.
kostek135   8 #36 18.08.2014 17:30

@Ja, programista (niezalogowany): Ehh... co do #1 to jeszcze czekam na wycieczki osobiste. Inaczej nie będzie fajnie :(

Poza tym jeśli ty IBM i Oracle kojarzysz tylko z Bazami Danych to o czym my mówimy.

Proszę to co ma do zaoferowania IBM: http://www-03.ibm.com/software/products/en/category?pgel=lnav

Tu masz Oracle: http://www.oracle.com/us/products/index.html

"Śmieciowy komentarz, ale rozumiem, że chciałeś coś mocnego przekazać, tyle że nie wyszło. Życie."
Mocnego? Ja tylko czekam na te przykłady makaronu z Indii. Chcę je zobaczyć naprawdę.

Autor edytował komentarz.
matelord   9 #37 18.08.2014 18:10

Kod kodem, makaron makaronem, ale jak ktoś jest samoukiem i gdzieś się pomyli, coś źle zrozumie to do czasu jak go ktoś nie poprawi będzie robił błędy. Proste

luki288   5 #38 18.08.2014 19:22

Owszem należy starać się pisać czysty kod i ułatwiać życie, także sobie.

Z tym, że tak cukierkowo, różowo i rajsko o wszelkich wzorcach i dobrych praktykach może sobie pisać ktoś, kto tworzy projekty na uczelnię/stosunkowo małe projekty komercyjne.
A życie życiem i zderzenia z deadline'ami, narzuty czasowe niezbędne na trzymanie się wzorców lub kombinowanie jak pozostać z nimi w zgodzie, problemy wydajnościowe z narzędziami takimi jak wychwalany przez autora ORM, sprawiają, że człowiek zaczyna krytycznie patrzyć na kwestie wzorców i dobrych praktyk.

#r2d2#   11 #39 18.08.2014 19:31

Nie rozumiem dlaczego nie ma czegoś takiego jak "programista PHP". Przecież PHP jest językiem programowania, więc dlaczego nie może być programisty PHP?

mordesku   8 #40 18.08.2014 19:38

@luki288: jeśli aplikacja jest napisana dobrze, podzielona na warstwy to każdą warstę można zastąpić zupełnie inną implementacją i dzięki temu bez problemu można pozbywać się wąskich gardeł i optymalizować. Jeśli napiszemy kod bardzo zależny od siebie często nie pozostaje nic innego jak zacząć od nowa.

luki288   5 #41 18.08.2014 20:28

@mordesku: Tak jak napisałem wyżej, ogólnie rzecz biorąc warto stosować wzorce, starać się pisać czysty kod. Podział na warstwy to wspaniała sprawa.

Jednak do niczego nie można podchodzić bezkrytycznie, a po drugie życie często weryfikuję dobre chęci. Zobaczysz biorąc udział w naprawdę dużych projektach

mordesku   8 #42 18.08.2014 20:33

@luki288: po czym poznać że biore udział w naprawdę dużych projektach?

kostek135   8 #43 18.08.2014 20:58

@luki288: Nie żeby coś, ale początkowo właśnie u nas tworzyliśmy projekty w stylu "Budowa szopy z Zenkiem za flaszkę". W momencie w którym przeszliśmy na Scrum z pełną analizą, dokumentacją i code review, tak żaden projekt nam się nie obsunął o więcej niż 2 tygodnie (projekty rozplanowane na około 4-6 miesięcy dla 8 osób).

Jeśli chcesz zacząć stawiać dziesięciopiętrowy budynek, to nie możesz myśleć uff udało się jakoś to drugie piętro postawić, jest koślawo, chwieje się, ale teraz kombinujmy z trzecim, tak żeby całość się nie zawaliła. No chyba, że lubisz mieszkać w takim domu.

luki288   5 #44 18.08.2014 22:24

@mordesku: Po ilości kodu, modułów, zaangażowanych programistów, przetwarzanych danych.

Autor edytował komentarz.
luki288   5 #45 18.08.2014 22:30

@kostek135: Kolejny raz powtórzę, nie widzę nic złego w stosowaniu wzorców. Co więcej widzę ich zalety i w pracy staram się je wykorzystywać. Ale odrzucam ślepe podążanie za wzorcem bo tak trzeba, tak mówią tak się robi.

Sam wielokrotnie zetknąłem się z sytuacjami, przy których wykorzystanie wzorca dodało spory narzut czasowy i nic poza tym, lub stosowanie się do wszystkich założeń wzorca było niemożliwe bez brzydkich kombinacji. W takich sytuacjach wolę odpuścić stosowanie takiego wzorca.

mordesku   8 #46 19.08.2014 07:26

@luki288: ile musi być zatem kodu, modułów i jakie musi być zaangażowanie programistów żeby projekt nazwać naprawdę dużym? 100k lub 200k lini, 5, 10 czy 15 modułów. Nie wiem jak się mierzy zaangażowanie ale powiedzmy, słabe zaangażowanie to pewnie tylko duży a naprawdę duży zaczyna się od mocnego zaangażowania?

Ślepe trzymanie się wzorców też nie jest dobre. To tylko wzorce na których trzeba się wzorować. Pozatym wzorce nie wzieły się z powietrza jeśli uważasz, że potrafisz coś zrobić lepiej opisz to i stwórz własny wzorzec.

Autor edytował komentarz.
Nalapl3   3 #47 28.08.2014 18:04

@#r2d2#: Też nie rozumiem.