Paras vastaus
Mielenkiintoinen kysymys. Minulle käsite ”käsityötaito” merkitsee jotain varsinaisen koodin kirjoittamistavasta, ei korkeamman tason järjestelmäsuunnittelusta. Sanon, että hyvin muotoiltu koodi toimii seuraavasti:
- noudattaa ulkoisia standardeja
- noudattaa sisäisiä standardeja
- käyttää hyviä malleja
- on luettavissa
Seuraa ulkoisia standardeja. Jos ryhmälläsi on koodausstandardeja, noudata niitä. Jos et ” Kuten standardeista, noudata silti niitä.
Seuraa sisäisiä standardeja. Tämä tarkoittaa, että koodin tulee olla sisäisesti johdonmukainen. Menetelmät, jotka tekevät samankaltaisia asioita, tulisi suunnitella samalla tavalla. Jos yksi menetelmä noudattaa mallia:
if (success) {
doSomething();
} else {
handleError();
}
ei ole muuta alkavaa menetelmää:
if (!success)
{
handleError();
Käyttää hyviä malleja. Tarkoitan tällä koodausmalleja suunnittelumallien sijasta. Koodisi tulisi käyttää kielelle sopivia idiomeja. (Käytä esimerkiksi scoped\_ptrs-muistia C ++: n muistinhallinnassa.) Sen tulisi välttää ilmeisiä tehottomia toimintoja, kuten C ++-iteraattoreiden jälkikäteistäminen tai luominen objektit, joita ei käytetä kaikilla koodipoluilla.
on luettavissa. Muut insinöörit lukevat koodisi, ja sinä luet uudelleen se vuosien kuluttua. Koodin tulee olla mahdollisimman helppo ymmärtää. Kaikki edellä mainitut kohteet koskevat ensisijaisesti luettavuutta ja odottamattomien elementtien minimointia koodissa. Lukijoiden tulisi olla huolissaan koodisi logiikasta, ei yrittää selvittää miksi epätyypillistä rakennetta on käytetty. Jos on olemassa epätyypillinen rakenne, lukijoiden tulisi tietää, että se on siellä syystä, ei siksi, että tekisit virheen. (Ajattele koodiasi kuin huonekalu. Pinnan tulee olla sileä, eikä sinun pitäisi tarttua sirpaleeseen, jos ajaa kätesi sen yli. Mahdollisten epäsäännöllisyyksien tulisi olla syystä.)
Luettavuutta parannetaan myös järkevällä menetelmällä ja muuttujien nimillä sekä asianmukaisilla kommenteilla. Kommentoinnissa ei saa mennä yli laidan. Jos se on ilmeistä, älä vaivaudu selittämään sitä. Mutta sinulla on jonkinlainen yleiskatsaus, jotta lukija tietää kontekstin. (Voi olla ilmeistä, että koodi muuttaa tuloa X ulostuloksi Y, mutta se auttaa, jos lukijalla on jonkinlainen käsitys siitä, miksi sitä tarvitaan.)
Vastaus
Esimiehet ovat kuin pikkulapset. He haluavat mitä haluavat ja haluavat sen NYT ! Toisin kuin pikkulapsilla, esimiehet ovat puoliksi muistaa Harvard Business Review -artikkelit, joihin ne viittaavat (antamatta viitteitä) perustellakseen vaatimuksiaan. He ovat oppineet joukon argumentteja, jotka pakottavat joitain kehittäjiä.
He sanovat: ”Meillä ei ole varaa tehdä sitä oikein. Meidän on saatava se markkinoilta NYT ! ”. Se ei ole totta, tiedät. Jos he kiirehtivät spagettikoodinsa tuotantoon, heillä on mahdollisuus kiusata käynnistysasiakkaitaan nyt, mutta koodi ei voi skaalata. Se tarkoittaa vain, että heidän liiketoimintansa sekoittuvat hetkeksi ennen romahtamista.
He sanovat: ”Julkaisemme beta-version julkaisuasiakkaillemme.” He tarkoittavat, että he haluavat sinun julkaisevan täydellisen, asiakkaille miellyttävän koodin aikaisemmin kuin muuten, vain siksi, että he suostuivat kutsumaan sitä beetatestiohjelmaksi. Se on maagista ajattelua, kuten uskominen joulupukkiin.
He sanovat: ”Lupaan, että kirjoitamme koodin myöhemmin, jos vapautat raittiin, puolivalmiin koodisi NYT ! ” Eikö tämä kuulosta siltä, että ”siivoan huoneeni myöhemmin isä, jos voin katsella televisiota ja syödä makeita välipaloja NYT ?” Ongelmana on, että myöhemmin ei koskaan tule. Joka päivä johtajalla on mahdollisuus lisätä joko uusia ominaisuuksia tai siivoaa sotkuinen huone, joka on heidän koodipohjansa. Arvaa mitä he pitävät etusijalla. Ja arvaa mitä, huone muuttuu siistimmäksi ja kiusaisemmaksi, joten siivous vie kauemmin ja kauemmin. Kaikkien sotkuuksien takia on vaikeampaa työskennellä (luoda uusia ominaisuuksia).
Lopulta he sanovat: ”Olemme investoineet liikaa tähän koodipohjaan. Uudelleen kirjoittaminen kestää liian kauan. Tarvitsemme ominaisuuksia NYT ! ” Vain kunkin ominaisuuden koodaaminen kestää kaksi tai kolme kertaa niin kauan, koska ohjelmistokehittäjät kutsuvat teknistä velkaa.
Hyvien kehittäjien, kuten kärsivällisten ja rakastavien vanhempien, on lopetettava hulluus. Heidän on vaadittava lujasti: ”Anteeksi rakkaus, mutta HBR -artikkelissasi sanotaan:” Tulot nopeammin ovat parempia, kaikki muut asiat ovat tasa-arvoisia . Sinun täytyy lukea se huolellisemmin.Kaikki muut asiat eivät ole samanarvoisia, jos kasaat teknistä velkaa. Entä jos priorisoimme ominaisuudet, ja ehkä on jotain, mitä voit myydä aikaisemmin. ”
Sinun on oltava aikuinen ja ilmoitettava heille, että ei ole olemassa sellaista asiaa kuin Joulupukki, eikä kuten täydellinen, asiakkaalle miellyttävä koodi, kunnes kaikki virheet on poistettu ja kaikki ominaisuudet on otettu käyttöön.
Sinun on kerrottava heille: ”Meillä ei ole varaa ei käyttää hyviä käytäntöjä. Elämme tai kuolemme, mutta meidän on tehtävä tiettyjä asioita elääksemme, kuten testien ja asiakirjojen kirjoittaminen. Se ei ole vaihtoehto. ”
Sinun täytyy hymyillä ja sanoa:” Emme koskaan kirjoita tätä koodia uudelleen. Tiedän, että tarkoitat hyvin, mutta kun se tulee korjaamaan koodi tai lisäämään uusia ominaisuuksia, tiedän mitä sanot. Se mitä sinä aina sanot. ”
Ollessasi vahva vanhempi, autat esimiehiäsi kasvamaan sellaiseksi yritysjohtajaksi kuin sinä haluaisi työskennellä.