Malliankkusyrjäyksen vaara

Olet varmaankin istunut jossain arkkitehtuurikatselmuksessa, jossa joku on kaivanut esiin pattern-katalogin kuin tarjoilija lounaslistan. "Tähän voisi käyttää Factorya. Tuossa Strategyn voisi ottaa. Entäs CQRS?"

Tämä ei ole arkkitehtuuria. Tämä on pattern-matching naamioituneena suunnitteluksi.

Devaajien keskusteluissa pyörii ajatus, joka osuu naulankantaan: hyvä software-arkkitehtuuri syntyy ongelman mallintamisesta – ei yrityksestä sovittaa ongelma valmiiseen pattern-kokoelmaan. Parhaat kehittäjät oppivat käyttämään työkalujaan, ymmärtämään materiaaliaan ja seuraamaan visiotaan sen sijaan, että he kaivaisivat esiin piparkakkumuotteja, jotka peittävät silmien eteen ilmeisen ratkaisun.

Miksi web-kehityksen resursseja on kaikkialla, mutta systems programming -arkkitehtuurista on vaikea löytää järkevää?

Jos haluat oppia mikropalveluista, konttiorkesteroinnista tai hajautetuista järjestelmistä web-kontekstissa, onneksi olkoon – materiaalia on meren verran. Mutta entä jos rakennat käännösohjelmaa, upotettua järjestelmää, pelimoottoria tai tietokantaa?

Maisema muuttuu dramaattisesti.

Suurin osa nykypäivän "software architecture" -sisällöstä keskittyy web-scale-sovellusten huoliin: horisontaaliseen skaalautumiseen, service discoveryyn, eventual consistencyyn ja suurten insinööritiimien organisatorisiin haasteisiin. Nämä ovat laillisia ongelmia, mutta eivät universaaleja ongelmia.

Systems-ohjelmoijille ja muille kuin web-kehittäjille sanasto vaihtuu. Ajattelet:

• Muistilayout ja käyttöprofiilit
• Latenssitarpeet ja real-time-rajoitteet
• Resurssirajoitetut ympäristöt
• Formaalinen verifiointi, kun korrektius on kriittistä
• Rakentamista vuosikymmenten ylläpitoa varten, ei vain seuraavaa sprinttiä

Haaste on, että hyvät resurssit tälle maailmalle ovat hajallaan, usein akateemisia, ja harvoin kehystävät itseään "arkkitehtuuriksi" – vaikka sitä ne täysin ovat.

Mitä oikeasti tarvitaan: Mental models ennen patterns

Eikä niitä listojen väsyttäviä esimerkkejä – keskity yhteen hyvään per kappale. Tässä mental frameworks, jotka ovat osoittautuneet arvokkaiksi robusttien järjestelmien rakentamisessa, oli kyse sitten upotetusta C:stä tai enterprise Java:sta:

1. Rajoitteet ensin

Jokainen järjestelmä toimii rajoitteiden sisällä: budjetti, aika, tiimin koko, suorituskykyvaatimukset, säädösympäristö. Arkkitehtuuri, joka syntyy rajoitteiden syvällisestä ymmärtämisestä, päihittää aina "oikean" arkkitehtuurin, joka ohittaa ne.

2. Data flow pohjana

Ennenkuin alat miettiä luokkia, moduuleja tai palveluita, ymmärrä miten data tulee järjestelmään, muuntuu ja poistuu. Arkkitehtuuri usein selkeytyy, kun tämän maptaa kunnolla. Oudot abstraktiot katoavat; tarpeelliset paljastuvat välttämättömiksi.

3. Riippuvuuksien omistajuus

Kuka omistaa tämän datan? Kuka voi muuttaa tätä tilaa? Selkeät vastaukset näihin kysymyksiin estävät suurimman osan arkkitehtuurisotkuisuuksista. Sekaannus omistajuudessa – erityisesti datan omistajuudessa – on se paikka, jossa useimmat järjestelmät alkavat mädäntyä.

4. Indirektion hinta

Jokaisella abstraktiolla on hintansa. Jokainen indirection kerros vaikeuttaa debuggausta ja tekee suorituskyvystä vaikeammin ennustettavaa. Kysymys ei ole "pitäisikö minun abstrahoida tämä?" vaan "mitä minä ostan tällä abstraktiolla, ja onko se hintansa arvoista?"

5. Käyttäytymisen paikallisuus

Koodi, joka on helppo ymmärtää itsenäisesti, joka ei vaadi kolmen tiedoston pitämistä samalla kertaa mielessä, on koodia joka kestää seuraavat viisi vuotta ylläpitoa. Arkkitehtuuri, joka luo kognitiivista kuormitusta, yksinkertaistetaan lopulta – usein jonkun toimesta, joka ei ymmärrä miksi se alun perin rakennettiin noin.

Suositellut resurssit (Ei-web-tyyppiset)

Jos haluat syventää arkkitehtuuriajatteluasi menemättä web-scale pattern -kaniinieläimeen, harkitse näitä:

• "A Philosophy of Software Design" by John Ousterhout – Tämä on edelleen yksi selkeimmistä ajatuksista monimutkaisuuden hallinnassa software-järjestelmissä. Se on kieliriippumaton ja syvästi käytännöllinen.

• Akateemisia papereita käyttöjärjestelmistä ja hajautetuista järjestelmistä – erityisesti ennen mikropalvelu-aikakautta julkaistuja. Esimerkiksi tiedostojärjestelmien suunnittelusta kertovat paperit sisältävät arkkitehtuurista viisautta, joka pätee paljon laajemmin kuin tiedostojärjestelmiin.

• Hyvin suunniteltujen järjestelmien lähdekoodin lukeminen – Tämä kuulostaa ilmeiseltä, mutta harvat kehittäjät tekevät sitä systemaattisesti. Kun ymmärrät, miten tietokannat, kääntäjät ja hyvin rakennetut open source -projektit ratkaisevat vaikeita ongelmia, opit enemmän kuin yhdestäkään pattern-kirjasta.

Taide tieteen takana

Tässä epämukava totuus: software-arkkitehtuuri on enemmän taidetta kuin tiedettä, eikä tämä ole muuttumassa.

Voimme puhua periaatteista ja heuristiikoista. Voimme mitata couplingia ja cohesionia. Voimme luoda malleja ja diagrammeja. Mutta loppujen lopuksi arkkitehtuuri heijastaa ihmisten harkintakykyä, jotka järjestelmän rakentavat – heidän kykyään nähdä ongelma selkeästi, kokemustaan siitä, mikä menee usein pieleen, ja taitoaan tehdä trade-offpäätöksiä, jotka palvelevat todellisia tarpeita teoreettisten ideaalien sijaan.

Kehittäjät, jotka rakentavat parhaita järjestelmiä, jakavat yhteisen piirteen: he ovat syvästi uteliaita ongelma-alueesta, eivät vain teknologiasta. He kysyvät "miksi tämä on vaikeaa?" ennen kuin kysyvät "mitä patternia minun pitäisi käyttää?"

Aloita siitä. Ymmärrä ongelmasi syvällisesti. Anna ratkaisun nousta esiin. Ja kun joku yrittää myydä sinulle patternia arkkitehtuurina, kysy häneltä minkä ongelman se ratkaisee – ja onko tuo ongelma edes olemassa sinun järjestelmässäsi.