Hyvän ohjelmoinnin säännöt. Hyvän koodin kriteerit ohjelmoinnissa. Vaikein asia on aloittaa

Useimmat ohjelmoijien palkkaamisesta kirjoitetut artikkelit kuulostavat enemmän tai vähemmän samalta. Tyypillisesti tällaiset artikkelit suosittelevat "palkkaamaan vain parhaat". Myönnän, en ole innostunut tästä neuvosta, koska se kuulostaa liian epämääräiseltä. Se on sama kuin jos tulisit autoliikkeeseen ja kysyisit myyjältä, mitä autoa hän suosittelisi sinulle, ja hän vastaisi, että "Paras" ei ole merkitty kenellekään autoliikkeessä.

Älä ymmärrä minua väärin, en neuvo sinua etsimään tietoisesti keskinkertaisia ohjelmoijia. Tietenkin kaikki haluavat palkata vain lahjakkaimmat ja kokeneimmat ohjelmoijat. Palkkauspäätöksillä on korkeat panokset. Päätöksesi vaikuttaa koko tiimin ja sen yksittäisten jäsenten työhön. Kuten he sanovat:

"Hyvän ehdokkaan hylkääminen on paljon parempi kuin huonon hyväksyminen... Jos sinulla on pienintäkään epäilystä, älä palkkaa"

Mutta tavalliset neuvot ärsyttävät minua edelleen. Kyse ei ole niinkään itse neuvoista, vaan siitä, että ihmisillä on taipumus ymmärtää ne väärin. Jos sitä sovelletaan ilman lisäsäätöjä, tämä käytäntö luo lähinnä itsetuntoa. Tämä vaikutus on erityisen yleinen ohjelmoijien keskuudessa, koska elitismi on jotenkin meille ominaista. Kun kuulemme, että meidän pitäisi palkata vain "paras", tämä neuvo käy läpi alitajuisen muutoksen:

"Paras?" Mutta se olen minä! Olen paras". Tietenkin minun on palkattava ihmisiä, jotka ovat yhtä lahjakkaita, älykkäitä ja hyvännäköisiä kuin minä. Ja miksi roskaamaan ihanaa tiimiäni kaikenlaisella sotkulla?

Ketkä ovat parhaat ohjelmoijat?

Tämä lähestymistapa ei tietenkään luo parhaita edellytyksiä päätöksenteolle. Vakiosääntö toimii paljon paremmin, jos ymmärrämme sen hieman eri tavalla:

”Haluan muodostaa mahdollisimman tehokkaan joukkueen. Palkkaamalla lisätyöntekijän pyrin paitsi laajentamaan henkilöstön määrää. Jokaisen palkatun on parannettava tiimiäni jollain tavalla. En ollenkaan etsi yhtä lahjakasta henkilöä kuin minä. Pikemminkin tarvitsen jonkun, joka on minua lahjakkaampi ainakin yhdellä tärkeällä alalla.

Pomo

Pahin pomo on se, joka tuntee olevansa uhattuna tiimistään. Tietoisesti tai ei, hän pelkää "parhaita" ja palkkaa siksi jatkuvasti ihmisiä, joita vastaan hän näyttää edulliselta.

Tällä lähestymistavalla pärjäät todennäköisesti suuressa yrityksessä. Epäilen vahvasti, että Dilbert-sarjakuvien Shaggy Boss perustui elämään.

Mutta pienten kehitysyritysten maailmassa asiat ovat täysin erilaisia. Jos olet pienen yrityksen perustaja tai ”pääguru”, yritä katsoa itseäsi huolellisesti, rehellisesti ja objektiivisesti. Jos olet yksi niistä ihmisistä, jotka tuntevat olonsa uhatuksi omien työntekijöidensä vuoksi, pysähdy ja mieti. Kunnes onnistut ratkaisemaan tämän ongelman, tehokkaan joukkueen rakentamisen mahdollisuudet ovat nolla.

Ohjelmoijien henkilöstö

Vakiosäännön todellinen tarkoitus ei ole silittää egoamme - se on muistuttaa meitä siitä, että emme pelkää etsiä parempia työntekijöitä. Silti on tarpeen selventää tarkemmin, mitä sana "paras" itse asiassa tarkoittaa.

Etsi ihmisiä, jotka ovat tietoisia itsestään

"Parhaat" työntekijät eivät koskaan lopeta oppimista.

Pidän yhtenä tärkeimmistä kriteereistä ehdokkaiden arvioinnissa sitä, mitä itse kutsun "ensimmäiseksi johdannaiseksi". Opiskeleeko tämä henkilö? Liikkuuko hän eteenpäin vai seisoko paikallaan? (Joitakin ajatuksiani tästä aiheesta on julkaistu blogini artikkelissa "Uralaskenta").

Ihmiset, jotka suhtautuvat vakavasti tulevaan menestykseensä, menestyvät todennäköisemmin. Tämä ajattelutapa on usein vahvin ominaisuus palkkauspäätöksissä.

Tämä ei tarkoita, että sinun pitäisi palkata vain ihmisiä, jotka haluavat menestyä. Kaikki ihmiset haluavat menestyä. Minun neuvoni on palkata ihmisiä, jotka ovat tosissaan jatkuvassa oppimisessa. Nämä ihmiset eivät tuhlaa aikaa yrittäessään vakuuttaa sinulle, kuinka paljon he tietävät. He keskittyvät menneisyyteen enemmän kuin tulevaisuuteen. Kun haastattelet heitä, he haastattelevat sinua ja yrittävät nähdä, mitä he voivat oppia sinulta.

Kuinka löytää tällainen henkilö?

Yksi selvä merkki on, että jatkuvaan oppimiseen sitoutuneet ihmiset tietävät hyvin, mitä he eivät tiedä. He tietävät heikkoutensa eivätkä pelkää puhua niistä.

Haastatteluissa hakijoita pyydetään usein kuvailemaan tärkeimpiä heikkouksiaan. Vaikka tämä kysymys on kauhean perinteinen, pidän siitä.

Valitettavasti monet ehdokkaat yrittävät välttää vastaamasta kysymykseen. He menevät kirjakauppaan ja ostavat kirjan haastattelusta. Kirja varoittaa minua, että kysyn heiltä tämän kysymyksen, ja ehdottaa "luovia" tapoja välttää vilpittömät vastaukset:

Joskus teen liikaa töitä.
Joskus huomioni yksityiskohtiin ärsyttää muita ryhmän jäseniä.

Kun pyydän ehdokasta puhumaan heikkouksistaan, odotan vastausta, joka on älykäs, vilpitön ja itsevarma. Kun kuulen ehdokkaan myöntävän heikkoutensa, se tekee vaikutuksen. Mutta jos ehdokas antaa välttelevän vastauksen suoraan kirjasta, alan miettimään seuraavaa ehdokasta.

Palkkaa kehittäjiä, älä ohjelmoijia

Pienessä yrityksessä "parhaat" ohjelmoijat ovat ne, jotka tekevät muutakin kuin ohjelmoinnin. Yritä palkata kehittäjiä, älä ohjelmoijia. Vaikka näitä sanoja käytetään usein vaihtokelpoisina, erotan ne toisistaan. Kyse on eroista yksinkertainen ohjelmointi ja osallistuminen tuotetiimiin. Lainaan artikkelia, jonka kirjoitin tästä aiheesta blogissani:

"Tässä artikkelissa "ohjelmoija" on henkilö, joka osallistuu yksinomaan uusien ominaisuuksien koodaamiseen ja [jos olet onnekas] virheiden korjaamiseen. Ohjelmoijat eivät kirjoita teknisiä tietoja. Ne eivät luo automaattisia testitapauksia. Ne eivät auta tukea automatisoidut järjestelmät kokoonpanot ovat ajan tasalla. Ne eivät auta asiakkaita ratkaisemaan teknisiä ongelmia. He eivät auta dokumenttien kirjoittamisessa, eivät osallistu testaukseen eivätkä edes lue koodia. He vain kirjoittavat uuden koodin. Pienen yrityksen ei pitäisi pitää sellaisia ihmisiä.

"Ohjelmoijien" (koodin kirjoittamiseen erikoistuneiden ihmisten) sijasta tarvitaan "kehittäjiä" (ihmisiä, jotka osallistuvat monin tavoin tuotteen menestykseen).

Mitä standardisääntö tarkoittaa? Mikä on se ominaisuus, jota on mitattava, jotta voidaan määrittää, onko ehdokas "paras"?

Tämän säännön ymmärretään yleensä koskevan vain koodaustaitoja. Mutta todella hyvät ohjelmoijat ovat älykkäitä. He ymmärtävät asioita, joita ei yleensä opeteta, ja he voivat työskennellä 10 kertaa tehokkaammin kuin keskimääräinen ohjelmoija. Tietysti olisi viisasta etsiä yksi näistä "kymmenkertaisista" persoonallisuuksista, etenkin suurista organisaatioista, joissa "puhtaiden" ohjelmoijien kaltaiset asiantuntijat ovat varsin sopivia. Mutta pieni yritys tarvitsee monipuolisuutta. Usein tiimin jäsenten on suoritettava useita toimintoja pelkän koodin kirjoittamisen lisäksi. Tällaisissa tapauksissa on erittäin tärkeää löytää paras kehittäjä, eikä tämä henkilö välttämättä ole paras ohjelmoija.

Joten vakiosääntö toimii melko hyvin, mutta yleisistä suosituksista on siirryttävä tarkempiin. Yhteenvetona edellisissä osissa käsitellystä on 10 kysymystä, jotka sinun tulee kysyä itseltäsi, kun harkitset ehdokasta kehittäjäpaikkaan:

Voiko tämä ehdokas tehdä jotain ryhmän hyväksi, mitä kukaan muu ei voi?
Onko hän jatkuvassa oppimisprosessissa?
Onko tämä ehdokas tietoinen heikkouksistaan ja voiko hän keskustella niistä rauhallisesti?
Kuinka monipuolinen tämä ehdokas on ja pystyy tekemään "mitä tahansa" tehdäkseen tuotteesta kaupallisen menestyksen?
Onko ehdokas yksi 10x ohjelmoijista?
Onko hänellä kandidaatin tutkinto hyvämaineisesta yliopistosta?
Jos hakijalla on tohtorintutkinto, onko muita viitteitä siitä, että hänellä on kykyä kehittää kaupallisia tuotteita?
Onko hakijalla kokemusta työskentelystä ryhmissä, jotka ovat kehittäneet kaupallisia tuotteita?
Voiko ehdokas antaa esimerkkejä hyvästä koodista?
Rakastaako ehdokas ohjelmointia tarpeeksi kirjoittaakseen koodia vapaa-ajallaan?

Myönteistä vastausta kaikkiin 10 kysymykseen ei vaadita. En aio edes määritellä, kuinka monta myönteistä vastausta vaaditaan ehdokkaan hyväksymiseen. Palkkaaminen on arpajaisia, ja jokainen kysymys voi toimia oppaana arvioitaessa ehdokkaan soveltuvuutta.

Viime kädessä mikä tahansa palkkauspäätös on harkinnanvarainen päätös, eikä takuita ole mahdollista. Kuitenkin kiinnittämällä huomiota näihin asioihin on todennäköisempää, että et tule katumaan päätöstäsi myöhemmin.

Kun ohjelmoija hankkii kokemusta, hän kehittää omia sääntöjään ja tyyliään. Samaan aikaan ei ole ehdottomasti välttämätöntä astua kaikkiin virheisiin itse. Seuraavien ohjeiden viisas noudattaminen auttaa sinua välttämään monia yleisiä virheitä. Tietenkin on mahdotonta antaa neuvoja kaikkiin tilanteisiin, koska monet eivät turhaan pidä ohjelmointia taiteena.

Päätavoitteena on saada helposti luettava, ehkä yksinkertaisemman rakenteen omaava ohjelma. Loppujen lopuksi kaikki ohjelmointitekniikat tähtäävät juuri tämän tavoitteen saavuttamiseen, koska se on ainoa tapa saavuttaa ohjelman luotettavuus ja muokkausten helppous.

· Ohjelman tulee koostua eristetyimmistä osista, jotka on kytketty toisiinsa vain rajapintojen kautta. Aliohjelman tai moduulin käyttöliittymä tulee erottaa selvästi sen toteutuksesta ja pääsyä tietoihin, jotka eivät ole sen käytölle välttämättömiä, tulisi rajoittaa.

· Jokainen suoritettu toiminto muotoillaan aliohjelmaksi. Aliohjelman koko voi olla erilainen, se riippuu tietystä toiminnosta, mutta on toivottavaa, että sen runko mahtuu yhdelle tai kahdelle näytölle: yhtä vaikeaa on ymmärtää ohjelmaa, joka sisältää useita valtavia toimintoja ja satoja alirutiineja. kukin useita rivejä. Jos jotakin lausesarjaa käytetään vähintään kahdesti, se on myös kirjoitettava aliohjelmaksi.

· Kaikki arvot, jotka aliohjelma vaihtaa kutsuvan ohjelman kanssa, on välitettävä sille parametrien kautta. Syöttöparametrit on suositeltavaa välittää vakioina. Yleensä parametriluettelo tallentaa ensin kaikki tuloparametrit ja sitten kaikki lähtöparametrit. Jos aliohjelma palauttaa yhden arvon, on parempi suunnitella se funktiona, jos useita - proseduurina.

· On hyödyllistä, että aliohjelmalla on valmiudet reagoida virheellisiin syöttöparametreihin ja kaatumiseen. Tämä voi olla joko viestin tulostamista tai mieluummin tuloslipun luomista. Tämä ominaisuus on analysoitava kutsuvassa ohjelmassa. Virheilmoituksen tulee olla informatiivinen ja kerro käyttäjälle, kuinka se korjataan. Jos esimerkiksi syötät virheellisen arvon, viestin on ilmoitettava kelvollinen alue.

· Vain aliohjelmassa käytetyt arvot tulee ilmoittaa paikallisina muuttujina aliohjelmassa. Tämä helpottaa ohjelman virheenkorjausta. Alirutiineissa ei ole suositeltavaa käyttää globaaleja muuttujia, koska niiden muutoksia on vaikea seurata.

· Muuttujien nimien tulee heijastaa niiden merkitystä. Oikein valitut nimet voivat tehdä ohjelmasta jonkin verran itsedokumentoivaa. Huonot nimet ovat päinvastoin ongelmien lähde. Lyhenteet heikentävät luettavuutta, ja voit usein unohtaa, kuinka sana tarkalleen lyhennettiin. Yleinen trendi on, että mitä suurempi muuttujan laajuus, sitä pidempi sen nimi. Tätä nimeä edeltää tyyppietuliite (yksi tai useampi kirjain, jolla muuttujan tyyppi voidaan määrittää). Päinvastoin, lyhyillä jaksolaskureilla on parempi käyttää yksikirjaimia nimiä, kuten i tai k.

· Sinun tulisi välttää numeroiden käyttöä ohjelmassa. Vakioilla on oltava merkitykselliset nimet, kuten const-ilmoitusosassa on määritelty. Symbolinen nimi tekee ohjelmasta ymmärrettävämmän, ja lisäksi, jos haluat muuttaa vakion arvoa, sinun tarvitsee muuttaa ohjelmaa vain yhdessä paikassa. Tämä neuvo ei tietenkään koske vakioita 0 ja 1.

· Jokaisen algoritmin fragmentin tallentamiseksi on käytettävä sopivimpia kielityökaluja. Esimerkiksi haarautuminen useisiin suuntiin kokonaisen muuttujan arvolla on kauniimmin kirjoitettu käyttämällä case-lausetta useiden if-merkkien sijaan. Jos haluat tarkastella taulukkoa, on parempi käyttää for-silmukkaa. Esimerkiksi goto-operaattoria käytetään hyvin harvoin. pakottaa poistumaan useista sisäkkäisistä silmukoista, ja useimmissa muissa tilanteissa on parempi käyttää muita kieliominaisuuksia, kuten katkaisu- tai poistumistoimintoja.

· Ohjelman on oltava "läpinäkyvä". Jos jokin toiminta voidaan ohjelmoida eri tavoilla, silloin etusijalle ei tulisi antaa pienikokoisinta tai edes tehokkainta, vaan sitä, joka on helpompi ymmärtää. Tämä on erityisen tärkeää, kun ohjelman kirjoittavat jotkut ja ylläpitävät sitä, mikä on laajalle levinnyt käytäntö. "Läpinäkymätön" ohjelmointi voi aiheuttaa valtavia kustannuksia virheiden etsimisestä virheenkorjauksen aikana.

· Älä sijoita montaa lausetta yhdelle riville. Kuten venäjäksi, Välimerkkien jälkeen tulee käyttää välilyöntejä:

· Sisäkkäisissä lohkoissa on oltava 3-4 merkin sisennys, Lisäksi saman sisäkkäisen tason lohkot on kohdistettava pystysuoraan. Muotoile teksti sarakkeiksi missä vain mahdollista.

· Merkitse pitkän yhdistetyn lauseen loppu.

· Käytä silmukoiden järjestämiseen sopivinta operaattoria. Toistosilmukkaa käytetään vain tapauksissa, joissa runko on ehdottomasti suoritettava vähintään kerran, esimerkiksi syötettä tarkistettaessa. silmukalle käytetään, jos toistojen määrä on tiedossa etukäteen ja parametri on järjestystyyppinen, kun silmukka- kaikissa muissa tapauksissa. Iteratiivisia silmukoita kirjoitettaessa (joissa silmukan rungossa muodostettujen muuttujien välisiä suhteita käytetään poistumisehtojen tarkistamiseen) on välttämätöntä tarjota hätäuloskäynti saavutettuaan ennalta määrätyn enimmäismäärä iteraatioita. Jotta silmukan lukeminen olisi helpompaa, meidän tulisi pyrkiä yhdistämään alustus, poistumistilan tarkistaminen ja lisääminen yhdessä paikassa.

Muutamia vinkkejä sivukonttorin lausuntojen kirjoittamiseen:

· Lyhyempi jos oksa on paremmin sijoitettu yläosaan, Muuten koko ohjausrakenne ei välttämättä mahdu näytölle, mikä tekee virheenkorjauksesta vaikeaa.

· Ei ole mitään järkeä käyttää tasa-arvotestausta totta tai väärä.

· Tarpeettomia kunnontarkastuksia tulee välttää.

· Jos if-käskyn ensimmäinen haara sisältää hallinnan siirron, muuta ei tarvitse käyttää:

jos i > 0 niin poistu; ( täällä minä<= 0 }

· On tarpeen säätää viestien tulostamisesta niissä ohjelman kohdissa, joissa ohjausta ei saa siirtää normaalin ohjelman toiminnan aikana.

Jokaisen ohjelman tulee alkaa kommentilla, joka sisältää ohjelmoijan etu- ja sukunimen, ohjelman tarkoituksen, versionumeron ja luomispäivämäärän.

Jokaisen aliohjelman tulee alkaa kommentilla, joka kuvaa lyhyesti aliohjelman tarkoitusta. Kommenttien tulee kuvata Mitä tekee koodin, ei Miten hän tekee sen. Seuraamalla koodia ohjelmoija näkee itse, kuinka se toimii.

Tyhjät rivit ovat erittäin hyödyllisiä lähdekoodissa osoittamaan, että ohjelma on jaettu osiin.

Jos lausunnon tai väiteryhmän tarkoitus on vaikea ymmärtää lähdekoodista, se tulee kommentoida lyhyesti. Sinun tulisi kuitenkin kuvata yksittäisiä lausuntoja mahdollisimman vähän. Yleensä tällaisten kommenttien tehokkuus on alhainen. Jos kommentti kuvaa jotain, joka on helppo nähdä koodista, se jopa vaikeuttaa koodin lukemista. Jos tällainen kommentti on edelleen tarpeen, sijoita se lohkon alkuun, jotta se ei riko ohjelman rakennetta.

Muuttujien ja aliohjelmien nimien tulee olla informatiivisia, ts. niin, että niitä katsomalla toinen ohjelmoija voisi arvata muuttujan tai aliohjelman tarkoituksen. Huonosti valittu nimi, joka hämmentää lukijaa, on vielä pahempi kuin epätietoinen nimi, kuten X tai A. Muuttujien nimien tulee koostua muista pienistä kirjaimista kuin kirjaimista, jotka alkavat nimen toisen tai sitä seuraavan sanan, esim. veroaste tai autojen määrä. Tavallisten nimien tulee alkaa isolla kirjaimella.

Objektien, ominaisuuksien ja metodien nimien tulee alkaa isoilla kirjaimilla.

Jokaisen komponentin nimen tulee alkaa etuliitteellä, joka koostuu kolmesta pienestä kirjaimesta, jotka osoittavat komponentin tyypin. Esimerkiksi lomakkeen nimi sisältää etuliitteen frm, syöttökentät – toim, painikkeet – btn jne. Etuliitteen perässä olevat kirjaimet kuvaavat komponentin tarkoitusta tai sisältöä. Esimerkiksi syöttökenttä edtLastName sisältää sukunimen.

Ohjelman lähdetekstin luettavuuden parantamiseksi on suositeltavaa kirjoittaa korkeintaan yksi lause riviä kohden, mikä johtuu ihmisen tekstinkäsityksen erityispiirteistä. Se helpottaa myös vaiheittaista virheenkorjausta symbolisissa debuggereissa.

Ei tarvitse pelätä ohjelman pidentymistä, sillä oikeat ohjelmat ovat jo niin pitkiä, että muutamat "ylimääräiset" sivut (tai jopa kymmenet sivut) eivät muuta kokonaistilannetta. Ymmärtämisen voitto enemmän kuin kattaa pituuden kasvun.

Kaksi lausetta rivillä ovat täysin hyväksyttäviä, jos toinen on alisteinen ensimmäiselle ja on ainoa alisteinen. Kahden tai useamman operaattorin käyttö rivissä ei ole vain hyväksyttävää, vaan myös toivottavaa, jos tämä mahdollistaa tietyn järjestelmän korostamisen paikallisessa operaattorisekvenssissä.

4.2. Ohjelman kehittämissäännöt

Kaikissa reaalivakioissa on oltava numeroita sekä desimaalipilkun vasemmalla että oikealla puolella, esimerkiksi 0,15 0,15:n sijaan.

Erityyppisille operandeille suoritettavia sekaaritmeettisia operaatioita tulee välttää aina kun mahdollista. Käytä sisäänrakennettuja tyyppimuunnosrutiineja.

Jos haluat muuntaa todellisen arvon merkkijonoksi ja takaisin, käytä toimenpiteitä Str() Ja Val(), ja kokonaislukuarvoille Object Pascal -kielessä - funktioita StrToInt() Ja IntToStr() vastaavasti.

Useita lausekkeita sisältävien lausekkeiden tulee sisältää sulkeita, jotta lausekkeet olisivat helpompia ymmärtää.

Poista tarpeeton koodi. Tämä pätee erityisesti lauseisiin silmukoiden sisällä, jotka suoritetaan toistuvasti. Esimerkiksi muuttujille tai taulukon elementeille ei tarvitse antaa arvoja ennen kuin muut operaattorit antavat arvoja niille. Mikä tahansa tällainen määritysoperaattori heikentää ohjelman tehokkuutta ja tekee koodista hankalamman.

Vältä globaalien muuttujien käyttöä. Jos useat rutiinit käyttävät samaa globaalia muuttujaa, voi syntyä vakavia virheenkorjausongelmia, koska on vaikeaa seurata, mikä rutiini muuttaa arvoaan. Useissa aliohjelmissa käytetyt muuttujat välitetään parhaiten parametreina, koska tämä tekee niiden käytöstä selvempää.

Päivitetty 30.1.2009

Jos olet mukana ohjelmoinnissa, riippumatta siitä, millä kielellä kirjoitat, on aina yleisiä ideoita ja käsitteitä, jotka niiden noudattaminen helpottavat työtäsi. Tässä on minun käsitykseni ohjelmoinnin perussäännöistä.

0. KORKEIN prioriteetti mitä tahansa ohjelmaa kehitettäessä on säilyttää kyky kehitystä Ja uudelleenkäyttö. Käytännössä vain koodin uudelleenkäyttö voi paljastaa virheitä ja parantaa rakennetta (esimerkiksi vanhan datan ulkoasua, mutta "uuden" tyyppiä). Hyvä ohjelma muuttuu pysyvästi.

Uudelleenkäytettävyyden pitäisi helpottaa sitä modulaarinen ohjelman rakenne (kapselointi ja rajapinnat). Esimerkiksi OOP:n tärkein etu on kyky:

a) turvallinen (vanha ei huonone) JO olemassa olevan koodin muuttaminen,

b) muokkausmahdollisuus ilman lähdekoodia.

Toisaalta datan ja menettelyjen yhdistäminen sen käsittelemiseksi heikentää väistämättä modulaarisuutta.

Tästä näkökulmasta tärkeimmät vaatimukset ohjelmointikielelle (tai tyylille, jota tulisi noudattaa) ovat

Hyvä luettavuus;

Suljetus (koodin eksplisiittisyys);

Nopea kokoaminen projektista kokonaisuutena, jotta näet heti muutoksen tulokset.

1. Yksittäisten toimintojen suunnittelu.

Pessimistinen näkökulma syöttömuuttujiin.

Bool-funktion tyyppi alkutuloksella FALSE .

Pakollinen arvonmääritys vapaapäivinä muuttujat heti ensimmäisellä funktion syöttämishetkellä.

On toivottavaa antaa lähtömuuttujat aivan lopussa ja työskennellä funktion rungossa "näiden muuttujien sisäisten kopioiden" kanssa, jotta kutsuva funktio saa tuloksena NIL:n, jos funktion rungossa tapahtuu virhe.

Poikkeuskäsittelyn laaja käyttö. Virheviestien tulee osoittaa selkeästi koodin sijainti, jossa vika tapahtui. Yleensä oletetaan, että poikkeusten käsittely on kysymys ulkoinen soittotoiminto. Modulaarisen rakenteen tukemiseksi on kuitenkin toivottavaa käsitellä virhe sisäisesti.

Kun hallitset muistia manuaalisesti, käytä aina NULL-esitäyttöä.

2. Muuttujien ja funktioiden nimeämiskäytännöt

Kaikki globaalit muuttujat alkavat kirjaimella "Gl".

Noudata vakiotoimintojen nimiä: Ilmainen, Luo, Init, Hanki, Aseta, On jne.

3. Menetelmät virheiden korjaamiseksi.

Virheen korjaaja.

Virheilmoitusvirran järjestäminen. Erilaiset virheet - vaarallisten virheiden tunnisteet.

Jäljitystiedostojen käyttäminen kaatumispaikan karkeasti paikallistamiseen.

Työkalut muistivuotojen valvontaan (manuaaliseen muistinhallintaan).

dll-versioiden täsmäytysmenetelmä: SizeOf (UsedRecord) tallentaminen kenttään tietueessa, joka välitetään dll-syötteeseen.

4. Ehkä helpoin tapa päättää, mikä käyttöliittymän tulisi olla, on "leikkiä" sillä: kirjoita esimerkkejä koodista, joka käyttää tätä moduulia, ennen kuin kirjoitat itse moduulin. Nämä "väärennetyt" esimerkit eivät häviä, kun lopetat moduulin kehittämisen. Voit yksinkertaisesti muuttaa nämä esimerkit esittelyohjelmiksi, esimerkeiksi dokumentaatiota varten tai käyttää moduulin testeinä. Keskeisenä periaatteena on kirjoittaa koodi ikään kuin moduuli olisi jo olemassa ja olettaa, että moduulilla on hyödyllisin käyttöliittymä.

Noin 5-7 vuotta sitten muotoilin säännöt, jotka ohjasivat minua työskennellessäni projekteissa (lähinnä yrityksen hallinnan automatisoinnissa), ja samassa hengessä yritin opettaa alaisiani (projektipäällikön roolissa). ). Tänään törmäsin näihin sääntöihin, luin ne ja vuodatin kyyneleen :) Ajan myötä näkemykset muuttuvat enkä ole enää täysin samaa mieltä joistakin säännöistä, mikä taas osoittaa, että tällaisten listojen tekeminen on kiittämätöntä työtä. Ja myös, kun olet aihealueen sisällä (muistutan sinua - yritysautomaatio), kohtaat päivittäisiä suunnitteluvirheitä, niin nämä säännöt ovat varsin järkeviä, ymmärrettäviä ja sovellettavia todellisissa tilanteissa. Ja ei-ohjelmoijan tai muun alan ohjelmoijan näkökulmasta jotkut säännöistä kuulostavat luultavasti ylimielisiltä, banaaleilta tai merkityksettömiltä. Joten en ole varma, että kaikki ymmärtävät, mutta julkaisen sen silti.

Ohjelmoijan ensimmäinen sääntö

Pointti: jaa suuri ongelma pieniin ja ratkaise ne yksitellen. Muista kuitenkin ongelma kokonaisuudessaan: kaikkien pienten päätösten on lopulta johdettava ratkaisuun suureen ongelmaan.

Ohjelmoijan toinen sääntö

Koskaan ei ole tarpeeksi rahaa tai aikaa tehdä kaikkea oikein. Mutta on aikaa ja rahaa tehdä se uudelleen myöhemmin.
(© Cheopsin laki)

Asia: tehtävän onnistunut suorittaminen ei riitä, siitä on poistuttava uusilla matkatavaroilla. Luo lopullisten ratkaisujen lisäksi myös menetelmiä + työkaluja - kaikki tämä on hyödyllistä tässä ja tulevissa projekteissa. Tee tämä, vaikka olisit määräajassa, koska jos et kasva, jäät jälkeen. Asiakas ja pomo eivät välitä siitä, sinä et.

Ohjelmoijan kolmas sääntö

Pointti: sinun on kyettävä lentää korkealle ja sukeltaa syvälle. Pystyt näkemään tehtävän kokonaisuutena ja pystyt analysoimaan sitä pienintä yksityiskohtaa myöten. Ilman järjestelmäajattelua ja analyyttistä mieltä ohjelmoinnissa ei ole mitään tekemistä.

Ohjelmoijan neljäs sääntö

Kokonaisuuksia ei ole niin paljon kuin niistä on näkemyksiä. Olennainen on ratkaisun perusta, sen tarkastelu on modifiointia tiettyä tehtävää varten.
(© ibigdan)

Merkitys: esimerkiksi "johtaja" ei ole henkilö, se on asema, joka voi olla henkilöllä (tai ei saa olla kenelläkään). Ja "Ivanov Pjotr Sidorovitš" ei ole henkilö, vaan sukunimi, nimi ja sukunimi, eli henkilön attribuutit. Ihminen on ruumis, elävä tai kuollut, jolla on joukko ominaisuuksia :) Yleensä tällaisia vivahteita ei oteta huomioon suunnittelussa, joten useimmat automatisoidut ohjausjärjestelmät ovat hyvin joustamattomia.

Ohjelmoijan viides sääntö

Vastaa kysymykseen "mikä tämä on?" - saat termin. Vastaa kysymykseen "miksi tämä on?" - ymmärrät merkityksen. Ehkä kysymys "miten tämä tehdään parhaiten?" Sinun ei tarvitse enää vastata.
(© ibigdan)

Ohjelmoinnin ydin on purkaa aihealue pieniksi paloiksi (analyysi) ja luoda se uudelleen tietokoneella toimivan mallin muodossa (synteesi).
(© ibigdan)

Merkitys: kaikki ohjelmointi rajoittuu vuorottelevaan analyysiin ja synteesiin. Lisäksi analyysi voi olla matemaattista, toiminnallista, objektiivista - mitä tahansa. Ja synteesin kielellä ei myöskään ole väliä. Tärkeää on vain näiden kahden vaiheen ymmärtäminen ja asiantunteva toteuttaminen.

Ohjelmoijan kuudes sääntö

Täydellisyyttä ei saavuteta, kun ei ole mitään lisättävää, vaan kun ei ole mitään poistettavaa.
(© tuntematon kirjoittaja)

Asia: jos kokonaisuus esiintyy useammin kuin kerran automatisoidussa järjestelmässä, olet tehnyt suunnittelun pahasti sekaisin. Esimerkki: "Ivanov Pjotr Sidorovitš, asema: lääkäri, työpaikka: urologian osasto." Sitten hän saa sydänkohtauksen ja hups! - kohde numero kaksi: "Pjotr Sidorovitš Ivanov, potilas, kardiologian osasto." Itse asiassa nämä ovat yksi ja sama henkilö, mutta järjestelmässä ne on listattu kahdeksi eri henkilöksi, jotka eivät liity toisiinsa. Lisäksi tämä on tyypillinen ja alkeellinen suunnitteluvirhe, mutta on paljon monimutkaisempiakin. Useimmat automatisoidut ohjausjärjestelmät koostuvat enemmän kuin kokonaan tällaisista virheistä.

Ohjelmoijan seitsemäs sääntö

Merkitys: useita merkityksiä. Älä kiirehdi iloitsemaan löytämästäsi ratkaisusta; ehkä se ottaa huomioon kokonaisuudet, mutta ei ota huomioon yhteyksiä. Vanhat ratkaisut eivät välttämättä toimi eri mittakaavan uusissa tehtävissä. Yleensä skaalausongelmista ei voi puhua.

Ohjelmoijan kahdeksas sääntö

Ohjelmistotuote, joka mallintaa tiettyä aihealuetta, ei voi fyysisesti olla tätä aihealuetta yksinkertaisempi.
(© ibigdan)

Seuraus: universaali ohjelmistotuote on useita suuruusluokkaa monimutkaisempi kuin erikoistunut, koska se kattaa joukon toisiinsa liittyviä aloja.
(© ibigdan)

Seuraus: ohjelmistotuote, joka pystyy tekemään kaiken, on äärettömän monimutkainen ja siksi periaatteessa mahdoton.
(© ibigdan)

Merkitys: valitettavasti kukaan ei jaa sinulle resursseja löytääksesi vastausta "pääkysymykseen elämästä, maailmankaikkeudesta ja lopulta". Etsi kompromisseja halutun ja mahdollisen välillä.

Ohjelmoijan yhdeksäs sääntö

Kun organisaation hallintaa automatisoidaan tietokoneella, on muistettava, että sen menestyksen pääavain on radikaali muutos perinteisessä organisaatiojohtamisen tekniikassa.
(© V.M. Glushkov)

Automaatio ei ole päämäärä sinänsä, vaan työkalu yrityksen toiminnan optimointiin. Jos automaatio ei optimoi, sitä ei tarvita.
(© ibigdan)

Asia: ei ole suurempaa idioottimaisuutta kuin paperityön automatisointi luomalla siitä tarkka kopio tietokoneella. Jotkut ohjelmoijat haluavat tehdä käyttöliittymästä "käyttäjälle tutun" niin paljon, että he piirtävät näytölle paperiarkkeja, asettavat niille viivoja ja merkkejä samassa muodossa kuin ne olivat paperilaskuissa jne. Markkinoinnin näkökulmasta tämä on perusteltua, mutta sillä ei ole mitään tekemistä automaation kanssa - ennen paperilla oli kaaosta, nyt tietokoneverkossa on kaaosta. Emme saa unohtaa, että dokumentti ei ole kokonaisuus, vaan "kirjanpitonäkymä" siitä, kokonaisuus on laskussa listattu tavara, tämä on todellinen esine, jonka kanssa toiminta on automatisoitava. Paperiasiakirjojen hallinta on vain yritys "automaatioon", joka tehtiin sata vuotta ennen sinua ja ennen tietokoneiden tuloa, sitä ei tarvitse automatisoida, se on vaihdettava. Tämä oli esimerkki, tällaisia hetkiä riittää millä tahansa alalla.