Coffee break #13: Perkara yang perlu diketahui oleh setiap pemula pengaturcaraan; 4 Cara untuk Memasukkan Pemikiran Reka Bentuk ke dalam Proses Pembangunan Anda

Perkara yang perlu diketahui oleh setiap pemula dalam pengaturcaraan

Sumber: Stackoverflow Sebagai pembangun, anda akan mendengar banyak teori berbeza tentang rupa kod. Sesetengah orang percaya bahawa lebih sedikit baris kod yang dimiliki oleh aplikasi, lebih mudah ia dibaca. Tetapi ini hanya sebahagiannya benar. Saya lebih suka menilai kualiti kod menggunakan kriteria berikut:

1. Kod tersebut hendaklah konsisten, bermaklumat dan didokumenkan dengan baik.
2. Kod harus menggunakan ciri moden yang stabil.
3. Kod itu tidak sepatutnya rumit atau rosak.

Jika anda memutuskan untuk mengurangkan bilangan baris kod dengan mengorbankan salah satu kriteria di atas, ini akan menjadi masalah. Jangan buat begitu.

Membaca kod orang lain adalah sukar

Sesungguhnya, nisbah masa yang dihabiskan untuk membaca dan menulis kod adalah lebih daripada 10 berbanding 1. Tetapi anda tidak boleh melakukannya tanpa membaca kod orang lain. Anda perlu membaca kod orang lain. Dan lebih cepat anda meningkatkan kemahiran anda, lebih baik. Cuba pelajari kod orang lain menggunakan repositori GitHub terbuka. Anda boleh berlatih pada bila-bila masa: cuma cari projek yang sesuai dengan anda dan teliti setiap baris. Satu lagi cara untuk meningkatkan keupayaan anda membaca kod orang lain ialah anda mula menyalin gaya. Apabila anda menulis kod dalam gaya orang lain, ia bukan sahaja meningkatkan kemahiran membaca anda, tetapi juga menjadikan kod lebih biasa kepada anda. Mencubanya.

Anda tidak akan menulis kod "sempurna".

Saya adalah pembangun solo selama empat tahun sebelum saya mula bekerja dalam satu pasukan. Untuk kebanyakan masa ini, saya percaya bahawa mana-mana pengaturcara berpengalaman menulis kod yang sempurna. Pada pendapat saya, belajar menulis kod yang sempurna hanya memerlukan masa dan usaha. Tetapi apabila saya menyertai pasukan, ia menjadi jelas bahawa tiada siapa yang menulis kod "sempurna". Benar, kod yang akhirnya disertakan dalam sistem hampir selalu "sempurna". Mengapa ini berlaku? Ini semua tentang analisis kod. Saya bekerja dengan pasukan jurutera yang benar-benar cemerlang. Ini adalah antara pengaturcara yang paling cekap dan yakin yang boleh diambil oleh wang. Tetapi setiap daripada mereka (termasuk saya) akan mengalami serangan panik sebenar jika sesiapa pernah mencadangkan memasukkan kod yang belum diuji dalam aplikasi. Walaupun anda fikir anda adalah Bill Gates seterusnya, anda akan melakukan kesilapan. Saya tidak bercakap tentang kesilapan logik, saya bercakap tentang kesilapan menaip, aksara yang hilang. Perkara yang kadang-kadang otak anda tidak dapat menangkap. Perkara yang hanya boleh diperhatikan dengan mata yang segar. Berusaha untuk bekerja dengan orang yang prihatin terhadap perincian dan bersedia untuk mengkritik kerja anda. Ia akan menjadi sukar untuk menerima kritikan pada mulanya, tetapi ia adalah satu-satunya cara yang boleh dipercayai untuk meningkatkan kualiti kod anda. Lakukan yang terbaik untuk tidak bersikap defensif semasa menyemak kod, dan jangan sekali-kali menerima kritikan secara peribadi. Anda bukan kod anda.

Anda tidak sepatutnya menulis kod 8 jam sehari

Tiada siapa yang boleh memberitahu anda dengan tepat berapa banyak masa sehari yang mereka habiskan untuk menulis kod. Tetapi pada hakikatnya, beberapa orang menulis kod lebih daripada 4 jam sehari. Orang yang tidak bersetuju dengan ini adalah sama ada pengecualian kepada peraturan atau bekerja untuk syarikat yang melayan kakitangan mereka dengan buruk. Pengaturcaraan adalah kerja yang sengit dan meletihkan mental. Adalah salah sama sekali untuk berfikir bahawa seseorang akan menulis kod 8 jam sehari, 5 hari seminggu. Akan ada masa yang jarang berlaku apabila anda perlu memenuhi tarikh akhir, tetapi apabila saya katakan jarang, maksud saya hampir tidak pernah. Jangan biarkan kerja membebankan anda dan memaksa anda bekerja lebih masa. Saya tidak mencadangkan anda hanya bekerja empat jam sehari. Baki empat jam biasanya paling baik dibelanjakan untuk perkara seperti:

• mempelajari alatan, fungsi, aplikasi baharu;
• membincangkan proses kerja dengan rakan sekerja;
• membantu rakan sekerja yang menghadapi masalah di tempat kerja;
• perancangan tugas;
• analisis kod;
• mesyuarat/mesyuarat perniagaan.

Saya juga sangat mengesyorkan mengambil rehat biasa sepanjang hari dan bersenam (sekurang-kurangnya sedikit). Kesan positif senaman telah lama terbukti.

4 Cara untuk Memasukkan Pemikiran Reka Bentuk ke dalam Proses Pembangunan Anda

Sumber Tech Beacon Untuk mencipta produk yang memenuhi keperluan pelanggan anda, anda perlu mempertimbangkan perkara yang mereka mahukan. Jika anda telah menulis apl dengan navigasi yang mengelirukan atau antara muka pemuatan yang tidak perlu panjang, sediakan diri anda untuk kegagalan masa hadapan. Sebagai seorang pengaturcara, anda mungkin perlu mendalami reka bentuk produk yang sedang diusahakan oleh pasukan anda. Kerjasama seperti ini sangat berguna kerana setiap orang menyedari perkara yang mungkin tidak diperhatikan oleh orang lain. Saya menawarkan anda 4 petua tentang cara pembangun dan pereka boleh bekerjasama.

1. Terlibat sejak awal lagi

Jangan menganggap reka bentuk sentiasa didahulukan dan pembangunan diutamakan. Ini mungkin benar, tetapi ini tidak bermakna pembangun tidak boleh terlibat dalam proses reka bentuk. Pengaturcara dapat memberikan maklumat teknikal penting tentang bagaimana projek itu boleh dilaksanakan, manakala pereka bentuk lebih memahami keinginan pengguna. Adalah lebih baik untuk mengetahui seawal mungkin fungsi mana yang secara teknikalnya mustahil atau tidak memenuhi keperluan pengguna. Jika pereka bentuk dan pembangun bekerjasama, masalah boleh ditemui dan diselesaikan dengan segera dan bukannya selepas reka bentuk diluluskan. Banyak syarikat mengambil pendekatan kolaboratif untuk pembangunan perisian. Ini bermakna ahli pasukan bukan sahaja bertanggungjawab untuk peringkat atau sekeping kod mereka sendiri, tetapi mengambil tanggungjawab kolektif untuk segala-galanya daripada reka bentuk hingga ujian.

2. Ketahui proses UX

Mereka yang tidak biasa dengan UX (pengalaman pengguna) mungkin tidak faham mengapa pasukan menukar reka bentuk berulang kali untuk butiran yang kelihatan kecil. Setiap langkah dalam proses UX berlaku untuk satu sebab: untuk memberikan pengalaman terbaik yang mungkin kepada pengguna. Oleh itu, adalah penting untuk memberi perhatian kepada mencipta proses UX dari awal lagi. Ia mungkin termasuk:

• menyelidik tujuan projek;
• mencipta wireframe - reka bentuk mudah yang membolehkan anda menentukan ciri utama produk;
• menambah butiran yang lebih halus pada reka bentuk projek, seperti antara muka pengguna;
• ujian reka bentuk pengguna. Ini mungkin peringkat paling penting dalam pembangunan UX. Ini memberikan maklumat berharga tentang produk sebelum anda meluangkan masa untuk membangunkannya;
• Lelaran: Menggunakan analisis keputusan ujian, ulang reka bentuk untuk meningkatkan pengalaman pengguna.

Pasukan mengulangi langkah reka bentuk dan ujian beberapa kali sehingga tiada perubahan yang tinggal, atau mengikut masa yang dibenarkan. Ini biasanya bermakna anda akan mempunyai berbilang versi reka bentuk.

3. Ikuti perkembangan reka bentuk

Amat teruk apabila pereka bentuk mencipta projek tanpa berunding dengan pembangun. Ia tidak produktif. Adalah penting untuk DevOps menetapkan peraturan supaya pembangun mempunyai akses kepada reka bentuk pelan tindakan dalam format yang mudah diakses seperti PNG atau PDF. Kerjasama yang berkesan antara pembangun dan pereka bentuk adalah penting untuk kejayaan pelaksanaan aplikasi. Elakkan menyerahkan reka bentuk siap secara membuta tuli pada semua kos. Adalah lebih baik untuk membetulkan kesilapan pada permulaan daripada pada akhirnya.

4. Bersetuju pada peringkat mana projek itu akan ditunjukkan kepada anda

Apabila pembangun diminta untuk mencipta versi minimum produk (MVP), mereka perlu mengetahui keperluan untuk versi akhir dari awal lagi. Ini adalah perlu untuk mengelakkan masalah dengan jangkaan yang tidak wajar. Pereka bentuk mesti menunjukkan kedua-dua versi reka bentuk kepada pembangun: kedua-dua MVP dan versi akhir. Ini akan membantu melaksanakan MVP, dengan mengambil kira perkara yang pelanggan jangkakan untuk melihat dalam versi akhir. Apabila pereka bentuk dan pembangun bekerjasama, mereka mendapat banyak faedah. Setiap daripada mereka mempunyai pengetahuan yang boleh digunakan untuk pengalaman yang lain. Pembangun boleh memberikan pandangan yang berharga tentang ciri yang tidak boleh dilaksanakan dalam reka bentuk. Sebaliknya, kerjasama dengan pengaturcara akan melegakan pereka daripada keperluan untuk membuat semula projek, yang, sewajarnya, akan menjimatkan masa untuk seluruh pasukan.