Apa yang harus saya lakukan ketika kode saya berbau?


13

Saya seorang programmer pemula dan seringkali ketika saya mengerjakan proyek-proyek saya sendiri, saya selalu merasa bahwa desain kode saya bukan yang terbaik, dan saya benci perasaan ini. Saya akhirnya menghabiskan waktu mencari hal-hal, tetapi kemudian saya menjadi mudah kewalahan dengan banyak detail, seperti pola desain untuk memilih dan kapan harus menggunakan kelas abstrak atau antarmuka. Apakah saya harus mencoba dan mempelajari sedikit semuanya sekaligus?


15
use deodorant;)
Pemdas

6
Dan mungkin disinfektan / insektisida untuk menghilangkan serangga :-)
Stephen C

3
Makanlah bawang putih. Orang mungkin akan lebih memperhatikan bau mulut Anda.
Mateen Ulhaq

4
dan sekarang Anda memiliki: codereview.stackexchange.com di mana Anda bisa mendapatkan bantuan dengan contoh spesifik kode Anda.
LRE

1
Buka windows ... oh tunggu ...
Mchl

Jawaban:


18

Beberapa saran:

  1. Gunakan enkapsulasi untuk mengelola kompleksitas dengan memisahkan fungsionalitas menjadi blok bangunan yang berbeda. Buktikan setiap blok berfungsi (melalui tes unit), dan Anda dapat menggunakannya tanpa khawatir tentang detail bagian dalamnya.

  2. Pelajari dan pelajari pola perangkat lunak . Pola perangkat lunak dicoba dan terbukti metode untuk melakukan tugas-tugas umum tertentu yang terkenal.

  3. Pelajari dan pahami struktur data. Pelajari penggunaan yang tepat dan karakteristik kinerja untuk setiap jenis struktur data.

  4. Ketahui bahasa pemrograman Anda dengan baik, kekuatan dan kelemahannya, dan cara terbaik menggunakan fitur-fiturnya.

Anda tidak harus mengetahui semua ini sekaligus, tetapi Anda harus mempelajari semua itu dari waktu ke waktu.


12

Saran saya adalah: berhentilah khawatir.

Pengalaman adalah guru terbaik, dan Anda tidak mendapatkan pengalaman jika Anda tidak menulis kode. Juga, kode dirancang buruk yang sudah ditulis lebih baik dari desain besar yang tidak .

Jadi, tulis lebih banyak kode. Selesaikan proyek Anda. Perasaan bahwa kode itu tidak ideal mungkin benar. Dan Anda mungkin akan memiliki masalah dengan kode ini. Dan ketika Anda memiliki masalah ini, maka Anda akan belajar mengapa itu sebenarnya buruk. Anda akan belajar lebih banyak dari pengalaman langsung daripada dari "mencari sesuatu".

Juga, jangan harap perasaan "bau kode" ini akan hilang. Ketika Anda menjadi lebih baik, Anda akan memperbaiki beberapa masalah, tetapi mulai memperhatikan yang baru, yang lebih tidak jelas / lanjutan.


+1 untuk kode tertulis yang dirancang dengan buruk lebih baik daripada kode hebat yang tidak tertulis!
GrandmasterB

Kedengarannya seperti disangkal, tetapi tidak. Kode yang dirancang dengan buruk yang melakukan apa yang dimaksudkan lebih baik daripada kode tidak tertulis yang dirancang dengan baik. Namun, jika kode dirancang dengan buruk, seberapa besar kemungkinan kode itu akan melakukan apa yang seharusnya dilakukan?
Matt Ellen

Kita sedang membicarakan proyek pribadi di sini. Tentu saja, jika kita mempertimbangkan perangkat lunak pengontrol rudal nuklir, tidak ada kode yang lebih baik dari kode yang buruk.
Nevermind

@ Matt - tergantung pada seberapa buruk tulisan itu sebenarnya. IMO hampir semua kode dunia nyata berbau sampai batas tertentu, dan menara gading tidak bereaksi dengan baik terhadap perubahan (salah satu masalah dengan terlalu banyak data bersembunyi dan terlalu banyak lapisan abstraksi). Pengalaman benar-benar adalah satu-satunya solusi, meskipun ada alasan bagus mengapa aturan standar diajarkan tentu saja. Pengalaman utama adalah kurang mengetahui aturan, dan lebih tahu kapan dan bagaimana melanggarnya. Sedangkan untuk mempelajari aturan - saya sudah menjadi programmer selama hampir 30 tahun sekarang, termasuk hal-hal hobi anak, dan saya masih belajar hal-hal baru sepanjang waktu.
Steve314

@ Steve314: Ya, saya setuju, maka peringatan saya tentang melakukan apa yang seharusnya dilakukan. Anda tidak dapat belajar kode tanpa kode, seperti yang Anda tunjukkan, dan ketika mengerjakan proyek pribadi untuk mendapatkan pemahaman tentang dasar-dasar, atau topik yang lebih maju, saya pikir penting untuk memikirkan apa yang ingin Anda capai , daripada terburu-buru dan mulai coding. Sedikit desain dapat berjalan jauh, karena, seperti yang saya yakin Anda tahu, pemrograman bukan hanya tentang pengkodean.
Matt Ellen

3

Ini adalah masalah umum dengan pemrogram pemula. Jangan melumpuhkan diri Anda dengan berpikir semuanya harus sempurna. Itulah cara paling pasti untuk tidak pernah menyelesaikan proyek. Salah satu keterampilan yang paling penting untuk dipelajari sebagai pengembang adalah perbedaan antara sempurna dan cukup baik . Terima bahwa setiap sistem yang Anda buat dapat diperbaiki. Fokus pada penyelesaian proyek Anda. Setelah selesai, Anda dapat kembali dan meningkatkannya. Itulah mengapa kami memiliki versi 2.0.


Panggilan bagus! Mengetahui bahwa sesuatu bisa lebih baik adalah awal yang baik.
ozz

2

Apakah saya harus mencoba dan mempelajari sedikit semuanya sekaligus?

Saya harap tidak. Di sisi lain, Anda harus belajar dan meningkatkan sepanjang waktu.

Baca buku, ambil kursus, dapatkan kualifikasi, kerjakan, dan Anda harus meningkatkan.


2

Saran terbaik saya adalah fokus pada dasar-dasar seperti daftar yang disarankan Robert Harvey. Pengembangan perangkat lunak adalah monster kompleks yang membutuhkan waktu bertahun-tahun bahkan untuk menjadi sangat baik, terutama dalam topik desain antarmuka yang baik. Sangat sulit untuk menghargai banyak aspek pengembangan perangkat lunak tanpa terlebih dahulu mengalaminya. Bahkan sesuatu yang mendasar seperti kode komentar dapat dihargai. Sejak hari pertama, Anda diajarkan untuk menulis kode yang terdokumentasi dengan baik. Saya akui itu tidak sampai saya benar-benar sedikit dalam $$ mencoba memahami kode yang saya tulis beberapa bulan yang lalu sebelum saya benar-benar menghargai nilai komentar yang baik. Hal yang sama dapat dikatakan untuk banyak konsep pemrograman. Misalnya, enkapsulasi data, modul berpasangan rendah, dan antarmuka bersih yang jernih.

Sumber daya paling berharga yang saya temui adalah rekan kerja saya. Anda akan menulis kode yang buruk. Terimalah itu. Ini adalah apa yang Anda lakukan untuk memastikan bahwa Anda menulis kode yang lebih baik dari waktu ke waktu yang mendefinisikan Anda sebagai seorang programmer. Misalnya, ketika saya mulai bekerja, perusahaan saya tidak memiliki kode formal atau prosedur tinjauan desain. Saya mengambilnya sendiri untuk membuat pekerjaan saya dikritik oleh rekan kerja saya yang lebih senior dan jujur, saya merasa seperti orang idiot untuk bagian yang lebih baik dari tahun pertama saya bekerja.

Pengembangan perangkat lunak merupakan pengalaman pembelajaran yang berkelanjutan. Ajukan banyak pertanyaan, periksa kode Anda, pahami mengapa ada saran yang diberikan lebih banyak orang senior, jangan takut untuk mempertanyakan validitas saran yang diberikan oleh pengembang senior dan yang terpenting jangan takut salah. Akhirnya faktor intimasi atau perasaan menjadi mode yang kewalahan. Sebagai catatan ... kurva belajar mengisap.


2
  • Pertama: Refactoring (masih akan berbau tetapi akan sedikit lebih teratur)
  • Kedua: Lihat apakah Anda dapat menggunakan beberapa Design Patter untuk membuat potongan refactored sesuai dengan logika Anda.
  • Ketiga: ketika segalanya mulai terlihat lebih baik, ingat waktu yang Anda habiskan untuk melakukan langkah pertama dan kedua. Dengan cara ini ketika Anda menulis beberapa fitur baru, Anda akan memikirkannya saat melakukannya dan bukan sebagai proses lain.

2

Lihatlah buku Refactoring: Meningkatkan Desain Kode yang Ada , oleh Martin Fowler. Hal pertama yang harus Anda lakukan adalah memperbaiki kode Anda , untuk meningkatkan keterbacaan kode dan mengurangi kompleksitas untuk meningkatkan pemeliharaannya.

Saat Anda membuat ulang kode, Anda sudah menggunakan Pola Desain , Mengenkapsulasi kode , dll.

Ini adalah salah satu buku terbaik yang pernah saya baca tentang topik ini. Ini menyediakan banyak resep berguna.


2

Sumber yang bagus adalah The Pragmatic Programmer . Bab tentang "Windows Rusak" menjelaskan di mana Anda melihat diri Anda sendiri. Respons singkat dan bernas adalah untuk memperbaiki masalah.

Ketika Anda mulai memperbaiki desain Anda, ada baiknya Anda memahami apa yang tidak Anda sukai tentangnya. Sangat mudah untuk datang dengan jawaban yang tidak jelas seperti "itu hanya terjadi di semua tempat" atau "mengapa saya melakukan itu di sana?". Tetapi luangkan waktu untuk melihat apakah ada pola umum yang Anda gunakan.

  • Desain yang baik akan menggunakan kembali sejumlah kecil konsep di seluruh basis kode (idealnya adalah satu konsep, tetapi dalam praktiknya Anda mungkin memerlukan beberapa lagi)
  • Desain yang baik akan memudahkan untuk mencari tahu di mana memperbaiki masalah (prinsip KERING, prinsip SRP)
  • Desain yang baik akan memiliki pelaporan kesalahan yang baik (terkait dengan poin di atas, tetapi dipanggil sebagai item terpisah karena merupakan aspek yang sering diabaikan)

Setelah Anda mengetahui ke mana Anda ingin pergi, ambil langkah-langkah kecil yang mudah dibalik untuk sampai ke sana (yaitu inilah yang dimaksud dengan Refactoring ). Setiap kali Anda meningkatkan kode, pertimbangkan dampaknya pada sisa kode. Apakah Anda membuat segalanya lebih baik atau lebih buruk? Setidaknya ini adalah pendekatan saya untuk menertibkan kekacauan.


1

Jika Anda sudah memiliki pengalaman dalam pemrograman, mengapa Anda tidak mempelajari beberapa proyek open source yang memiliki kode bersih ? Anda dapat melihat pertanyaan INI dari SO yang memiliki beberapa tautan yang relevan.

Juga, pola desain adalah harus tahu - pikirkan tentang hal itu, seluruh gagasan memiliki pola adalah untuk memecahkan masalah yang diketahui tanpa menciptakan kembali roda atau menulis kode kereta.

Akhirnya, sepertinya Anda perlu dosis pemrograman fungsional untuk menjernihkan pikiran Anda. Lihatlah Haskell atau Ocaml sebagai permulaan.


0

Jika Anda bukan monster berbahaya, Anda harus mencari teman yang disebut , yang dapat meninjau kode Anda, dan sebaliknya. Juga, jika Anda membuat sesuatu, yang akan ditinjau kembali, atau hanya diawasi oleh orang lain, itu adalah tekanan yang baik untuk melakukannya dengan cara yang lebih baik.

Dan jangan lupa, pemrograman dimulai sebelum coding, selalu tinjau kembali ide-ide Anda, rencana. Jika rencana Anda buruk, itu tindakan yang menyenangkan untuk membuangnya: Anda baru saja menyelamatkan frustrasi membuang sekelompok kode (dan waktu pembuatannya) berdasarkan rencana yang buruk.


0

Saran saya, perhatikan setiap aroma dengan serius dan coba perbaiki. Ada banyak buku bagus tentang topik ini (Kode bersih dan GOOS adalah IMHO terbaik). Tetapi lebih dari buku pergi ke konferensi untuk mendengar dan berdiskusi dengan orang lain dan di komunitas online (milis, grup). Masih lebih baik mencoba untuk bergabung dengan xxug lokal Anda (dotnetug, kendi, xpug, dll.) Atau menemukannya.

Mendiskusikan dengan programmer lain adalah satu-satunya cara saya tahu untuk benar-benar meningkatkan (kecuali jika Anda cukup beruntung untuk bekerja sama dengan programmer lain yang berdedikasi).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.