4. Pembangunan Perisian

4.1 Memilih bahasa pemprograman

Sistem yang sedang dibina mestilah ditulis dalam salah satu daripada bahasa berikut. Pengecualian dibenarkan apabila standard industri melencong daripada senarai berikut atau terdapat kebersandaran yang memerlukan bahasa khusus untuk digunakan. (Cth. Python untuk analitis data.)

4.1.1 Bahagian belakang

Go
Java
Python
Typescript

4.2 Rangka Kerja Bahagian Depan Web

Apabila pelayar bekerja dengan HTML, js dan css, bahagian ini hanya digunakan apabila melakukan Aplikasi Halaman Tunggal (SPA). Jika melakukan penjanaan bahagian pelayan , bahagian ini akan di langkau.

VueJS ialah rangka kerja pilihan. Sila bincangkan dengan pemilik projek jika terdapat keperluan untuk melencong daripadanya.

4.3 Panduan gaya

Mempunyai gaya yang konsisten dalam organisasi memastikan bahawa pembangun yang berbeza yang masuk projek akan mempunyai masa yang lebih mudah untuk mengambilnya, serta mengurangkan beban kognitif pada pembangun.

Apabila gaya kod menjadi perkara pilihan, kami memilih untuk terlalu bersandar pada gaya kod yang dibangunkan oleh komuniti bahasa dan rangka kerja yang berbeza.

nda juga mungkin ingin mengkaji semula panduan MAMPU untuk gaya pengekodan yang boleh didapati di sini.

4.3.1 Go

Pemformatan kod dalam go dikendalikan oleh arahan binaan dalaman go fmt.

Selain daripada itu, Effective Go memberikan amalan terbaik tentang idiomatik penulisan kod go.

4.4 Pembinaan dengan memikirkan kebolehcapaian

Perkhidmatan kerajaan mestilah boleh dicapai untuk semua orang. Ini merangkumi sesiapa sahaja yang mempunyai ketidakupayaan visual, pendengaran, pertuturan, motor atau pembelajaran. Ini juga merangkumi sesiapa sahaja dengan yang mempunyai ketidakupayaan sementara atau keadaan, seperti individu yang mengalami patah tangan atau yang bekerja dalam persekitaran bising.

Pembinaan perkhidmatan dengan memikirkan kebolehcapaian bukan sahaja membolehkan sesiapa dengan keperluan akses menggunakan perkhidmatan anda, tetapi juga menambah baik perkhidmatan untuk orang lain. Masalah kebolehcapaian dengan tapak web boleh menjadi sesuatu yang menjejaskan semua orang, bukan sahaja kepada individu yang hanya boleh mengakses web dengan papan kekunci atau pembaca skrin.

Jika perkhidmatan anda tidak boleh dicapai oleh semua orang, mungkin akan terd implikasi kos juga. Pengguna yang tidak boleh mengakses perkhidmatan anda dalam talian akan cuba berinteraksi dengan perkhidmatan tersebut dengan cara yang lebih mahal untuk organisasi anda. (cth. melalui telefon atau secara bersemuka).

4.4.1 Cara untuk menjadikan perkhidmatan anda boleh dicapai

Pertimbangkan kebolehcapaian dari mula

Anda tidak boleh mencapai kebolehcapaian dengan menambah beberapa sentuhan akhir – ia mesti dipertimbangkan di semua peringkat projek. Anda perlu menyemak reka bentuk jika terdapat kemungkinan masalah, menulis dan menjalankan ujian sepanjang pembangunan, dan menguji perkhidmatan dengan memikirkan kebolehcapaian.

Memahami bahawa bukan semua orang membaca kandungan dengan cara yang sama

Asepintas lalu melalui tajuk dan perenggan untuk mencari kandungan yang mereka inginkan.

Pengguna yang tidak celek juga boleh membaca sepintas lalu daripada membaca satu halaman. Pembaca skrin boleh mengumumkan kandungan melalui jenis elemen, seperti tajuk, perenggan atau pautan. Sebagai contoh, jika pengguna pembaca skrin menjangkakan halaman mengandungi data dalam elemen jadual, seperti jadual masa kereta api, mereka mungkin mula membaca semua jadual pada halaman.

Inilah sebabnya penanda semantik dan struktur tajuk yang baik adalah penting apabila mewujudkan perkhidmatan yang boleh diakses.

4.5 Mendokumenkan keputusan

Anda perlu merekodkan keputusan yang menjejaskan reka bentuk perkhidmatan anda, bagi memelihara konteks pilihan anda.

Apabila projek yang pintar semakin matang, ia kadang kala sukar untuk terus menjejaki sebab di sebalik keputusan yang dilakukan. Ini biasanya betul apabila orang baharu menyertai projek apabila tiada lagi mereka yang terlibat pada peringkat awal.

Ia penting untuk mengekalkan sebab tersebut supaya pasukan semasa boleh memasukkannya sebagai konteks apabila membuat keputusan mereka sendiri tentang perubahan yang mereka perlu lakukan. Sebagai contoh, memahami sama ada pilihan tertentu dilakukan demi kesesuaian dan oleh itu boleh diubah dengan impak yang kecil, atau sama ada terdapat sebab luar di sebalik keputusan yang perlu difaktorkan.

4.5.1 Cara untuk mendokumenkan keputusan

Keputusan reka bentuk perlu disimpan dalam kawalan versi supaya terdapat rekod tentang perkara yang berubah, siapa, dan bila. Keputusan yang menjejaskan aplikasi khusus perlu berada dalam repositori kod aplikasi tersebut. Anda juga mungkin ingin menyimpan keputusan berskala lebih besar dalam repositori dokumentasi pusat.

Format yang disyorkan ialah Rekod Keputusan Reka Bentuk, yang dicadangkan oleh Michael Nygard dalam hantaran blog dan sejak digunakan secara meluas. Hantaran tersebut menjelaskan format secara penuh, tetapi sebagai ringkasan, ia terdiri daripada seksyen berikut:

Tajuk

Penerangan tentang keputusan (bukan masalahnya)

Status

cth Dicadangkan, Diterima, Digantikan

Konteks

Fakta di sebalik keperluan untuk membuat keputusan

Keputusan

Perkara yang diputuskan oleh pasukan untuk dilakukan

Akibat

Akibat positif dan negatif tentang keputusan