Wpis z mikrobloga

@sluchawki_iphone_wawa: Bo patrząc jak są zaimplementowane biblioteki, jak wyglądają programy z gita to jakoś nie widziałem, żeby ktoś #!$%@? szablony ze zmienną ilością parametrów albo korzystał z curiously recurring template pattern. Więc jestem ciekawy czy tego się używa normalnie czy to tylko sztuka dla sztuki
  • Odpowiedz
Zależy od projektu, rozmiaru itd. Przeważnie wszystko na własnych typach i im większy tym mniej czytelny. Im więcej osób pisze tym styl i preferencje się coraz bardziej różnią. CRTP sobie nie przypominam. Może nie sztuka dla sztuki, jeśli coś jest zrobione dobrze i działa to zostaje, nikt przecież nie będzie odkrywał Ameryki na nowo bo czasu jest zawsze za mało.
  • Odpowiedz
@sluchawki_iphone_wawa: Rozumiem. Bo im bardziej się zagłębiam w C++ tym krzywa trudności nauki rośnie coraz szybciej. Zresztą cytując Bjarne Stroustrupa "C++ has indeed become too "expert friendly""... I ilość kontrukcji językowych zrozumiałych tylko przez ekspertów jest bardzo duża.
  • Odpowiedz
@MrOsamaful: Ogólnie, niezależenie od języka powinno się używać prostych konstrukcji. No chyba, że faktycznie te wymyślne rzeczy pozwalają:
- uniknąć tworzenia zależności
- redukują duplikacje kodu
- polepszają wydajność jeżeli jest ona ważna
- polepszają czytelność (czyli da się zdefiniować krócej i zwięźlej jakieś znane i powtarzalne konstrukcje)
Jeżeli powyższe warunki da się osiągnąć przy pomocy prostszych konstrukcji to unikałbym stosowania takich 'fency' rzeczy tylko dlatego, że można
  • Odpowiedz
@LeopoldStuff: Dodałbym jeszcze - jeśli wymyślne rzeczy umożliwiają pełniejsze pokrycie kodu testami.

Była kiedyś afera w firmie, bo kolega napisał kod, który rozumiał niemal tylko on. Klient nie odebrał pracy, bo powiedział, że ich programiści nie czają co tam się dzieje, że trzeba kod zrefaktorować. Skubany wykazał, że jego kod jest w 98% pokryty unit testami właśnie dzięki temu, że stosował tak zawiłe konstrukcje.Po ciężkich dyskusjach klient odebrał pracę.
  • Odpowiedz
@saracenxc: A mógł napisać prosto i czytelnie, mniej by się narobił, klient i tak by odebrał kod a z dalszą zabawę przejęliby jego programiści ( ͡° ͜ʖ ͡°) Skoro nie widać różnicy, to po co przepłacać?
  • Odpowiedz
@Khaine: Po to, żeby uniknąć nieoczekiwanych zachowań gotowego produktu, bo okazało się, że jakaś ścieżka była nieprzetestowana, spowodowała problemy, których wykrycie kosztowało 200 roboczogodzin testerów, a których naprawa kosztowała kolejnych 200 roboczogodzin programisty, bo jakiś leń i niedouk nie chciał poświęcić 100 roboczogodzin na napisanie testowalnego kodu. Co spowodowało np. wycofanie z produkcji partii samochodów znanej marki klasy premium i akcję serwisową dla posiadaczy tego modelu w celu aktualizacji oprogramowania
  • Odpowiedz
@saracenxc: To już zależy jak bardzo skomplikowane są rzeczy, które ten kod robi. Bo ja mam teraz w pracy sytuacje, gdzie jakiś "wirtuoz" musiał proste rzeczy komplikować żeby się pewnie nie zniżać do "leni i niedouków" a teraz nie da się czytać tego co zrobił, bo komentarzy ani dokumentacji też nie ma. W końcu "widać od razu o co chodzi".

Prostota zawsze powinna być maksymalna możliwa przy spełnieniu pozostałych parametrów.
  • Odpowiedz