Wpis z mikrobloga

@AnonimoweLwiatko: z miesiąc temu rzuciłem pracę w firmie, która za parę lat pewnie będzie korpo, więc to może efekt tej zmiany( ͡° ͜ʖ ͡°) To nie są przede wszystkim rady, tylko jakieś luźne myśli, które przeczytam i stwierdzam, że może warto się nimi podzielić i podyskutować.
  • Odpowiedz
@zibizz1: zwłaszcza jeśli to jest kod którego szanse na zmianę w przyszłości wynoszą 0%. Lepiej skupić się na często używanych częściach projektu, zresztą większość artykułów o refactoringu właśnie to promuje - poprawiaj kod który zmieniasz. Trzeba realistycznego podejścia cost vs benefit.
  • Odpowiedz
@AnonimoweLwiatko: ja pracuje w korpo i ani mysle zoatawiac zly kod. A sam technical lead zacheca do dbalosci o niego, bo wie ze koszty utrzymania sa wieksze. Ja mysle ze Ty to o software house mowisz i np Comarchu który więcej ma wspolnego z software housem chybq.

@cxnmlhuipwetr: no jak uzywasz to tez. Chociaz wyjątkiem sa tutaj wspolne biblioteki. Ale to głównie dlatego ze nie chcesz potem ilustam
  • Odpowiedz
  • 1
@cxnmlhuipwetr trzeba się jednak zastanowić skąd ten gówniny kod się tam wziął. Brak dbałości w codziennej pracy to jeden z głównych powodów. Wydaje mi się czasami, że to jest wina głównie programistów, bardziej niż menadżerów, którym nie chce się poprawiać słabego kodu, który właśnie stworzyli "bo działa to nie ruszam" i commit
  • Odpowiedz
te rady odnoszą się do typowych projektów domowych, a nie takich z którymi masz styczność w korpo ( ͡° ͜ʖ ͡°)


@AnonimoweLwiatko: no przecież książka nazywa się "czysty kod", to chyba już tytuł wyklucza korpo ;)

W korpo ma realizować cele biznesowe asap
  • Odpowiedz
@nilphilus: wydaje mi się, że dopóki chłopaki nie trafią do firmy w której istnieją jakieś standardy, to Twoje wysiłki przekonania ich do "czystego kodu" mijają się z celem. Wiele osób ma zakorzenione przekonanie, że piszą słaby kod, bo w korpo nie ma czasu na pisanie dobrego kodu, ale często jest to jedynie efekt braku umiejętności (nie mówię oczywiście, że brakuje Wam umiejętności chłopaki!)
  • Odpowiedz
@dzek: zależy też od typu korporacji, często jest tak, że jeżeli firma przez długi czas zajmuje się jednym produktem to nawet PM zauważa, że przyłożenie większej wagi do jakości pozytywnie wpływa na wyniki.
  • Odpowiedz
Ja tam nie polecam branie sobie tej zasady za bardzo do serca bo pozniej niektorym sie wydaje, ze jest komentarz = slaby kod, wiec nie pisza komentarzy w ogole ;)
  • Odpowiedz
@toshie: a ja myślalem że chodzi raczej o wytykanie ;-) dobry komentarz w dobrym miejscu to złoto, niepotrzebny to zlo. Ale wiele osób wali komentarz który równie dobrze można by porównać do 'inicjalizacja inta' i na co to?
  • Odpowiedz
@nilphilus: A to jasne. Komentarze oczywistego kodu śmierdzą.
Ogólnie rzecz biorąc też się zgadzam z tym, że jeśli musisz komentować np kolejne kroki Twojego kodu to prawodpodobnie możesz ten kod ulepszyć. I dobry komentarz zazwyczaj rozjaśnia nie co się w danym miejscu dzieje (o tym powinien mówić kod), a dlaczego, jeśli to nie jest oczywiste. Chodzi mi przykładowo o sytuacje gdy coś czego używasz ma skopany (niejasny/niejednoznaczny) interfejs lub jakaś
  • Odpowiedz
@zibizz1: jeśli się boisz, to już jesteś niewolnikiem ( ͡° ͜ʖ ͡°)
Po grubych refactorach wychodzą błędy, to normalne. Jednak to jest kod na świeżo, czytelny i wyrównany, więc naprawia się go błyskawicznie.
  • Odpowiedz