wyważanie otwartych drzwi, czyli pisanie czegoś, co już jest napi

wyważanie otwartych drzwi, czyli pisanie czegoś, co już jest napisane

czy uważacie, że warto pisać klasy, funkcje itd. które już zostały przez kogoś napisane i przetestowane?

a jeżeli tak, to z jakiego powodu:

  • sprawdzić siebie?
  • postarać się zrobić lepiej?
  • duch rywalizacji?
  • inny ;-)

7 miesięcy, 2 tygodnie temu | edytowane przez: michu 3526115

  • Odpowiedź pragmatyczna: Tylko jeżeli uważasz, że możesz zrobić lepiej (co na ogół przekłada się po prostu na "w sposób lepiej dopasowany do moich potrzeb").

    Odpowiedź edukacyjna: Żeby się nauczyć jak coś takiego zrobić.

    Odpowiedź romantyczna: Tak, bo programowanie jest cudowne i uwielbiam tworzyć coś z niczego, a w dodatku mam na to czas.

    Osobiście uważam, że tworząc projekt w pracy, komercyjnie, im mniej kodu się napisze by osiągnąć dany cel, tym lepiej. Natomiast "po godzinach", wszystko co zrobisz to Twój rozwój. Gdyby nie było warto, to do dzisiaj mielibyśmy jeden framework MVC, jeden mapper ORM, jednego CRM-a, jeden system operacyjny, jedną (pewnie systemową) bibliotekę do pracy z datą i czasem...

    No i oczywiście trudno oczekiwać żeby ktoś zabrał się za pisanie na nowo czegoś, co już istnieje, aby osiągnąć dokładnie ten sam efekt - na ogół to wynika z silnych opinii na temat jakiegoś rozwiązania i co można zrobić, by było lepsze. Zatem, odpowiadając wprost na Twoje pytanie - głównie po to żeby zrobić coś lepiej i sprawdzić siebie. Rywalizacji jeszcze nie widziałem w tym kontekście.

  • Myślę, że umiejętność stosowania gotowych rozwiązań (na przykład wzorców projektowych) jest jedną z bardziej przydatnych umiejętności programisty. Korzystając z cudzego (ale dobrego!) kodu można zaoszczędzić czas i spożytkować go na aspektach związanych już bezpośrednio z naszą aplikacją. Przydaje się też wyczucie i dobra ocena własnych możliwości (umiejętności i zasobów) - są rzeczy, których nikt z nas nie zrobi lepiej niż jest zrobione (a przynajmniej nie w rozsądnym czasie).

    A kiedy pisać od nowa?

    • gdy istniejący kod jest słaby i brzydki,
    • gdy istniejące rozwiązanie jest dobre w ogólności, ale nasze wymagania są bardzo specyficzne (jeśli mamy do czynienia z opensource to w tym przypadku można pohackować),
    • gdy filozofia lub środowisko istniejącego rozwiązania różni się znacząco od środowiska naszej aplikacji (na przykład widget dla jQuery, podczas gdy my korzystamy z Prototype), co wprowadziłoby niepotrzebną heterogeniczność.

    Myślę natomiast, że należy się wystrzegać działania pod wpływem NIH (Not Invented Here).

    Wyjątkiem jest sytuacja, w której naszym celem jest samo programowanie, a nie utworzenie gotowego produktu (na przykład dla poszerzenia wiedzy i umiejętności) - takie wprawki mogą być wówczas rzeczywiście pouczające. Zwłaszcza przy końcowym porównaniu jak nasze rozwiązanie wypada na tle innych.

  • Motywacje, żeby pisać coś na nowo mogą być różne... Najczęściej piszę coś od nowa, bo lepiej będzie dostosowane do środowiska jakie stworzyłem.

    Niestety, bardzo często jednak nie mam wyboru. Ponieważ pracuję nad komercyjnym projektem, muszę zwracać uwagę na licencje. Paradoksalnie, najniebezpieczniejszą licencją jest... GPL*. Dlatego unikam jej jak ognia (o wiele bardziej przyjazną jest MIT). Najsmutniejsze jest to, że wielu programistów udostępnia swoje biblioteki na licencji GPL w dobrej wierze, nie zdając sobie zupełnie sprawy z tego, że blokują ich użycie w produktach komercyjnych.

    *) Patrz: licencje wirusowe.

  • Kiedyś prowadzący ćwiczenia zaproponował napisanie czegoś jak NK. NK już istnieje, więc nie da się osiągnąć lepszego efektu, chyba że by nie była rozwijana. Jednak takie zadanie ułatwia określenie co jest przedmiotem projektu. Nie chodzi oczywiście o napisanie słowo w słowo NK ale serwisu społecznościowego, a konkretny przykład pozwala uniknąć uogólnień i godzin konsultacji co tak na prawdę jest do zrealizowania, kiedy można od razu zacząć ćwiczenia wiedząc do czego się zmierza i jaki mniej więcej efekt końcowy osiągnąć.

    Programista to fach, w którym chętniej bierze się kilof do ręki i kuje tą skałę, zamiast zobaczyć czy ktoś już nie wykuł. Jednak ponieważ kucie w skale jest interesujące czasem tak robimy. Ponadto może się wydawać, że jakiejś biblioteki, modułu albo aplikacji nie ma. No cóź... zazwyczaj jednak jest i to zależy od naszych umiejętności szukania i researchu czy ją znajdziemy.

    Kiedyś znajomy powiedział mi, w odpowiedzi na pytanie czemu w Linuxie jest tyle programów gdzie każdy realizuje tylko jedną rzecz, odparł , że taka jest filozofia tego systemu, żeby napisać pojedyncze aplikacje, które realizują idealnie jedną konkretną funkcję. Od tamtej pory uważam, że tak właśnie powinno być nawet na większą skalę i w dowolnym projekcie: rozwijasz jeden produkt i starasz się go udoskonalić. A jeżeli potrzebujesz jakiegoś pomocnego narzędzia: korzystasz z softu od firmy, która takie narzędzie dostarcza.

    Czemu więc polegać na oprogramowaniu od innych dostawców? Jeżeli firma zajmuje się też jednym produktem od lat to jej oprogramowanie jest dopracowane, nie ma zazwyczaj błędów a jeżeli takie się pojawią będziesz miał pewność, że zostaną naprawione. A samemu pisząc coś co jest gotowe można się przeliczyć, bo:

    • nie będzie tak dobre jak gotowe rozwiązanie
    • koszty mogą przewyższyć koszt zakupu

    Pamiętajmy przecież, że pisząc coś co jest już gotowe, marnujemy czas który byśmy mogli poświęcić na napisanie programu, którym moglibyśmy rozwiązać czyjś rzeczywisty problem!

    Także pisanie czegoś co zostało już napisane to marnowanie czasu. Jeżeli popatrzyć na eksperyment Stanfordzki czy to, że innowacyjne produkty powstały na studiach, postulat o tym, że na uczelniach powinno się pisać coś co zostało już napisane, też jest mylny. Facebook, DOS i inne ważne rozwiązania miały swój początek na studiach. Gdyby Mark albo Bill w czasie studiów musieli pisać kolejną wersję assemblera to nie mielibyśmy takiego rozwoju IT dzisiaj.

    Oczywiście nie każdy jest Markiem czy Billem, ale jednak każdy ma potencjał, umiejętności i wiedzę i powinien starać się z niej korzystać, aby pomagać innym. Pisanie klonów nie pomaga nikomu.

  • Też coś sobie skrobnę, a jak! :-)

    Nie bez powodu będzie bardzo zbliżone do zdania Michu i Newtona, fakt który został uwzględniony, że zwyczajnie czas goni, a rozwiązanie jest dobre jest wystarczającym powodem żeby go użyć - ew. jeżeli potrzebujemy trochę inny interfejs, to sobie taki przygotujemy (Adapter). Z kolei tworzenie nowych technologii jak tomaszs zaznaczył ma więcej plusów niż się koledze wydaje, gdyby nie pasjonaci, nie było by teraz: Pythona, Ruby i innych tego typu skryptów, o zgrozo, nie było by nawet Linuxa i windowsa, jechalibyśmy teraz na dosie! Tak więc, nowe rozwiązania poza pożytkiem dla mózgu, jak zaznaczył Michu i nie ukrywajmy, ma rację, mamy miliony tetrisów i kalkulatorów które naskrobał młody adept sztuki, dokładnie po to aby lepiej ją zrozumieć - w przypadku gier np. to jest taka mała sugestia tetris->platformówka i bodajże jeszcze coś, może jakiś pong, aby zapoznać się jak działa szkielet takiej gry, to samo się tyczy każdej innej aplikacji albo biblioteki - napiszemy coś sami, to lepiej to zrozumiemy. Chociaż, nie wyobrażam sobie żebym miał napisać Silnik 3D - coś jak Ogre, raczej wolę go wykorzystać (Btw. mamy jeszcez wiele innych, tak więc, rozwiązania idealne nie istnieją).

  • Wszystko zależy od konkretnego przypadku, ale moim zdaniem jeśli coś jest i nam odpowiada w takiej wersji w jakiej jest to po co to pisać drugi raz?

  • W pracy mam kolegę, który pisze wszystko od nowa i nie chce używać frameworków ani innych tego typu rozwiązań. Przez to zyskał przydomek "Socjalizm", ponieważ socjalizm to ustrój, który bohatersko pokonuje problemy nieznane innym ustrojom. A mój kolega, analogicznie, jest programistą, który bohatersko pokonuje problemu nieznane innym programistom. Bo nie stosuje żadnych frameworków. :)

    Oczywiście warto inwestować swój czas w znane i sprawdzone cudze rozwiązania, bo w przyszłości to będzie procentować. Wyjątkiem jest sytuacja, gdy potrzebujemy czegoś krojonego na naszą miarę ze względu na specyfikę naszej aplikacji.

  • Cel edukacyjny. Modyfikacja/optymalizacja (pod dowolnym względem) kodu.

Zaloguj się, aby dodać swoją odpowiedź