Studenci i hobbyści lubią pisać kod dla samej zabawy pisania kodu. Stąd różnorodność rozwiązań w każdej niemal kategorii oprogramowania. Dzięki temu klony Uniksa są dziś najbardziej elastycznymi systemami. Sytuacja wygląda jednak nieco inaczej w przypadku oprogramowania komercyjnego.
Każdy chce się pochwalić swoimi umiejętnościami i chętnie napisałby wszystko od zera, ale w odróżnieniu od oprogramowania OpenSource, w komercyjnych rozwiązaniach obowiązują terminy, a głównym czynnikiem napędzającym całą zabawę są pieniądze. Ważne nie jest popisanie się, ale efektywne zgospodarowanie czasu, stąd pisanie własnych rzeczy często jest niepożądane.
Zanim zabierzesz się za pisanie własnego modułu, silnika czy jakiegokolwiek elementu oprogramowania, rozejrzyj się po rynku. Sprawdź czy istnieją gotowe rozwiązania, z których mógłbyś skorzystać i zaoszczędzić czas. Jeśli nie uda ci się znaleźć nic, co pasowałoby do twojego projektu, zainteresuj się tymi, które nie pasują. Sprawdź, jaką mają bazę użytkowników, czy znane są jakieś błędy, z jakimi problemami borykają się ci, którzy im zaufali i czy nie żałują swojej decyzji. Zobacz, czy nie da się ich zaadaptować za pomocą minimalnych zmian.
Pisanie własnego systemu powinno być ostatnim podejmowanym krokiem. Jeśli nie znajdziesz nic, co mogłoby ci zaoszczędzić czasu, to zaoszczędź go sobie sam - przeznacz czas na zaplanowanie swoich działań zanim napiszesz choćby linijkę. Zastanów się nad architekturą, porównaj ją z istniejącymi i skorzystaj z poznanej wcześniej listy problemów. Pisanie oprogramowania, które nie będzie się nadawało do wdrożenia mija się z celem, tak samo jak napisanie od zera kolejnego pakietu o identycznej funkcjonalności.
Pamiętaj, że prawdopodobnie nie będziesz jedyną osobą dbającą o ów kod - zaplanuj go rozwojowo i tak, żeby wprowadzanie zmian nie wymagało przepisywania dużych fragmentów kodu. Przygotuj choćby krótką dokumentację - twoi współpracownicy nie będą mieli czasu na czytanie całości kodu za każdym razem, kiedy potrzebują z niego skorzystać. To jest właśnie największa zaleta korzystania z szeroko stosowanych rozwiązań - problemy za ciebie rozwiązują inni. Ty możesz skupić się kodzie funkcjonalnym, a nie na poprawianiu używanych narzędzi i bibliotek.
Reasumując: w pracy codziennej pisze się masę nowego kodu, ale staramy się ograniczać do tego, którego napisanie jest nieodwołalne. Cała reszta to koszty, które dla pracodawcy nie przynoszą żadnego zysku (poza kodem, o który trzeba dbać, co pochłania dalsze ilości czasu, a w efekcie przekłada się znów na pieniądze).
Inna sprawa, że trzeba zainwestować sporo czasu w poznanie obecnie 'obowiązujących' technologii. Tzn. jeśli chodzi o wuwę, to warto mieć już jakieś doświadczenia z np. mambą, drupalem i wordpressem. A bawienie się tym trochę trwa.
Poza tym mam wrażenie, że poruszając tego typu tematy piszesz (ja zresztą też) strasznie oczywiste rzeczy.
Taka luźno związana uwaga, mój przełożony rzucił swego czasu tekstem: "nie ma znaczenia, czy to będzie działać, ważne żeby się dało wdrożyć" ;)
A tak na serio, z obserwacji w moim aktualnym miejscu pracy: dokumentowanie kodu, a przez to jego reużywalność jest fikcją. Właśnie z powodu terminów, o których piszesz, mnóstwo poprawek jest robionych ad-hoc, bez tworzenia jakiejkolwiek dokumentacji developerskiej, pisana jest jedynie dokumentacja "biznesowa" niezbędna do zatwierdzenia zmian przez klienta. I nie mam tu na myśli komentowania każdej linijki kodu, ale brakuje nawet ogólnego zarysu zależności pomiędzy poszczególnymi modułami.
Wszystko ładnie wygłąda w teorii (lub hobbistycznym pisaniu Open Source) natomiast praktyka jest już niestety zupełnie inna.
Co jest dla mnie o tyle dziwne, że imho projekt, który ma przynajmniej założenia dobrze udokumentowane, powinien być w stanie się rozwijać szybciej, niż taki, gdzie tylko dodaje się hacki.
A ja potwierdzam, bo jakiś czas temu wyrzuciliśmy właśnie poprzedni system CMS i zaczęliśmy pisanie nowego od zera. W porównaniu z tamtym, nanoszenie poprawek to marzenie.
Problem w tym, że dokumentowanie kodu (szczególnie takie z myślą o reużywalności) zajmuje niewiele mniej, lub czasem nawet więcej, czasu niż samo kodowanie. Jeśli płacą ci za kod, to po prostu dokumentacji pisać się nie opłaca. Tak samo jak pisania "reusable code".
Mi płacą za pracę, bo jestem na stałym zatrudnieniu. A do komentowania kodu używamy PHPdoc, co jest dla nasz wystarczające. Komentowanie każdej linijki kodu to przesada. Najważniejsze jest udokumentowanie architektury kodu, czyli wszystkich klas, metod i zależności.
My już nie tyle mówimy o dokumentacji samego kodu, bo ten, o ile nie jest w jakiś masakryczny sposób napisany, powinien być w miarę zjadliwy. Imho najważniejsze jest utrzymywanie dokumentacji dotyczących miejsc w kodzie, gdzie on musi się dogadywać z jakimiś innymi podsystemami. W drugiej kolejności zapewne przydałaby się dokumentacja tabelek w bazie danych, bo wtedy znacznie szybciej można załapać gdzie coś poprawić, jeśli chce się to poprawić.
Jajcuś, wydaje mi się że nie do końca nie ma sensu. Nawet jeśli jesteś płacony za kod, lepszym rozwiązaniem jest wklejenie reużywalnego kodu np. z poprzedniego projektu niż pisanie od zera, dlatego że wychodzi wtedy wyższy współczynnik ilość kodu do czasu pracy, co jest opłacalne dla firmy softwareowej.
Dlatego mówię o PHPdoc, tam komentarze mówią też o strukturze całego projektu, podziale na moduły i zależnościach. Wiadomo też, kogo winić za dany kawałek kodu.
Jeśli masz ten reużywalny kod z poprzedniego projektu. Ale robiąc tamten projekt nie wiedziałeś co będzie w następnym. Chcąc robić kod uniwersalny ryzykujesz, że się napracujesz (koszty), a nie masz gwarancji że to wykorzystasz. Oczywiście często warto — ale z umiarem i jak już to tylko to, czego ktoś inny nie zrobił (większość rzeczy, których się używa wielokrotnie, już została zrobiona).
Żeby zrobić rzeczywiście reużywalny kod, to trzeba się namęczyć. Dlatego tak długo trwa przygotowanie porządnej, komercyjnej biblioteki do czegośtam (choćby takie qt do gui i innych rzeczy). Dlatego lepiej się nie napalać zbytnio na tworzenie super kodu, tylko tworzyć na tyle, żeby był ok. I później w następnym projekcie *ewentualnie* rozważyć użycie starego kodu.
Chyba że pracuje się dla firmy, która robi wiele specyficznych wdrożeń opartych na jednym rozwiązaniu. Stąd właśnie nasz modularny kombajn do CMS, który do zbudowania serwisu docelowo wymagać będzie tylko szablonów HTML.
mmazur: dokładnie! Właśnie dlatego nie chcę być komercyjnym programistą, bo taki musi czasem odwalić fuszerkę (czyt. nie robić tego najlepiej jakby umiał, a tylko tak jak oczekuje klient). Programując hobbistycznie mogę projekt dopieszczać latami. ;-) Ale też zaczynam iść na skruty, bo jak typowy klient, nie mam cierpliwości czekać na idealne rozwiązanie. ;-)
"skruty" argh! :D
uuups… s/skruty/skróty/
Jajcuś, nasze kody też przeważnie nie są idealne, bo jak coś zaczynamy pisać to dlatego, że jest nam potrzebne, a nie dlatego, że nagle zapałaliśmy nieodpartą chęcią stworzenia idealnego rozwiązania dla jakiegoś problemu :)
To jest raczej kwestia tego, na jakim poziomie nasz kod jest paskudny. Choćbym nie wiem jak szybkiego hacka pisał, to raczej nie wpadłbym na pomysł włożenia w kod odwołania do mysql_connect (z ręcznym podaniem usera i hasła) w pięciu miejscach. Albo ręcznego hardocowania jakiejś ścieżki w dziesięciu. A właśnie na taki kod patrzę.
Zdanie o "tych, co będą później ten kod utrzymywać" brzmi co najmniej znajomo…
http://www.hacknot.info/hacknot/action/showEntry?eid=52
Nie twierdzę, że tworzę ideały. Tylko, że mogę sobie pozwolić na dopieszczanie (łącznie z przepisaniem od zera) fragmentów, których dopieszczanie musiałbym sobie odpuścić robiąc to komercyjnie (bo brzydki kod spełniający wymagania klienta mogę zrobić w terminie, a kodu spełniającego moje ambicje nie dam rady).
Chodzi mi oczywiście jedynie o ideę (broń Boże nie zarzucam plagiaryzmu czy czegoś w ten deseń).
Jestem właśnie jednym z tych wielu "next guys", którzy dziedziczą kod po swoich poprzednikach, najczęściej po koleżkach, co to popracowali w firmie rok-półtora i sobie poszli. A ich "dzieła" zostały dla mnie. A także kod po jakichś amatorach z różnych działów, co to "się pochwalili szefowi, że umią w Delphi" i teraz się okazało, że jednak za mało "umią" i zawodowy programista jednak musi to poprawić. Jedno wszyscy oni mają wspólne — żaden nie myślał o swoim następcy, stąd czytanie takiego kodu to ciągłe drapanie się po łysinie z myślą "WTF?!", albo po naszemu "CTKJ?!". I jak podliczyłem, to głównie za to firma mi ostatnio płaci, za grzebanie się w gównie po jakichś amatorach. Frustrujące.
Dobrze, Patrys, że o tym piszesz. Takiego przypominania nigdy za wiele.
zgoda: dziwi mnie Twoje podejście. Jako zwolennik twardych regół wolnego rynku powienieneś sytuację dobrze rozumieć. Ci amatorzy zrobili to za co im ktoś zapłacił. Teraz zarabia ten kto to poprawia. Jeśli klient chciał zapłacić za chłam, to zapłacił, a dla amatora, który to zrobił to uczciwie zarobione pieniądze. Przekonaj potencjalnego klienta, żeby od razu zamawiał kod u profesjonalisty (u Ciebie). Nie da się? Znaczy się nie ma popytu na takie usługi, a Ty nie jesteś konkurencją dla taniego studenta, czy syna szefa, albo nie umiesz się sprzedać. Możliwe, że nawet dokładasz się do tego stanu rzeczy, pokazując, że wszystko da się naprawić. Przykre, ale prawdziwe.
Aby nie zniżać się do poziomu "syna szefa" ja staram się robić swoją robotę tak, żeby klient nigdy nie żałował, że akurat mnie to zlecił — dzięki temu nawet gdy kiedyś do podobnej roboty zatrudni amatora, to przy kolejnej znowu mam szansę. Poprawiania po innych raczej nie lubię, tak samo jak robienia czegoś, co kto inny ma dalej ciągnąć (tego drugiego jednak trudno uniknąć). Jednak wyleczyłem się już z robienia wszystkiego „idealnie” — ambicje ambicjami, ale nie wszędzie jest dla nich miejsce.
To ja jeszcze a'propos silnika szablonów:
już widzę jak rzesze początkujących PHP-owców rzucają się uczyć Smarty! ROTFL! Przecież nie będę używał silnika szablonów do małych rzeczy, to raz. Poza tym wciąż spotykam się z ludźmi, którzy piszą mimo wszystko własne wersje z czterech conajmniej powodów: 1. nauka, bo nie ma to jak samemu coś napisać, 2. security by obscurity, 3. szycie na miarę i 4. kwestie licencyjne.
Jest jeszcze kwestia tego, ze kiedy poczatkujacy PHP-owiec zabiera się za smarty to wyrasta Smarciarz. Co jeśli mu się te smarty zabierze?
Dobre rozwiązania - tak. Rozwiązania w celu przyspieszenia pracy - owszem. Za wszelka cenę - błąd. Nuda, a człowiek się czuje jak warzywo.
Panowie rozumiem uczenie się smartów tak jak rozumiem naukę ogl'a czy directx'a, ale nie róbcie z programisty rzemieślnika ;)
>Jest jeszcze kwestia tego, ze kiedy poczatkujacy PHP-owiec zabiera się za smarty to wyrasta Smarciarz. Co jeśli mu się te smarty zabierze?
Pisze obleśny kod z przemieszaniem warstwy prezentacyjnej z logiczną. Żadna to sztuka. Ewentualnie w tęsknocie za Smartym może ów kod podzielić na funkcje od logiki i funkcje od prezentacji, ale wtedy na pewno napieprzy się bardziej niż smartując.
Z programistów rzemieślników zrobił już Dijkstra, chociażby tekstem "GOTO statement considered harmful". ;P