Cara untuk memecahkan “Syndrome of the perfect programmer” [ditutup]

Saya mungkin bukan satu-satunya yang merasakan hal itu. Tetapi saya memiliki apa yang saya sebut "Sindrom programmer sempurna" yang banyak orang katakan adalah sama dengan perfeksionis tetapi dalam hal ini berada dalam domain pemrograman. Namun, domain pemrograman agak bermasalah untuk sindrom semacam itu.

Pernahkah Anda merasa bahwa ketika Anda memprogram Anda tidak percaya diri atau tidak pernah cukup percaya diri bahwa kode Anda bersih dan kode yang baik yang mengikuti sebagian besar praktik terbaik? Ada begitu banyak aturan yang harus diikuti sehingga saya merasa kewalahan. Bukannya saya tidak suka mengikuti aturan tentu saja saya seorang programmer dan saya suka pemrograman, saya melihat ini sebagai seni dan saya harus mengikuti aturan. Tapi aku juga menyukainya, maksudku aku ingin dan aku suka mengikuti aturan untuk memiliki perasaan yang baik tentang apa yang aku lakukan berjalan dengan cara yang benar .. tapi aku hanya berharap aku bisa memiliki segalanya sedikit lebih dalam "kontrol" tentang praktik terbaik dan kode yang baik.

Mungkin karena kurangnya organisasi? Mungkin karena kurangnya pengalaman? Mungkin kurang latihan? Mungkin karena kurangnya sesuatu yang bisa ditunjukkan oleh seseorang? Apakah ada cara untuk menghilangkan sindrom itu?

Memprioritaskan . Hal pertama yang pertama. Fokus pada apa yang penting.

Prioritas Anda mungkin beragam, tetapi secara umum Anda harus peduli:

• Kode yang benar
• Kode dapat dipertahankan
• Kode bersih
• Kode sederhana dan elegan
• Kode efisien

Mungkin dalam urutan itu. Namun, poin pertama adalah yang paling penting. Tanpa itu, kode tidak akan berguna. Apa yang Anda lakukan dengan program yang tidak berfungsi dengan benar?

Buat itu bekerja, semua yang lain dekat tidak relevan untuk menyelesaikan masalah yang perlu Anda pecahkan. Tentu saja, saya juga menderita ini. Apa yang saya pelajari yang membantu adalah fokus pada solusi yang berhasil . Itu cukup. Itu adalah 99% dari pekerjaan.

Anda mungkin ingin memikirkan sesuatu seperti kode yang baik . Apa itu? Orang macam apa yang menulisnya? Bagaimana cara menulis kode yang baik ? Ini sangat sederhana. Tulis kode yang berfungsi . Kode kerja adalah kode yang baik. Segala sesuatu yang lain datang kemudian.

Tentu saja, ketika menulis kode secara profesional, lingkungan tim , kode yang jelas, dapat dibaca, dan kode yang dapat dipelihara menjadi semakin penting. Namun, masih tugas pertama adalah membuatnya berfungsi , dan fokus pada hal itu. Hanya dengan begitu Anda dapat mulai memperbaiki dan refactoring menjadi lebih baik - jika diperlukan.

Seringkali sangat jelas bahwa kebenaran kode sangat penting - namun kita semua gagal merangkul pentingnya kode ketika menulis kode. Kami mengambil jalan pintas, kami menggunakan optimasi prematur, kami mencoba untuk menulis kode yang elegan bahkan sebelum kami memiliki kode kerja yang ditulis. Sudah menjadi sifat manusia untuk mengusahakan kesempurnaan sejak awal, tetapi pemrograman dan pengembangan perangkat lunak adalah proses berulang, dan prioritas ada. Jadi, sekali lagi, buat itu berfungsi , khawatir tentang yang lain nanti. Memahami pentingnya kode yang benar dan berusaha keras untuk itu.

Meskipun ada berton-ton praktik yang baik , saya pikir akal sehat adalah yang paling penting, pikirkan mengapa praktik itu dianggap baik, kapan dan di mana menerapkannya. Namun, jangan berusaha untuk memenuhi setiap praktik yang baik. Tidak ada pengganti atau pengganti pengalaman pribadi. Anda tidak dapat menghindari perangkap umum - tidak peduli berapa banyak buku yang Anda baca, seminar yang Anda hadiri atau yang lainnya. Yang penting adalah belajar dengan melakukan, melakukan hal-hal dengan benar dan bersenang-senang - kapan pun memungkinkan.

Cara paling sederhana untuk menghindari masalah ini adalah dengan hanya mengubah apa yang sakit. Jangan memoles kode yang benar, dapat dibaca dan dipelihara, bahkan jika Anda berpikir bahwa beberapa perubahan mungkin membuatnya lebih baik. Tetapi begitu Anda misalnya mencoba mengubah sesuatu dan menemukan variabel yang tujuannya tidak jelas, atau fungsi yang terlalu panjang untuk dipahami, perbaiki. Tidak lebih cepat.

Itu tidak berarti bahwa Anda tidak harus berusaha untuk kode yang baik dan bersih di tempat pertama, tentu saja Anda harus, tetapi Anda harus mempertimbangkan upaya pertama Anda "cukup baik" kecuali terbukti sebaliknya.

Saya pikir penangkal terbaik untuk ini adalah untuk mengingatkan diri sendiri bahwa semua praktik terbaik dan aturan kebersihan kode tidak ada untuk kepentingan mereka sendiri, juga kode itu sendiri.

Pada akhirnya, yang lebih penting dari apa pun adalah bahwa perangkat lunak berfungsi dan dapat digunakan. Dan itu tidak akan terjadi jika Anda tidak menyelesaikannya.

Saya tidak suka perbandingan pengkodean ke seni, tetapi dalam hal ini berfungsi: seniman ( terutama penulis ) juga sering ingin terus mengerjakan karya karena selalu ada sesuatu yang tidak sempurna. Tetapi nilai apa yang ada dalam kesempurnaan ketika ia menunda publikasi tanpa batas dan dengan demikian mencegah siapa pun untuk menghargai karya itu?

Hal yang paling penting untuk disadari adalah kode Anda akan selalu berubah, dan selalu ada ruang untuk perbaikan. Tidak ada kode yang sempurna. Lebih sering daripada tidak, perpustakaan kelas tempat Anda bekerja hari ini akan sangat berbeda enam bulan ke depan. Anda belajar teknik baru, atau menemukan pola yang benar-benar cocok untuk Anda. Selama kode tersebut mudah dipelihara dan dibaca maka Anda harus baik. Idealnya Anda akan memiliki unit test untuk membuatnya lebih mudah untuk refactor di kemudian hari.

Sangat mudah untuk terjebak dalam membuat kode terlihat sempurna dan mengikuti setiap standar yang dapat Anda pikirkan. Itu terjadi pada kita semua. Melihat kode yang saya tulis beberapa minggu lalu membuat saya berpikir untuk melakukan perubahan. Tambahkan properti di sini, refactor metode di sana. Dan itu tampaknya terjadi pada akhir proyek. Tetapi jika Anda terlalu larut dalam hal itu Anda bisa berakhir membuat bug showstopping. Saya telah melakukan itu beberapa kali di awal karir saya. Beberapa sesi perbaikan bug 3 pagi menyembuhkan saya dari masalah itu.

Lakukan sebaliknya.

Alih-alih "apa yang bisa dilakukan dengan lebih baik?" mencari "apa yang membuatku kesal?" sampai tidak ada yang berhasil.

Sebagai seorang programmer, tugas Anda adalah menghasilkan kode. Tujuan dari praktik terbaik adalah untuk meningkatkan tingkat produksi Anda dengan membuat hal-hal lebih mudah dipahami / dilakukan / diingat. Jika mengikuti praktik-praktik ini menghalangi benar-benar menyelesaikan sesuatu, Anda melakukan sesuatu yang salah. Cukup coba untuk menghasilkan kode secepat mungkin, dan praktik Anda harus berkembang agar Anda dapat melakukan hal itu.

Buat itu berfungsi, bersihkan, SOLID, buat performan.

Tiga yang pertama adalah pepatah yang saya dukung setiap kali ada yang bertanya-tanya bagaimana menulis kode SOLID pada timeline. Ketika Anda pertama kali menulis satu baris kode, itu hanya harus bekerja, jadi lakukan apa yang harus Anda lakukan dan jangan menjadi mewah. Pertama kali Anda mengunjungi kembali satu baris kode, itu bukan lagi satu kali dan Anda harus membersihkan kode itu, membuatnya dapat dibaca dan dengan demikian lebih dapat dipertahankan. Ketiga kalinya kursor Anda masuk ke dalam baris itu, mungkin itu adalah masalah besar sekarang, dan Anda harus refactor untuk mematuhi metodologi SOLID, mengabstraksikan dependensi, pola implementasi, dan umumnya membuat kode lebih mudah untuk dihubungkan atau dicolokkan ke dalam untuk peningkatan di masa depan.

Keanggunan dalam kode harus dicapai di mana programmer memperhatikan peluang, dan umumnya merupakan fungsi penyederhanaan, pembersihan, dan umumnya meningkatkan keterbacaan dan pemeliharaan kode sambil mengikuti langkah-langkah sebelumnya. Itu bukan sesuatu yang harus dimaksimalkan .

Kode performant hampir selalu menjadi perhatian paling sedikit dalam bahasa yang dikelola memori (Java, keluarga .NET, sebagian besar bahasa fungsional, dll). Dalam lingkungan ini, tujuannya adalah untuk menulis kode yang benar ("benar" di sini didefinisikan sebagai menghasilkan hasil yang diharapkan dalam semua kasus yang diharapkan, danmenjadi dimengerti dan terstruktur dengan baik, dan dengan demikian dapat dipertahankan), dan kinerja adalah sekunder (biasanya akan melanjutkan ke tingkat tertentu dari kode yang benar). Dalam semua kasus, suatu algoritma tampil ketika "cukup baik". Ingat, "optimisasi prematur adalah akar dari semua kejahatan"; membuat optimasi yang Anda tidak tahu Anda perlu melakukan sedikit lebih dari membuang waktu, mengaburkan kode, dan umumnya mencegah kemajuan. Ini harus bekerja dulu, lalu setelah berhasil, Anda jalankan dan lihat seberapa cepat itu berjalan. Jika itu tidak cukup cepat (seperti yang didefinisikan oleh beberapa tolok ukur yang merupakan persyaratan yang dipublikasikan), Anda meningkatkannya sampai itu, dan kemudian Anda berhenti .

Anda benar-benar harus pragmatis tentang pemrograman. Ya, kita semua suka melakukan hal yang benar, tetapi Anda dibayar untuk mengirimkan perangkat lunak yang berfungsi, bukan untuk memolesnya selama sisa hidup Anda.

Pendekatan yang harus diambil adalah "menyelesaikannya" dalam kehidupan profesional Anda. Kirim dan lanjutkan. Simpan perfeksionisme Anda untuk proyek-proyek pribadi.