Jakiś czas temu pisa­łem o archi­tek­tu­rze i dobrych prak­ty­kach, a nie raz wręcz o zasa­dach budo­wy archi­tek­tu­ry, jed­ną z klu­czo­wych jest „[[open clo­se pryn­cy­pia]]” (część zasad [[two­rze­nia opro­gra­mo­wa­nia obiek­to­we­go SOLID]]). Zasada ta mówi, że dobra archi­tek­tu­ra jest otwar­ta na roz­sze­rze­nia i zamknię­ta na zmia­ny. Można się z ta zasa­dą bar­dzo czę­sto spo­tkać w lite­ra­tu­rze doty­czą­cej archi­tek­tu­ry sys­te­mów, i nie cho­dzi tu o to, że o praw­dzie decy­du­je to, jak czę­sto ją powta­rza­my, a o to, że jest masa przy­kła­dów na to, że jest to moż­li­we (roz­sze­rze­nia bez wpro­wa­dza­nia zmian), że jest przy­dat­ne o czym świad­czą naj­niż­sze kosz­ty cyklu życia sys­te­mów o takiej wła­śnie architekturze.

Aż tu czy­tam sobie niu­sy” z inter­ne­tu i tra­fiam na artykuł:

Upgrade opro­gra­mo­wa­nia to pro­jekt co naj­mniej rów­nie skom­pli­ko­wa­ny co insta­la­cja bazo­wa. […] (Źródło: Cechy dobre­go mene­dże­ra ds. upgra­de­’u opro­gra­mo­wa­nia – Portal Wiedzy Menedżerskiej)

W tym momen­cie, oso­bom któ­re chcą choć pobież­nie poznać zasa­dy two­rze­nia dobrej archi­tek­tu­ry” pole­cam wpis o grze w sza­chy.

Jeżeli upgra­de opro­gra­mo­wa­nia ma być rewo­lu­cją co naj­mniej tak wiel­ką, lub nawet więk­szą, jak pier­wot­ne wdro­że­nie tego opro­gra­mo­wa­nia, to ja głę­bo­ko współ­czu­ję nabyw­com tego opro­gra­mo­wa­nia. Czytałem ten arty­kuł i z każ­dym kolej­nym aka­pi­tem moje zdu­mie­nie rosło: jak moż­na z pato­lo­gii robić dobre praktyki…

Upgrade, cóż to jest” Słownik języ­ka polskiego:

upgra­de [wym. apgrejd] ?uak­tu­al­nie­nie opro­gra­mo­wa­nia kom­pu­te­ra lub jego sys­te­mu operacyjnego?

w języ­ku angiel­skim sło­wo upgra­de ozna­cza uak­tu­al­nie­nie, uno­wo­cze­śnie­nie, roz­sze­rze­nie (źr. bab​.la). Jedną z klu­czo­wych cech dobrej archi­tek­tu­ry jest kom­pa­ty­bil­ność wstecz. Wdrażanie to (s.j.p.) to wpro­wa­dzać coś nowe­go do użyt­ku, zacząć sto­so­wać coś w prak­ty­ce. Jedno jest pew­ne: nie jest to wymiana.

Jeżeli więc ktoś fun­du­je Państwu” upgra­de jako pro­jekt co naj­mniej rów­nie skom­pli­ko­wa­ny co insta­la­cja bazo­wa” to zna­czy, że to opro­gra­mo­wa­nie, lub spo­sób jego wdro­że­nia, poła­ma­ło wszel­kie dobre prak­ty­ki wdra­ża­nia opro­gra­mo­wa­nia i budo­wa­nia jego architektury.

Można się spo­tkać w przy­pad­ku upgra­de z poję­ciem dłu­gu tech­no­lo­gicz­ne­go (czy­taj arty­kuł o dłu­gu tech­no­lo­gicz­nym) ale to tak­że wie­lo­let­nie zanie­dba­nie ze stro­ny pro­du­cen­ta oprogramowania…

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).

Ten post ma 4 komentarzy

  1. Michał Bukowski

    Dług tech­no­lo­gicz­ny może być tak­że kon­se­kwen­cją wie­lo­let­nich zanie­dbań ze stro­ny posia­da­cza (nabyw­cy) oprogramowania.

    1. Jaroslaw Zelinski

      To praw­da, to jed­nak typo­we grze­chy zanie­cha­nia. I fak­tycz­nie nie zwró­ci­łem tu na to uwa­gi. U pro­du­cen­ta dłu­giem tech­no­lo­gicz­nym jest utrzy­my­wa­nie sta­rej nie­efek­tyw­nej archi­tek­tu­ry i korzy­sta­nie z prze­sta­rza­łej tech­no­lo­gii. W takich wła­śnie przy­pad­kach upgra­de bywa rewo­lu­cją, nie zmie­nia to fak­tu, że wyda­nie nowej wer­sji sys­te­my kom­plet­nie nie­kom­pa­ty­bil­nej wstecz jest raczej dziw­nym podejściem.

  2. Marcin Karczewski

    Znam fir­my, któ­re spe­cjal­nie nie inwe­stu­ją w archi­tek­tu­rę umoż­li­wia­ją­cą płyn­ny upgra­de. Po pro­stu kasu­ją dodat­ko­wo klien­ta za każ­dą aktu­ali­za­cję. Ktoś musi poje­chać do klien­ta, poprze­py­chać” skryp­ty itp. Interes się krę­ci. Są to jed­nak prze­waż­nie dość duże i kosz­tow­ne systemy.

    Czasy się zmie­nia­ją, upo­wszech­nia się clo­ud-com­pu­ting i wyda­je mi się, że dostaw­cy opro­gra­mo­wa­nia będą musie­li spła­cić zacią­gnię­ty dług technologiczny.

    Na przy­kła­dzie jed­ne­go z naszych pro­duk­tów prze­ko­na­li­śmy się, że celu­jąc w dłu­gi ogon”, czy­li bar­dzo wie­lu klien­tów będą­cych w sta­nie zapła­cić za usłu­gę sto­sun­ko­wo nie­wie­le ( rzę­du kil­ku­set zło­tych – , trze­ba bar­dzo dobrze zapro­jek­to­wać archi­tek­tu­rę roz­wią­za­nia, aby kolej­ne wdro­że­nia i aktu­ali­za­cje prze­cho­dzi­ły bez­pro­ble­mo­wo, a nawet automatycznie. 

    Myślę, że to jest korzyst­ne pole wal­ki dla małych firm kon­ku­ru­ją­cych z duży­mi kor­po­ra­cja­mi, gdzie bez kon­sul­tan­ta / wdro­że­niow­ca / pro­gra­mi­sty (100 PLN/h i w górę) ani rusz.

    1. Jaroslaw Zelinski

      Myślę, że jest to pole wal­ki do mniej­szych firm mają­cych ambi­cje nie mieć żad­nych dłu­gów tech­no­lo­gicz­nych. W dobie nara­sta­ją­cej tren­du zawie­ra­nia umów fixed pri­ce” poję­cie staw­ki godzi­no­wej spa­da na dru­gi, nawet trze­ci plan, zaczy­na grać ogrom­ną rolę budżet na cały pro­jekt – zamknię­ty budżet i zakres.

Dodaj komentarz

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