Vapaa ohjelmistokehitysmalli: Katedraali ja basaari

Katedraali ja basaari on manifestityyppinen asiakirja, jonka on kehittänyt Eric S.Raymond vuonna 1.998 yrittääkseen selittää omasta näkökulmastaan ​​ja kokemuksestaan ​​(Fetchmail Development) mitä hän ymmärsi Linuxin ja siihen liittyvien ohjelmien onnistuneesta luomisesta ja kehityksestä, etenkin hänen henkilökohtaisesti kutsumiensa ohjelmistokehitysmallien välisen eron näkökulmasta: Cathedral Model ja Bazaar Model.

Ja tässä julkaisussa annamme analyysin ja yhteenvedon mainitusta manifestista, joka on niin suosittu vapaiden ohjelmistojen liikkeen kehittäjien keskuudessa. Se on saatavana vapaasti ja saatavana monissa osissa verkkoa, mutta se voidaan ladata seuraavalta verkkolinkiltä, ​​jotta sitä voidaan käyttää nopeammin: Katedraali ja basaari.

ESITTELY

Sanottu materiaali «Tuomiokirkko ja basaari» tarjoaa meille näkemyksen siitä, että ohjelmistotuotannon maailmassa on "kaksi täysin erilaista kehitystyyliä, katedraalimalli, jota voidaan soveltaa useimpiin kaupallisten ohjelmistojen maailmassa tehtyihin kehityksiin verrattuna basaarimalliin, joka on tyypillisempi Linux-maailmalle.

Korostamalla, että nämä 2 mallia on johdettu ohjelmistojen virheenkorjausprosessin luonteen vastakkaisista lähtökohdista, ja hänen erityisestä teoriastaan ​​siitä, mitä hän kutsui Linusin laiksi, joka totesi seuraavaa: "Kun otetaan huomioon riittävä määrä silmiä, kaikilla virheillä ei ole merkitystä" tai toisin sanoen: "Riittävän määrän silmiä, kaikki virheet ovat vähäpätöisiä".

Ja siinä korostetaan sanaa Hacker, jonka kirjoittaja mielestäni ilmaisi eräänlaisena korkean tason käyttäjänä, joka kykenee ymmärtämään ja tehokkaasti hyödyntämään ohjelmaaja havaita, ehdottaa tai toteuttaa tehokkaan muodon ja sisällön korjauksia tai muutoksia koko käyttäjäyhteisölle.

Muissa kirjallisuuksissa tämä sana tai käsite nimeltä Hacker viittaa:

«asiantuntija, intohimoinen tietystä aihealueesta, etenkin teknologia-alueesta, ja jonka tarkoituksena on hyödyntää tätä tietoa hyvänlaatuisissa tarkoituksissa. Se on henkilö, joka on yleensä tietämyksen ammattilainen, joka on intohimoinen tietoon, uusien asioiden löytämiseen ja oppimiseen sekä heidän toimintansa ymmärtämiseen, saavuttaen tilanteen parantamisen tehokkailla ehdotuksilla ja aina tarkoituksella jakaa tietoa tai välttää tutkimuksen kohteen epäonnistuminen tai toimintahäiriö.

Mikä on yleismaailmallisempi ja todellisempi käsite, koska "hakkereita" on kaikilla inhimillisen tiedon alueilla.

DESARROLLO

Monista, jotka ovat lukeneet tällaista materiaalia, on varmasti suuri joukko, jotka ovat samaa mieltä siitä, että ajatus "Linux on kumouksellinen" ilmaistaan ​​siellä selvästi. Mutta miksi?

Koska siihen asti oli useita standardoituja ohjelmistokehitysmenetelmiä tai -malleja, jotka perustuvat "keskitetymmään ja suunnitellumpaan lähestymistapaan alusta alkaen" koska ohjelmiston luominen katsottiin liittyvän johonkin, mikä johtaa "tiettyyn kriittiseen monimutkaisuuteen".

Ja että siitä huolimatta, että Unix-maailma oli jo olemassa, se koostui pienistä työkaluista, nopeasta prototyyppien luomisesta ja evoluutioohjelmoinnista, Vapaiden ohjelmistojen kehitysfilosofian ilmaantuminen Linuxissa vei asian uudelle hienostuneisuuden tasolle.

Vaikka Yksityisen ohjelmistokehityksen maailmassa se tehtiin "hiljaisella ja kunnioittavalla tavalla", aivan kuten katedraali rakennetaan, vapaan ohjelmistokehityksen maailmassa (Linux) se tehtiin "meluisalla tavalla ja useilla esityslistoilla (poluilla) ja lähestymistavoilla (ehdotuksilla)", aivan kuten olit mahtavassa basaarissa.

Tämän suuren manifestin ansiosta voimme tiivistää siellä ilmaistuja ajatuksia vapaan ohjelmistokehitysmallin suhteen:

TILA # 1

KAIKKI OHJELMISTON HYVÄT TYÖPAIKAT YRITTÄVÄT KEHITTÄJÄN HENKILÖKOHTAISIA ONGELMIA.

Mikä on kiistaton todellisuus, koska Monet vapaan ohjelmistokehityksen parissa työskentelevät aloittavat yleensä tarpeen ratkaista henkilökohtainen ongelma tai kollektiivin tai ryhmän ongelma, tai optimoida prosessi, joka on jo suoritettu hitaammin ja / tai toistuvasti, mikä usein pyrkii uuvuttamaan ja / tai tylsää siihen osallistuville yrittäen maksimoida osallistujien aikaa ja ponnisteluja.

TILA # 2

Hyvät ohjelmoijat tietävät mitä kirjoittaa. SUURIMMAT TIEDOT MITÄ KIRJOITTAA JA KÄYTETÄÄN.

Jokainen ohjelmoija tietää, että ohjelman aloittaminen alusta alkaen ei ole mitään pahaa tai tarpeetonta. Monille aloittelijoille ja muille, jotka ovat jo perehtyneitä asiaan, on kuitenkin tunnettua, että joskus "Pyörän keksiminen" ei ole kovin tehokasta, mutta on parempi vain optimoida se ja mukauttaa se omiin tarpeisiisi. Toisin sanoen on parempi kirjoittaa ja omaksua kaikki mahdolliset koodit muilta alan asiantuntijoilta, jotka huolestuttavat meitä oman ohjelmistokehityksemme ratkaisemiseksi.

TILA # 3

"Ajattele heittämistä ainakin yhdellä - lopetat sen tekemisen milloin tahansa."

Hyvän ohjelmistokehittäjän on osattava kuunnella yksityiskohtaisesti, mitä heidän kehitystensä käyttäjät sanovat tai ehdottavat tai ehdottavat, koska jo toimivasta ohjelmasta voi silti tulla jotain hyvin isoa, vaikka se olisi toimiva, jotain, joka menettää pohjoisen, toimivan hirviön joka tekee kaiken kaikille ja puolestaan ​​jotain ei miellyttävää. Joten kuunteleminen palata alkuperään, palauttaa kadonneet käyttäjät, lisätä uusia toimintoja, poistaa tarpeettomat toiminnot, tehdä ohjelmasta pienempi, tarkempi ja yleisempi, on aina hyvä käytäntö.

TILA # 4

JOS SINULLA ON OIKEA ASETTAMUS, KIINNOSTAVAT ONGELMAT TULOSTAVAT SINUN.

Hyvä asenne- ja ajallinen muutos voi tarkoittaa radikaalia muutosta jokaiselle ohjelmoijalle tai ohjelmistokehittäjälle nykyisessä tai uudessa kehityksessään, mikä puolestaan ​​merkitsee uusia ajan, rahan tai mukavuuden etuja tuotteidensa käyttäjille. Etsikää innovatiivisia tapoja ratkaista ongelmia, jotka ovat hyvässä oireessa oikeaan suuntaan.

TILA # 5

KUN OHJELMA EI enää kiinnosta sinua, viimeinen velvollisuutesi on siirtää se pätevälle seuraajalle.

Monille ohjelmoijille tai ohjelmistokehittäjille sekä muille tekniikoille ei ole harvinaista, että haluamme omistaa uuden ajan uusille projekteille. Mutta vapaiden ohjelmistojen maailmassa lähtökohtana on välittää viestikapula. On muitakin, jotka haluavat jatkaa jo hylättyjen tuotteidensa kehittämistä, minkä vuoksi heidän on sallittava kenen tahansa hakkeroida (parantaa) ohjelmaa itselleen tai hyötyä ohjelman yhteisön käyttäjille.

TILA # 6

KÄYTTÄJIIDEN KÄSITTELEMINEN YHTEISTYÖKUMPPUINA ON VÄHEMMÄN VAATIVA TAPA OHJELMAN NOPEAAN PARANTAMISEEN JA TEHOKASTA PURKAMISEEN.

Koska ilmaista tulkitaan usein ilmaiseksi ilmaisten ohjelmistojen kehityksessä, monet ohjelmoijat pyrkivät ryhmittymään yhteen välttääkseen maksamattoman kulumisen liittymällä muiden kehittäjien tai kehittyneiden käyttäjien kanssa heidän kehitystyöhönsä, jatkamaan tai toisten jatkamista heille vastineeksi "hyvitysten" saamisesta tulevien koodiinnovaatioiden kehittämisessä ja sen varmistamisesta, että tulevaan kehitykseen sisältyy virallisesti jonkin verran lisenssejä, jotta vältetään niiden väärinkäyttö.

TILA # 7

Vapauta pian. Käynnistä se usein. JA KUUNTELE KÄYTTÄJÄTÄ.

Toisin kuin oma ohjelmistokehitys, vapaissa ohjelmistoissa on usein paljon ja nopeasti parempi. Koska laaja käyttäjäkunta ja kehittäjät, jotka yleensä käyttävät ja kehittävät ohjelmaa yhteisössä ja vuorovaikutuksessa toistensa kanssa, ilmoittavat epäilyistään, ehdotuksistaan, ehdotuksistaan, valituksistaan ​​ja / tai väitteistään, voi tulla arvokkaaksi tietolähteeksi nopeasti kehittää ohjelmaa kohti kehittyneitä kehitysvaiheita.

TILA # 8

ANTI LAAJAN TARJOAMISEN TESTAJIEN JA OSALLISTAJIEN POHJAN, MÄHÄ KAIKKI ONGELMAT TUNNISTETTAVAT NOPEASTI, JA NIIDEN RATKAISU ON JOSKIN HELMÄTÖN.

Aine päättyy tekemään lukija päättelemään monta kertaa, että Bazaar-malliin perustuva ohjelmistokehitysmenetelmä on erittäin tehokas. Koska mitä enemmän voimaa, vapautta tai tietoa ohjelmistokehittäjä antaa käyttäjille ohjelmastaan, sitä enemmän he voivat antaa nerokkaita ideoita tai hyödyllisiä muutoksia vain kollektiivisen edun nimissä.

Ja tämä ilmaistaan ​​miellyttävästi seuraavassa otteessa materiaalista:

"Mielestäni tämä on olennainen ero katedraalin ja basaarin tyylien välillä. Sen mukaan, miten katedraali suhtautuu ohjelmointiin, virheet ja kehitysongelmat ovat salakavalia, syviä ja vääntyneitä ilmiöitä. Pieni määrä omistautuneita ihmisiä kestää kuukausia, jotta he voivat luottaa siihen, että heidät on poistettu. Tästä syystä uusien versioiden julkaisemiseen vaaditut pitkät jaksot ja väistämätön pettymys, kun niin kauan odotetut eivät ole täydellisiä.

Basaarimallin valossa oletetaan kuitenkin, että virheet ovat yleensä vähäisiä asioita tai ainakin niistä tulee niin nopeasti, kun ne altistuvat muutaman tuhannen omistautuneen yhteistyökumppanin innokkaille silmille oikean ja päinvastoin jokaisessa uudessa versiossa. Joten julkaiset versioita jatkuvasti saadaksesi vielä enemmän korjauksia, ja hyödyllisenä sivuvaikutuksena sinulla on vähemmän menetettävää, jos sekoitat silloin tällöin. "

YHTEENVETO

Henkilökohtaisesti vähäinen kokemukseni vapaiden ohjelmistojen kehittämisestä Bazaar-tyyppisessä mallissa antaa minulle seuraavat johtopäätökset:

• Käyttäjiä tulisi kohdella korvaamattomana resurssina ja parhaimmillaan korvaamattomina liittolaisina yhteistyössä tuotteen kehittämisessä.
• Jokainen idea on hyvä tai tutkimuksen arvoinen, koska joskus vähiten epäilty voi olla loistava ratkaisu tai parannus kehitykseen.
• On hyvä tai todennäköistä, että alkuperäinen idea jakaa, laajenee tai siirtyy pois alkuperäisestä konseptista, mutta tärkeätä on, kuinka keskittyneenä tulisi olla sen tyyppisten käyttäjämarkkinoiden suhteen, joita haluat palvella, palvella tai auttaa.
• Tehokkuuden välttämiseksi ja hajaantumisen aiheuttamien vaivojen välttämiseksi
• Parasta on pieni, suora, yksinkertainen, mutta tehokas koodi, jonka yhteisö pystyy arvostamaan oikeeksi.
• Ohjelma on jo kypsä käyttäjien yhteisölle, kun ei ole enää mitään poistettavaa, koska lisääminen on aina hyvä mahdollisuus ottaa huomioon.
• Mitä tahansa ohjelmaa voidaan käyttää (osittain tai kokonaan) uudelleenkäytettäväksi toiminnoissa, joita ei alun perin suunniteltu.
• Kaikilla ohjelmistoilla on oltava vastaavat lisensointi- ja suojaustoimenpiteet käyttäjän tietojen luottamuksellisuuden varmistamiseksi.
• Ei ole välttämätöntä aloittaa tyhjästä, joku on aina kehittänyt jotain samanlaista kuin ajateltu ajatuksemme.
• On työskenneltävä sellaisen suhteen, mikä on tykkää, hänen täytyy tuntea intohimo kehitykseen, johon hän omistautuu vapaissa ohjelmistoissa, jotta syntyy sisäisesti tunne yhtenäisyyttä kehiteltyyn nähden saavuttamatta äärimmäisyyttä omistajuuden tunteen kehittämisestä. se.
• Kehittäjien ja käyttäjien (yhteistyökumppaneiden) välillä on oltava erinomaiset ja toistuvat viestintävälineet, jotta työ sujuu nopeasti ja muuttuu tehokkaasti.

Toivon, että pidit ja pidit näistä tiedoista hyödyllisinä, koska "Katedraali ja basaari" -lehti on pakollinen viite kaikille niille, jotka ohjelmoivat minkä tahansa vapaan ohjelmistokehityksen, riippumatta siitä kuinka suuri tai pieni.