Podobieństwo metod kodowania

Panowie, zapytanie teoretyczne, ale z początku kariery i przez pewien czas każdy prawie zadaje sobie jedno pytanie.
Wyobraźmy sobie, że mamy mechanizm złożony z kół zębatych, przekładni. Nie mam w nim za bardzo zbędnej elektroniki. Naszym celem jest nauczyć się jak on wlaścicie działa, a bierzmy pod uwagę, że niezbyt wiele o nim wiemy.

Jaką taktykę byście wybrali:

A ) Demontujecie jeden element oglądacie i staracie się metodą prób i błędów przypasować to do innych podobnych części czy.

B ) Rozkładacie mechanizm i skłądacie go na nowa starajć się w nim coś modyfikować aczkolwiek zachować mimo wszystko zasadę działania.

Tutaj albo coś nowego odkryjecie, albo coś zepsujecie co jest normą. Można powiedzieć, że jedna z tych metod jest bardziej efektywan od II.
W prowagramowaniu nazywamy to wzorcami projektowymi, które jak wiadomo są sprawdzone.
Dla mnie osobiście zawsze przykłady będę najlepszym nauczycielem. Porównanie do mechaniki klasycznej myslę adekwatne :-p

Karmie z jednej strony i patrze co wylatuje. Tu poruszam, tam pokręcę i patrze czy to co wyleciało przypomina to co powinno być

Biorąc pod uwagę, że takim mechanizmem może być np. tradycyjny zegar sprężynowy to na początek zanim to rozbiorę jednak czytam odrobinę jakieś teorii i podstaw mechaniki.
Możesz być niemal pewien, że jak rozłożysz zegar bez żadnego doświadczenia to najprawdopodobniej go nie złożysz. Nie mówię, że trzeba się od razu doktoryzować ale zanim się paluchy do kontaktu włoży dobrze przeczytać najpierw "jak wkładać palce do kontaktu".

Mając te minimum teorii i jakieś poczucie, że zdołam tego nie zepsuć zabieram się za grzebanie w środku.

W programowaniu, jeśli kod całości nie jest zbudowany "antypatternowo", to łatwa i efektywna będzie metoda A, bo wiemy jak są połączone moduły.

C ) Zaglądacie do dokumentacji ze świadomością, że jest do powód do wstydu i ostateczne przyznanie się do porażki.

delform_17 napisał(a):

Wyobraźmy sobie, że mamy mechanizm złożony z kół zębatych, przekładni. Nie mam w nim za bardzo zbędnej elektroniki. Naszym celem jest nauczyć się jak on wlaścicie działa, a bierzmy pod uwagę, że niezbyt wiele o nim wiemy.

Negocjuje +100% za pracę w legacy.

Jaką taktykę byście wybrali:

Rewrite from scratch.

ccwrc napisał(a):

C ) Zaglądacie do dokumentacji ze świadomością, że ...

trafie na kolejna "kupe" pisana "na kolanie" przez "geniusza", ktory wychodzi z zalozenia, ze docsy sa najmniej istotna rzecza, a prawdziwemu programiscie wystarczy po prostu czytanie kodu. Kodu, ktory czesto wiecej ma wspolnego z bigosem niz z dobrymi praktykami.

W dzisiejszym świecie odpowiedź może być tylko jedna:

D) Zamiast tracić czas na naprawianie padła z wbudowanym terminem przydatności do użycia to lepiej pójść do sklepu i zamówić nowy egzemplarz.

delform_17 napisał(a):

W prowagramowaniu nazywamy to wzorcami projektowymi, które jak wiadomo są sprawdzone.

jak wiadomo otrzymaliśmy je na górze Synaj ;)

Dla mnie osobiście zawsze przykłady będę najlepszym nauczycielem. Porównanie do mechaniki klasycznej myslę adekwatne :-p

po co mieć wzór na siłę grawitacji, jak przecież o wiele lepiej mieć stablicowane y dla różnych wartości x ;)

Miang napisał(a):

jak wiadomo otrzymaliśmy je na górze Synaj ;)

Nie, te akurat zostały rozbite bo ci którzy dla których były przeznaczone byli zajęci sprawianiem sobie złotego cielca.

po co mieć wzór na siłę grawitacji, jak przecież o wiele lepiej mieć stablicowane y dla różnych wartości x ;)

Wzór na siłę grawitacji g**no ci da jak nie opanujesz rachunku różniczkowego. Stablicowane wartości dają przynajmniej szansę na jego odkrycie i wyprowadzenie wzoru na siłę grawitacji.