Mitä huonompi sen parempi

Huonompi on parempi  - lähestymistapa ohjelmistokehitykseen , joka julistaa toteutuksen helppouden ja käyttöliittymän yksinkertaisuuden tärkeämmäksi kuin muut järjestelmän ominaisuudet. Richard P. Gabriel kuvailee tätä tyyliä julkaisussa Lisp : Good News, Bad News, How to Win Big kohdassa "The Rise of 'Worse is Better", ja se julkaistaan ​​usein erillisenä artikkelina.

Essence

Gabriel kuvailee lähestymistapaa seuraavasti:

  1. Yksinkertaisuus: Toteutuksen ja käyttöliittymän tulee olla yksinkertaisia. Käyttöönoton helppous on vielä tärkeämpää kuin käyttöliittymän yksinkertaisuus. Yksinkertaisuus on tärkein vaatimus suunnittelua valittaessa.
  2. Oikeus: Suunnittelun tulee olla oikein kaikissa näkyvissä ilmenemismuodoissa. Yksinkertainen muotoilu on hieman parempi kuin oikea.
  3. Johdonmukaisuus (yhtenäisyys): Suunnittelu ei saa olla liian epälooginen. Joskus logiikka voidaan uhrata yksinkertaisuuden vuoksi, mutta on parempi hylätä osa suunnittelusta, joista on vain harvoin hyötyä, kuin monimutkaistaa toteutusta tai uhrata johdonmukaisuutta.
  4. Täydellisyys: Suunnittelun tulee kattaa mahdollisimman monet tärkeät tilanteet. Täydellisyys voidaan uhrata muiden ominaisuuksien hyväksi, ja se on uhrattava, jos se häiritsee yksinkertaisuutta. Johdonmukaisuus voidaan uhrata täydellisyyden hyväksi, jos yksinkertaisuus säilyy (looginen käyttöliittymä on erityisen hyödytön).

Gabriel pitää C-kieltä ja Unix -järjestelmää esimerkkeinä tästä lähestymistavasta.

MIT

Artikkeli vertaa sitä lähestymistapaan, jota kutsutaan "MIT-lähestymistapaksi" ( MIT  - Massachusetts Institute of Technology). Gabriel kuvailee tätä lähestymistapaa suunnitteluun seuraavasti:

  1. Yksinkertaisuus: Toteutuksen ja käyttöliittymän tulee olla yksinkertaisia. Käyttöliittymän yksinkertaisuus on tärkeämpää kuin toteutuksen yksinkertaisuus.
  2. Oikeus: Suunnittelun tulee olla kaikin puolin oikea. Väärä suunnittelu on ehdottomasti kielletty.
  3. Johdonmukaisuus on yhtä tärkeää kuin oikeellisuus. Logiikan vuoksi voit uhrata yksinkertaisuuden ja täydellisyyden.
  4. Täydellisyys: Suunnittelun tulee kattaa mahdollisimman monet tärkeät tilanteet. Kaikki mahdolliset tilanteet on ennakoitava. Yksinkertaisuuden ei pitäisi häiritä liikaa täydellisyyttä.

Tehoste

Gabriel väittää, että "huonompi on parempi" lähestymistapa on parempi kuin "MIT-lähestymistapa". Helposti toteutettava järjestelmä on helposti siirrettävissä eri käyttöjärjestelmiin, eli se leviää nopeasti jo ennen kuin MIT-periaatteiden mukaan tehty järjestelmä on kirjoitettu. Helpommin toteutettava järjestelmä houkuttelee lisää käyttäjiä, jotka ymmärtävät sen toiminnan ja haluavat parantaa sitä. Parannuksia jatketaan, kunnes järjestelmä on lähes täydellinen. Esimerkkinä Gabriel mainitsee C- ja Lisp -kääntäjät . Gabriel kirjoittaa, että vuonna 1987 näiden kielten kääntäjät olivat laadultaan lähes yhtäläisiä, mutta C-kääntäjää halusi parantaa paljon enemmän kuin Lisp-kääntäjää.

Vaikka Gabriel saattoi olla ensimmäinen, joka muotoili tämän periaatteen, samanlaisia ​​ideoita käytettiin paljon aikaisemmin UNIXin ja avoimen lähdekoodin ohjelmistojen ideologiassa .

Katso myös

Linkit