Analiza vs Programowanie

0

Ostatnio spotkałem się ze stwierdzeniem, że analiza czyjegoś kodu jest trudniejsza niż pisanie kodu. Ja miałem zawsze odwrotnie, analiza i wyszkukiwanie błędów było dla mnie prostsze. A jak to jest u Was?

0

Zależy jaki język ;]

0

Wszystko jest zależne, ale z własnego doświadczenia wiem że analiza cudzego kodu to ciężka robota. Pisanie kodu który sam wymyslasz jest znacznie łatwiejsze - twój kod - twoja myśl.

0

Jeszcze bardziej niż od jezyka, zależy od wyglądu tego kodu.

0

Zakładając, że analizujemy kod kolegi z pracy, lub kogoś kto ma choć tyle przyzwoitości, że prosząc o pomoc pokazuje odpowiednio sformatowany kod to analiza czyjejś myśli jest znacznie trudniejsza od pisania czegoś po swojemu, niezależnie od tego jakim językiem sie posługujemy. Ta zasada dotyczy nie tylko programowania.

0

analiza - hardkor.
pisanie jak rozumiem problem ktory implementuje to banal.

0

Zdecydowanie czytanie czyjegoś kodu to jest droga przez mękę.
W sumie to zależy od autora kodu. Jeśli jest to dobrze napisane:

  1. dobrze ponazywane symbole
  2. dobrze sformatowane
  3. zrozumiałe krótkie i rzeczowe komentarze
  4. nierozwlekłe funkcje/procedury/metody
  5. dobra dokumentacja.

To wtedy może się zdarzyć, że czytanie kody jest łatwiejsze niż jego pisanie.
Zwykle oznacza to jeden z 3 przypadków:

  1. autor kodu jest lepszym koderem od czytającego ten kod
  2. autor i analizator kodu dobrze znają swoje style programowania
  3. problem jest prosty i pisanie kodu było by nudne.

edit: wniosek jest prosty dll najwyraźniej pracuje w dobrym zespole (przyznam, że zazdroszczę)

0

IMHO analizowanie cudzego kodu z pewnością jest bardziej żmudne ale nie prostsze od pisania własnego.

0

Pisanie kodu, to implementacja algorytmów, stosowanie wzorców etc. Jeśli ktoś tego nie zna, to będzie się głowił nad każdą bzdurą zadając sobie pytanie: za co to cholerstwo odpowiada.

Jeśli ma się rozeznanie w temacie, z którym związany jest aplikacja, to niekiedy analiza jest prostsza od napisania, bo przecież w niejednym przypadku trzeba wymyślić rozwiązanie, które rozwiąże problem.

Zresztą sam problem można zobaczyć tu na forum. Ileż jest próśb o gotowce. Sam algorytm często ludziom nie wystarcza...

0

Dla mnie trudniejsza jest analiza cudzego kodu. Czemu ? :)
Ponieważ należy "wejsc" w "myslenie" tamtego kodera i zaczac myslec tak jak on. A zalozmy ze ja mam zupelnie inna wizje i mozna wtedy sie pogubic. Niemniej analiza wymaga zdecydowanie wiecej uwagi bo samo kodzenie robisz "automatycznie". Kiedys slyszalem ze programista najpierw mysli mysli mysli a pozniej bach napisze kilka linijek kodu. A z analizowaniem niestety trudniej bo tu myslisz myslisz i skaczesz po kodzie ktorego nie pisales.
Oczywiscie jesli trafisz na kogos kto w podobny sposob kodzi jak Ty to lajcik :P

0

W sumie to zależy od autora kodu. Jeśli jest to dobrze napisane:

  1. dobrze ponazywane symbole
  2. dobrze sformatowane
  3. zrozumiałe krótkie i rzeczowe komentarze
  4. nierozwlekłe funkcje/procedury/metody
  5. dobra dokumentacja

Żadne z powyższych.

Dobry kod nie jest zależny od formatu kodu czy też nazw zmiennych, czy też długości funkcji/procedur. Dokumentacja / Komentarze jest/są również zbędny. Gdy kod jest pisany wg pewnych metodologii - sam tłumaczy się za siebie. To oznacza:

  • stosowanie wzorców projektowych
  • podział kodu na sensowne obiekty, enkapsulacja, dziedziczenie
  • stosowanie dobrych praktyk OOP (S.O.L.I.D)
  • podział na odpowiednie warstwy (MVC) i moduły
  • testy jednostkowe (Agile development)

To, czy ktoś nazwie zmienną "numberOfRows" czy "nor" nie ma najmniejszego znaczenie.

0

@Deti - co do nazw się nie zgodzę. Stosowanie złych nazw często zadanie utrudnia.

A co do tematu - to zależy od kodu i od tego, czy autora kodu mamy pod ręką.
Ja dzisiaj dostałem całkiem pokaźny kawałek kodu w C++, i to jakiejś egzotycznej mobilnej odmianie (nie pisałem w C++ od chyba 4 lat, a ten dialekt widzę na oczy po raz pierwszy w życiu). Dwóch gości bawi się od ponad miesiąca, żeby wreszcie zaczęła działać podstawowa funkcjonalność. Termin się zbliża i poprosili mnie, żebym im pomógł. Kod jest napisany dość sensownie i w ciągu 8h kilka błędów znalazłem. Natomiast nie napisałbym tego fragmentu kodu, który analizowałem od zera nawet jakbym dostał na to tydzień. Moim zdaniem znajdowanie błędów w cudzym kodzie jest łatwiejsze niż pisanie samemu kodu wysokiej jakości, o ile ma się autora tegoż kodu pod ręką, żeby go kilka razy zapytać "po co jest ta linijka", albo "jaki jest cykl życia tego obiektu" itp.

0

Jak dla mnie dobre nazwy zmiennych to element samodokumentojucęgo się kodu.

0

a ja glosuje za analiza, poniewaz TWORZAC program, musimy go NAPISAC i PRZEANALIZOWAC czy jest poprawny:)
zajmuje sie na co dzien i tym i tym, i to wlasnie na analizie trace godziny, po to, by potem miec pewnosc ze kilka linijek napisanych tak a nie inaczej zalatwi to co trzeba.

nie pisanie w kolko kilkunastu linijek czy trzech petli jest trudne/meczace, a wlasnie notoryczne powtarzanie analizy czy sa one poprawne

warto tez zwrocic uwage, ze analiza wydaje sie latwiejsza, poniewaz NIE bierzecie sie za analize czegos o czym mie macie pojecia! zas tworzac cos nowego - zwykle wlasnie tak jest i wtedy niejawnie analizujecie nieznane rzeczy.. postawcie sobie pytanie tak: analizowac kompletnie nieznana technologie vs. pisac w doskonale znanym frameworku ?

i druga rzecz - podczas analizy/kodowania mamy narzedzia. usuncie je z widoku i pomyslcie:

  • napisac program w notepadzie, bez google, bez IDE, bez podpowiadania skladni :) tylko kompilator, NIE wolno odpalac programu, tylko go pisac
  • analizowac program w notepadzie, bez google, bez debuggera, NIE wolno odpalac, tylko czytac

@Krolik - zgodzilbym sie z Toba, ale jak na razie ciagle trafiam gdzies, gdzie autorow juz nie ma albo maja skleroze, dokumnetacja to najlepiej zebym ja ja od nowa napisal bo analitycy systemu do mnie przychodza pytac sie jak on wlasciwie dziala, a ostatnio to wrecz pojawilo sie zlecenie zeby znalezc blad w ... kupionym gdzies od firmy z 3ciego swiata .exe'ku. naturalnie, zero dokumentacji, zero zrodel, zero kontaktu z autorem :) a skoro mowa o egzotycznej mobilnej odmianie - symbian pewnie? NewLC i zero wyjatkow?
btw. znalezienie paru bledow w 8h a napisanie masy kodu, to rozna ilosc produktow wytworzonych. zastanow sie, ile czasu zajmie Ci napisanie "wiele" kodu, a ile czasu zajmie znalezienie "wielu" bledow. wybacz, nie zarzucam Ci nic, ale jesli w 8h znalazles kilka bledow w C++ na platformie ktorej nie znasz, obawiam sie ze w tym kodzie sa w takim razie jeszcze dziesiatki jak nie setki nie odnalezionych. ile czasu zajmie znalezienie ich, vs. ile czasu trwaloby napisanie tego kodu NIE bawiac sie i piszac defensywnie?

0
  • napisac program w notepadzie, bez google, bez IDE, bez podpowiadania skladni :) tylko kompilator, NIE wolno odpalac programu, tylko go pisac
  • analizowac program w notepadzie, bez google, bez debuggera, NIE wolno odpalac, tylko czytac

IMHO nietrafione porównanie. Do analizy nie jest tak potrzebne IDE i kompilator jak do programowania.
Za to mogę wymyśleć takie porównanie:

  • zakoduj algorytm w assemblerze
  • zanalizuj algorytm napisany w assemblerze
    Porównanie też średnio trafione ale to tylko pokazuje jak łatwo można manipulować takimi analogiami.

1 użytkowników online, w tym zalogowanych: 0, gości: 1