Oczywiście, że można :).
Musisz spojrzeć na programowanie , z punktu dziecka. Założmy, że instrukcje i funkcję są pierwotnymi zachowaniami, czyli możliwości dane przez stwórce danego języka. Dziecko potrafi je wykorzystać, ale nie wie jak wydajnie je wykorzystywać. Ty jako jego stwórca musisz go poprowadzić za rączkę unikając pułapki i doprowadzić go do ostatecznego rozwiązania. Wykorzystując pierwotne jego możliwości. By doprowadzić, musisz przeanalizować jakie problemy staną Ci na drodze. Bo czym jest programowanie? Znalezieniu problemu A, napisaniu rozwiązania B, który ostatecznie oddaje rezultat C. Przykład:
Mój kolega zajmujący obsługą jakiegoś programu do odczytu czujników GPS z samochód, chce napisać opgramowanie, które ułatwi mu pracę(przy okazji pozwoli awansować ^^) , które policzy zużycie paliwa samochodu na danym dystansie.
Problem główny: Jak sprawdzić ile samochód zużył paliwa.
By dojść ile zużył paliwa , musimy wiedzieć jaką prędkość pojazd uzyskał na danym odcinku. Skąd to będziemy wiedzieć? Mamy wzór na prędkość V=s/t czas do przybytego dystansu.
Ale skąd mamy wiedzieć jaki wyniósł dystans? Sczytujemy kordynaty sygnału GPS, co określoną jednostkę czasu (powiedzmy minute). Narzucamy na mapę, zliczamy dystans, licząc odległośc od punktu A do punktu B razy odpowiednia skala mapy.
Znamy odległość, znamy czas. Jesteśmy w stanie policzyć prędkość. Potem, możemy pobrać średnie zużycie paliwa , obliczone z bazy danych. I tym sposobem ustaliśmy zużycie paliwa.
Jednakże, czytelnik zauważy (ulubiony zwrot mojego ćwiczeniowca z fizyki), co jeśli prędkośc jest niejenostajna? Raz pojazd jedzie 120 km/h, a potem 20 km/h., średnia 60km/h (na oko)i z tylu liczymy A potem dzwoni zdenerwowany klient, że wasze opgramowanie jest do d*py. Ma duże straty w paliwie.
Nasz przełożony, podziękuje mu kulturalnie, powie "dziękuje za informacje, za chwilę pójdę zobaczyć do działu IT, a tu mam coś ekstra od firmy". No i obydwoje są szczęśliwi. Klient bo dostał coś znowu od firmy, a szef że pozbył się natręta. Odkłada słuchawkę, siada przy swoim komputerku no i patrzy na raporty. Patrzy...patrzy no i NIE DOWIERZA, nagle wszyscy jedża regulaminowo albo maluchami. No to idzie do was albo waszego (TL), mówi, że macie udoskanalić opgramowanie bo klienci, dzwonią że z skargami. No to ty przyjmujesz poważną minę i mówisz, że coś wymyślisz.
To jest pułapka, którą w ty wpadłeś. Teraz musisz skręcić w bok. Robisz meeting.
Początkujący programista, powie zróbmy o wiele częstiejszy pomiar np : co 30 sek.
Inny powie, że może wprowadzić średnią ważoną. Owszem nie jest to idealne rozwiązanie, ale ograniczony błędem statystycznym.
Outsider, powie, że to wszystko jest do niczego, najlepiej napisać od nowa (zawsze się, znajdzie jakiś choleryk)
Analizujesz:
Outsidera, nawet nie bierzesz pod uwagę. Bo to wieczny maruda.
Analizujesz pierwsze rozwiązanie. Robicie jakieś testy. Do niczego, laguje jak jasna cholera. Komp się grzeje by jajka można by na nim smażyć. Trzeba by kupić mocniejszy serwer, ale masz już budżet przekroczony.
Próbujesz coś innego:
Sprawdzasz drugie rozwiązanie. Jest lepiej , błąd statyczny zmalał do 10%,to wciąż dużo, ale nie tyle samo co wcześniej.
Tym sposobem omijasz pułapkę i dochodzisz do lepszego rozwiązania.
Ale po tym spotkał kolejną pułapkę, jaką? Pomyśl jakie czyniki, mogą wpływać na rzeczywistośc wyniku :)
Programowanie nie jest łatwą rzeczą, tym bardziej gdy robimy coś bardziej zawansowanego niż kalkulator. Tylko nauka na swoich błędach i błędnych rozwiązaniach, pozwolą nam spokojnie dopływać do przystajni odbioru rozwiązania. Pytanie czy chcesz przebyć ten dystans?
