Rehat kopi #13: Apa yang harus diketahui oleh setiap pemula dalam pemrograman; 4 Cara Memasukkan Design Thinking ke dalam Proses Pengembangan Anda

Apa yang harus diketahui oleh setiap pemula dalam pemrograman

Sumber: Stackoverflow Sebagai pengembang, Anda akan mendengar banyak teori berbeda tentang tampilan kode. Beberapa orang percaya bahwa semakin sedikit baris kode yang dimiliki suatu aplikasi, semakin mudah untuk dibaca. Namun hal ini hanya sebagian yang benar. Saya lebih suka mengevaluasi kualitas kode menggunakan kriteria berikut:

1. Kode tersebut harus konsisten, informatif, dan didokumentasikan dengan baik.
2. Kode harus menggunakan fitur yang stabil dan modern.
3. Kode tidak boleh terlalu rumit atau rusak.

Jika Anda memutuskan untuk mengurangi jumlah baris kode karena salah satu kriteria di atas, ini akan menjadi masalah. Jangan lakukan itu.

Membaca kode orang lain itu sulit

Memang benar, rasio waktu yang dihabiskan untuk membaca dan menulis kode lebih dari 10 banding 1. Namun Anda tidak dapat melakukannya tanpa membaca kode orang lain. Anda harus membaca kode orang lain. Dan semakin cepat Anda meningkatkan keterampilan Anda, semakin baik. Coba pelajari kode orang lain menggunakan repositori GitHub terbuka. Anda dapat berlatih kapan saja: temukan saja proyek yang cocok untuk Anda dan selidiki setiap lini. Cara lain untuk meningkatkan kemampuan Anda membaca kode orang lain adalah dengan mulai menyalin gayanya. Saat Anda menulis kode dengan gaya orang lain, hal ini tidak hanya meningkatkan keterampilan membaca Anda, tetapi juga membuat kode tersebut lebih familier bagi Anda. Cobalah.

Anda tidak akan pernah menulis kode yang "sempurna".

Saya adalah pengembang solo selama empat tahun sebelum saya mulai bekerja dalam tim. Selama ini, saya percaya bahwa setiap programmer berpengalaman menulis kode yang sempurna. Menurut saya, belajar menulis kode yang sempurna hanyalah masalah waktu dan tenaga. Namun ketika saya bergabung dengan tim, menjadi jelas bahwa tidak ada yang menulis kode yang “sempurna”. Benar, kode yang pada akhirnya dimasukkan ke dalam sistem hampir selalu “sempurna”. Kenapa ini terjadi? Ini semua tentang analisis kode. Saya bekerja dengan tim insinyur yang benar-benar brilian. Ini adalah beberapa programmer yang paling kompeten dan percaya diri yang dapat disewa dengan uang. Tetapi masing-masing dari mereka (termasuk saya) akan mengalami serangan panik jika ada yang menyarankan untuk memasukkan kode yang belum diuji ke dalam aplikasi. Bahkan jika Anda mengira Anda adalah Bill Gates berikutnya, Anda tetap melakukan kesalahan. Saya bahkan tidak berbicara tentang kesalahan logika, saya berbicara tentang kesalahan ketik, karakter yang hilang. Hal-hal yang terkadang tidak ditangkap oleh otak Anda. Hal-hal yang hanya bisa dilihat dengan mata segar. Berusahalah untuk bekerja dengan orang-orang yang memperhatikan detail dan bersedia mengkritik pekerjaan Anda. Sulit menerima kritik pada awalnya, tetapi ini adalah satu-satunya cara yang dapat diandalkan untuk meningkatkan kualitas kode Anda. Lakukan yang terbaik untuk tidak bersikap defensif saat meninjau kode, dan jangan pernah menganggap remeh kritik. Anda bukan kode Anda.

Anda tidak boleh menulis kode 8 jam sehari

Tidak ada yang bisa memberi tahu Anda dengan tepat berapa banyak waktu sehari yang mereka habiskan untuk menulis kode. Namun kenyataannya, hanya sedikit orang yang menulis kode lebih dari 4 jam sehari. Orang yang tidak setuju dengan hal ini mungkin merupakan pengecualian terhadap aturan tersebut atau bekerja di perusahaan yang memperlakukan stafnya dengan buruk. Pemrograman adalah pekerjaan yang intens dan menguras mental. Sangat salah jika berpikir seseorang akan menulis kode 8 jam sehari, 5 hari seminggu. Jarang sekali Anda harus memenuhi tenggat waktu, namun jika saya katakan jarang, maksud saya hampir tidak pernah. Jangan biarkan pekerjaan membebani Anda dan memaksa Anda untuk bekerja lembur. Saya tidak menyarankan Anda hanya bekerja empat jam sehari. Empat jam sisanya biasanya paling baik dihabiskan untuk hal-hal seperti:

• mempelajari alat, fungsi, aplikasi baru;
• mendiskusikan proses kerja dengan rekan kerja;
• membantu rekan kerja yang mengalami kesulitan dalam pekerjaan;
• perencanaan tugas;
• analisis kode;
• pertemuan/pertemuan bisnis.

Saya juga sangat menyarankan untuk beristirahat secara teratur sepanjang hari dan berolahraga (setidaknya sedikit). Dampak positif olahraga sudah lama terbukti.

4 Cara Memasukkan Design Thinking ke dalam Proses Pengembangan Anda

Sumber Tech Beacon Untuk menciptakan produk yang memenuhi kebutuhan pelanggan, Anda harus mempertimbangkan apa yang mereka inginkan. Jika Anda telah menulis aplikasi dengan navigasi yang membingungkan atau antarmuka pemuatan yang terlalu lama, persiapkan diri Anda untuk kegagalan di masa mendatang. Sebagai seorang programmer, Anda mungkin harus mempelajari lebih dalam desain produk yang sedang dikerjakan tim Anda. Kolaborasi semacam ini sangat berguna karena masing-masing orang memperhatikan hal-hal yang mungkin tidak diperhatikan oleh orang lain. Saya menawarkan 4 tips tentang bagaimana seorang pengembang dan desainer dapat bekerja sama.

1. Terlibat sejak awal

Jangan berasumsi bahwa desain selalu didahulukan dan pengembangan didahulukan. Ini mungkin benar, namun bukan berarti pengembang tidak boleh terlibat dalam proses desain. Pemrogram mampu memberikan informasi teknis penting tentang bagaimana proyek dapat dilaksanakan, sementara desainer lebih memahami keinginan pengguna. Lebih baik mencari tahu sedini mungkin fungsi mana yang secara teknis tidak mungkin atau tidak memenuhi persyaratan pengguna. Jika perancang dan pengembang bekerja sama, masalah dapat ditemukan dan diselesaikan segera, bukan setelah desain disetujui. Banyak perusahaan mengambil pendekatan kolaboratif dalam pengembangan perangkat lunak. Artinya, anggota tim tidak hanya bertanggung jawab atas tahapan atau bagian kode mereka sendiri, namun juga mengambil tanggung jawab kolektif atas segala hal mulai dari desain hingga pengujian.

2. Pelajari proses UX

Mereka yang tidak terbiasa dengan UX (pengalaman pengguna) mungkin tidak memahami mengapa tim mengubah desain berulang kali untuk detail yang tampaknya kecil. Setiap langkah dalam proses UX terjadi karena satu alasan: untuk memberikan pengalaman terbaik kepada pengguna. Oleh karena itu, penting untuk memperhatikan pembuatan proses UX sejak awal. Ini mungkin termasuk:

• meneliti tujuan proyek;
• membuat gambar rangka - desain sederhana yang memungkinkan Anda menentukan karakteristik utama produk;
• menambahkan detail yang lebih halus pada desain proyek, seperti antarmuka pengguna;
• pengujian desain oleh pengguna. Ini mungkin tahap paling penting dalam pengembangan UX. Ini memberikan informasi berharga tentang produk sebelum Anda meluangkan waktu untuk mengembangkannya;
• Iterasi: Menggunakan analisis hasil pengujian, ulangi desain untuk meningkatkan pengalaman pengguna.

Tim mengulangi langkah desain dan pengujian beberapa kali hingga tidak ada perubahan yang tersisa, atau jika waktu memungkinkan. Ini biasanya berarti Anda akan memiliki beberapa versi desain.

3. Ikuti perkembangan desain

Sangat buruk bila desainer membuat proyek tanpa berkonsultasi dengan pengembang. Itu kontraproduktif. Penting bagi DevOps untuk menetapkan aturan sehingga pengembang memiliki akses untuk merancang cetak biru dalam format yang mudah diakses seperti PNG atau PDF. Kolaborasi yang efektif antara pengembang dan desainer sangat penting untuk keberhasilan implementasi suatu aplikasi. Hindari menyerahkan desain yang sudah jadi secara membabi buta dengan cara apa pun. Lebih baik memperbaiki kesalahan di awal daripada di akhir.

4. Sepakati pada tahap apa proyek tersebut akan diperlihatkan kepada Anda

Ketika pengembang diminta untuk membuat versi produk minimum yang layak (MVP), mereka perlu mengetahui persyaratan untuk versi final sejak awal. Hal ini diperlukan untuk menghindari masalah dengan harapan yang tidak dapat dibenarkan. Desainer harus menunjukkan kedua versi desain kepada pengembang: MVP dan versi final. Ini akan membantu mengimplementasikan MVP, dengan mempertimbangkan apa yang diharapkan pelanggan untuk dilihat di versi final. Ketika desainer dan pengembang bekerja sama, mereka mendapatkan banyak manfaat. Masing-masing dari mereka memiliki pengetahuan yang dapat diterapkan pada pengalaman yang lain. Pengembang dapat memberikan wawasan berharga tentang fitur apa saja yang tidak dapat diterapkan dalam desain. Di sisi lain, kolaborasi dengan seorang programmer akan membebaskan desainer dari keharusan mengulang proyek, yang karenanya akan menghemat waktu seluruh tim.