Veiklas programmatūras izstrāde nav saistīta tikai ar veikliem principiem un praksi. Lai veiksmīgi izdotu programmatūru, kas pozitīvi ietekmē galalietotājus, risina tehnisko parādu un uzticami izvieto, izstrādes komandai jāņem vērā arī viņu veiklības vadīšanas kodēšanas prakse un arhitektūras standarti.
Vēl svarīgāks apsvērums ir tehnoloģiju organizācijām. Lai arī cik grūti ir izstrādāt programmatūru, ir vēl grūtāk regulāri ieviest uzlabojumus un jauninājumus ilgākā laika posmā. Devops CI / CD un IAC (infrastruktūra kā kods) prakse daļēji pievēršas vienam kritiskajam faktoram, jo automatizācija nodrošina uzticamus un atkārtojamus veidus, kā izvietot lietojumprogrammas. Pievienojiet nepārtrauktā testēšanā, un izstrādes komandām ir veids, kā apstiprināt, ka koda izmaiņas neietekmē esošo funkcionalitāti.
Tomēr, lietojumprogrammām novecojot, sākotnējie izstrādātāji pāriet uz citiem projektiem un dažreiz citiem uzņēmumiem. Kad komandai pievienojas jauni izstrādātāji, viņiem jāapgūst programmatūras arhitektūra un jāsaprot kods, pirms viņi to var droši un efektīvi mainīt.
Turklāt izstrādātāji, kuri veido lietojumprogrammas, bieži vēlas izstrādāt jaunas. Varētu justies ērti un droši palikt piesaistītiem jūsu izstrādātajām lietojumprogrammām, taču piesaistīšana kodam nav noderīga ne jūsu karjerai, ne organizācijai.
Labākais veids, kā pāriet uz jaunām un aizraujošām programmatūras izstrādes iniciatīvām, ir padarīt jūsu arhitektūru, lietojumprogrammu un kodu viegli atbalstāmu citiem izstrādātājiem. Veiklām komandām un izstrādātājiem jāizveido un jāievieš kodēšanas prakse, kas uztur nepārtrauktu programmatūras attīstību.
1. Neizgudrojiet riteni no jauna
Pirmais kodēšanas noteikums: nekodējiet kaut ko tādu, kas nav jākodē! Kā?
- Apsveriet iespēju uzdot jautājumus par prasībām. Kāpēc funkcija ir svarīga? Kas gūst labumu? Precīzāk, izpētiet nekodēšanas iespējas, lai atrisinātu problēmu. Dažreiz labākais risinājums vispār nav risinājums.
- Vai kāds no jūsu organizācijas jau ir kodējis līdzīgu risinājumu? Varbūt ir kāds mikropakalpojums, kam nepieciešams tikai uzlabojums, vai programmatūras bibliotēka, kurai nepieciešama neliela jaunināšana? Pirms kodējat kaut ko jaunu, noteikti apskatiet savas organizācijas kodu bāzi.
- Vai ir trešo pušu risinājumi, ieskaitot pieejamus SaaS rīkus vai atvērtā pirmkoda iespējas, kas atbilst minimālajām prasībām?
- Vai esat apskatījis atvērtas kodēšanas krātuves, piemēram, GitHub, lai iegūtu kodu piemērus un fragmentus, kas atbilst jūsu organizācijas atbilstības prasībām?
2. Apsveriet zema koda izstrādes iespējas
Ja jums tomēr ir nepieciešams kodēt risinājumu, iespējams, alternatīvas zema koda platformas var efektīvāk attīstīt iespējas, salīdzinot ar kodēšanu attīstības valodās, piemēram, Java, .Net, PHP un JavaScript.
Zema koda platformas, piemēram, Caspio, Quick Base, Appian, OutSystems un Vantiq, visi nodrošina rīkus, lai izstrādātu lietojumprogrammas ar nelielu kodu un dažreiz pat bez kodēšanas vispār. Katra platforma specializējas dažādās iespējās un tādējādi ir piemērota noteiktai lietojumu klasei. Piemēram, Kaspio ļauj ērti iegult veidlapas un darbplūsmas vietnēs. Quick Base ir spēcīgas darbplūsmas un automatizācijas iespējas, un Vantiq notikumu virzītā arhitektūra ir piemērota IoT un citām reāllaika datu lietojumprogrammām.
Reizēm ir nepieciešama kodēšana, taču izstrādātājiem vajadzētu arī pārzināt vienu vai vairākas zema koda izstrādes iespējas un ņemt vērā tos atbilstošos lietošanas gadījumos.
3. Automatizēt testēšanu
Papildus prasībām atbilstoša koda ierakstīšanai viena no vissvarīgākajām lietām, kas izstrādātājiem jādara, ir tā pārbaude. Testu vadīta izstrādes prakse un automatizētie testēšanas rīki ir nobrieduši, un izstrādes komandām ir jāiekļauj vienības, regresijas, veiktspējas un drošības pārbaude kā daļa no viņu veiklajām aplēsēm.
Papildus testiem, lai pārbaudītu būvējumus un laidienus, šie testi palīdz arī padarīt kodu atbalstāmāku. Testi ir dokumentācija, kas noslēdz līgumu par koda uzvedību. Kad jaunie izstrādātāji pievienojas komandām un netīši ievieš sliktas izmaiņas, nepārtraukta testēšana aptur būvējumu un sniedz izstrādātājam nozīmīgu atgriezenisko saiti, lai ātri risinātu problēmu.
4. Ārējus visus konfigurācijas parametrus
Izstrādātājiem nevajadzētu būt attaisnojumam, ka kodā vienmēr ir jāievada cietā koda sistēmas līmeņa iestatījumi, lietotājvārdi un paroles vai cita konfigurācijas informācija. Esmu redzējis, ka izstrādātāji izmanto īsceļus, izstrādājot prototipus, kas nonāk ražošanas vidē. Mūsdienu arhitektūrā to nekad nevajadzētu darīt. Cietā kodēšana nav tehnisks parāds, bet slinka, bezatbildīga kodēšanas prakse, kurai var būt būtiskas sekas. Ja kods kļūst nejauši pieejams, tas rada drošības ievainojamību, ja tiek pakļauti galapunkti vai piekļuves akreditācijas dati.
Pārejot vienu soli tālāk, kad tiek strādāts ar mantoto kodu, tehniski parādu prioritātei vajadzētu būt visu grūti kodēto konfigurāciju un parametru risināšanai.
5. Ievērojiet nosaukšanas konvencijas un iekļaujiet komentārus, lai kods būtu salasāms
Reiz es strādāju ar neticami talantīgu izstrādātāju, kurš labi nezināja angļu valodu un nebija labākais mašīnrakstītājs. Viņš momentānos objektus ar tādiem nosaukumiem kā a, b, un c un pēc tam izveidojiet vietējos mainīgos ar nosaukumu zz, yy, xx. Viņš apņēmās to iztīrīt pirms atbrīvošanas, bet reti sekoja līdzi.
Lai atzītu, ka šī ir briesmīga prakse, jums nevajadzētu būt iestatītam pāra vai pūļa programmēšanai.
Komandām jāpieņem nosaukumdošanas metodes, piemēram, Google JavaScript stila rokasgrāmata un Java stila rokasgrāmata, un jāapņemas komentēt kodu vismaz moduļu līmenī un ideālā gadījumā klases līmenī. Turklāt organizācijām vajadzētu apsvērt iespēju izmantot statisko kodu analīzes rīkus, kas sniedz atgriezenisko saiti izstrādātājiem, kad kodam ir nepieciešams pārstrukturēt struktūras un lasāmības faktorus.
6. Bieži pārbaudiet kodu versiju kontrolē
Ja jūs katru dienu vai biežāk nepārbaudāt kodu versiju kontrolē, tas var radīt konfliktus un citus blokus, kas ietekmē komandu. Viena neliela kļūda var izraisīt veiklu komandu nokavēšanu no sprinta saistībām vai radīt papildu darbu atkarību atrisināšanai.
Komandām jāvienojas par koda, kas nav gatavs ražošanai, pārbaudes kārtību. Parastās pieejas ietver iezīmju karodziņus un Git atzarojumus.
7. Izvairieties no varoņu un sarežģītību kodēšanas
Lielākā daļa man zināmo izstrādātāju kļuva par profesionāliem programmatūras inženieriem, jo viņiem patīk risināt kodēšanas problēmas. Kodēšana ir māksla, zinātne un amatniecība, un labāki izstrādātāji meklē pārdomas rosinošus kodēšanas uzdevumus un elegantu ieviešanu.
Izņemot pelēko līniju starp izaicinošu uzņēmējdarbības un tehnisko uzdevumu risināšanu un kodēšanas varonību, kas nākamajiem izstrādātājiem atstāj grūti saprotamu un sarežģīti uzturamu kodu.
Tiem no mums, kas kādu laiku ir kodējuši, mēs atceramies Perla vienas līnijpārvadātāju ērtības vai ligzdotu veidņu izmantošanu C ++. Dažreiz ir pamatoti iemesli izmantot šīs pieejas, taču, ja jauna izstrādātāju grupa nesaprot šīs metodes, ir grūtāk mainīt kodu. Dažreiz vienkāršāka, bet mazāk eleganta kodēšanas prakse ir labāka.
Braukšanas veiklība veiklās programmatūras izstrādē
Rituāli, kas iekļauti pilnīgā un veiklā attīstībā, tostarp saistības, standups, sprinta pārskati un retrospektīvas, tagad ir pārbaudīta prakse, kas ļauj komandas sadarbībai un sekmīgai ieviešanai. Bet, lai ilgu laiku parādītu veiklību, izstrādātājiem jāuzņemas atbildība un kodēšanas prakse, kas nodrošina ilgāku laiku atbalstu un viņu izstrādātā koda paplašināmību.
Izstrādes komandām kritiski jāaplūko sava kodēšanas prakse. Tas nav pietiekami labs, lai šodien demonstrētu un atbrīvotu; tas ir arī svarīgi, lai citi varētu viegli uzturēt lietojumprogrammu un kodu.
