keyboardMiliony linii kodu to cza­sem cha­os. Komputer jest z defi­ni­cji deterministyczny.

Właśnie skoń­czy­łem czy­tać kolej­ny tego­rocz­ny gru­dnio­wy numer Software Developer Journal. Ogromne prze­my­śle­nia wzbu­dził we mnie arty­kuł Fazy Tworzenia Oprogramowania Pana Daniela Jabłońskiego. Autor, doświad­czo­ny pro­gra­mi­sta, pisze o zarzą­dza­niu pro­jek­ta­mi, w któ­rych zło­żo­ność sta­je się wręcz abs­trak­cyj­na dla samych pro­gra­mi­stów: milio­ny linii kodu!

To wła­śnie mnie fascy­nu­je: ogar­nia­nie zło­żo­no­ści za pomo­cą abs­trak­cyj­nych mode­li pro­ble­mu. Wyrzucam wszyst­ko to co zaciem­nia obraz i zosta­wiam tyl­ko ele­men­ty jed­nej per­spek­ty­wy. Z milio­nów linii kodu moż­na zro­bić kil­ka­dzie­siąt diagramów.…

System ERP zawie­ra kil­ka tysię­cy funk­cjo­nal­no­ści, każ­dą imple­men­tu­je kil­ka, kil­ka­na­ście czy nawet kil­ka­dzie­siąt tysię­cy linii kodu. Jak to ogarnąć?

Jeden z pra­cow­ni­ków moich klien­tów, duży deve­lo­per powie­dział, że fir­ma i to co się w niej dzie­je jest tak skom­pli­ko­wa­na, że nie wyobra­ża sobie bo moż­na to było opi­sać lub nary­so­wać. Powiedziałem, że moż­na, nale­ży jed­nak po pierw­sze przy­jąć pewien poziom szcze­gó­ło­wo­ści opi­su sen­sow­ny z per­spek­ty­wy czło­wie­ka (model to uprosz­cze­nie) oraz podzie­lić pro­blem na kawał­ki… dys­ku­sja nie mia­ła koń­ca. Mój pro­jekt dobiegł koń­ca i oka­za­ło się, że uda­ło się opi­sać nie małą fir­mę w cią­gu mie­sią­ca, mode­lem na kil­ku­dzie­się­ciu stro­nach. Jak?

Modelowanie to fascy­nu­ją­ca pro­fe­sja. Pozwala upro­ścić samo­chód Porche, skła­da­ją­cy się z kil­ku­set tysię­cy ele­men­tów do posta­ci mode­lu, zabaw­ki na reso­rach, zacho­wu­ją­cej potrzeb­ne, w kon­tek­ście wyści­gów na pla­sty­ko­wym torze, cechy takie jak wygląd i roz­po­zna­wal­ność mar­ki samo­cho­du. Modelowanie pozwa­la upro­ścić ten sam zło­żo­ny samo­chód do posta­ci drew­nia­nej sko­ru­py pozwa­la­ją­cej na oce­nę aero­dy­na­mi­ki samo­cho­du. Innym razem sil­nik umiesz­cza się, w skrzyn­ce imi­tu­ją­cej nad­wo­zie z koła­mi by go prze­te­sto­wać i oce­nić jakie samo­chód będzie miał przyśpieszenie.

Opanowywanie zło­żo­no­ści to pod­sta­wo­we zaję­cie ana­li­ty­ka, projektanta.

Autor arty­ku­łu pyta: czy kie­dyś przy­pad­ko­wy błąd, defekt, pro­gra­mu zawie­ra­ją­ce­go milio­ny linii kodu nie spo­wo­du­je, że powsta­nie świa­do­my program?

No coż … filo­zo­ficz­ne dywa­ga­cje :)… cza­sem i to nale­ży robić.… W każ­dym razie, z filo­zo­ficz­ne­go powo­du pole­cam ten numer SDJ

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.