Kata Pengantar Penerjemah: Setelah membaca artikel ini, Anda mungkin terkejut atau bahkan marah. Ya, kami juga terkejut: penulis diduga tidak pernah mendengar tentang hierarki dalam tim, tentang pengaturan tugas dengan status "lakukan dengan cepat dan tanpa alasan". Ya, itu saja, itu teks yang agak aneh. Memang, penulis menawarkan programmer untuk mengambil peran seorang arsitek sistem - mengapa Anda membutuhkan seorang arsitek? Tetapi semua keberatan ini seharusnya tidak menyembunyikan dari Anda hal utama - mengapa kami mengambil dan menerjemahkan teks ini. Dia bukan tentang peran. Teks ini tentang pendekatan profesional dan kesadaran. Yang benar adalah bahwa ketika Anda hanya "melakukan apa yang mereka katakan" tanpa memikirkan arti dari tindakan Anda, Anda tidak akan pernah menjadi programmer yang hebat.Katakan tidak untuk kode tambahan. Yang harus Anda lakukan adalah mengumpulkan ketiga huruf dan mengucapkan kata. Mari kita coba bersama: "Tidaaaak!"
Tapi hei. Kenapa kita melakukan ini? Bagaimanapun, tugas utama seorang programmer adalah menulis kode. Tetapi apakah perlu untuk menulis kode apa pun yang diminta dari Anda? Tidak! "Memahami ketika Anda tidak seharusnya menulis kode mungkin merupakan keterampilan paling penting bagi seorang programmer."
Seni Kode Yang Dapat Dibaca .
Kami mengingatkan Anda: untuk semua pembaca "Habr" - diskon 10.000 rubel saat mendaftar untuk kursus Skillbox menggunakan kode promo "Habr".
Skillbox merekomendasikan: Kursus praktis "Pengembang Mobile PRO" .
Pemrograman adalah seni pemecahan masalah. Dan Anda adalah penguasa seni ini.
Terkadang, mencoba memulai sesegera mungkin, kami tidak memikirkan apa pun selain menyelesaikan tugas. Dan ini dapat menyebabkan masalah yang lebih serius.
Untuk apa para programmer menutup mata?
Semua kode yang Anda tulis harus dipahami oleh pengembang lain, serta diuji dan di-debug.
Tetapi ada masalah: apa pun yang Anda tulis, itu akan menyulitkan perangkat lunak Anda dan mungkin akan menambah bug di masa depan.
Menurut Rich Skrent,
kode itu adalah musuh kita . Inilah yang dia tulis:
“Kode ini buruk karena mulai membusuk dan membutuhkan pemeliharaan yang konstan. Menambahkan fitur baru seringkali memerlukan modifikasi kode lama. Semakin besar, semakin tinggi kemungkinan kesalahan terjadi dan semakin banyak waktu yang dibutuhkan untuk mengkompilasi. Pengembang lain perlu lebih banyak waktu untuk mengetahuinya. Dan jika Anda perlu refactoring, maka pasti ada fragmen yang layak diubah. Kode massal sering kali berarti mengurangi fleksibilitas dan fungsionalitas suatu proyek. Solusi sederhana dan elegan lebih cepat daripada kode kompleks. ”
Bagaimana cara mengetahui kapan Anda seharusnya tidak menulis kode?
Masalahnya adalah bahwa programmer sering melebih-lebihkan jumlah fungsi yang dibutuhkan aplikasi mereka. Akibatnya, banyak bagian dari kode tetap tidak lengkap atau tidak ada yang menggunakan, tetapi mereka mempersulit aplikasi.
Anda harus mengetahui dengan jelas apa yang dibutuhkan oleh proyek Anda dan apa yang tidak.Contohnya adalah aplikasi yang hanya memecahkan satu tugas - ia mengelola email. Dua fungsi telah diperkenalkan untuk ini - mengirim dan menerima surat. Anda seharusnya tidak berharap bahwa manajer surat secara bersamaan akan menjadi manajer tugas.
Anda harus tegas mengatakan tidak pada saran untuk menambahkan fungsi yang tidak terkait dengan tugas utama aplikasi. Inilah saat ketika menjadi jelas bahwa kode tambahan tidak diperlukan.
Jangan pernah fokus aplikasi Anda.Selalu bertanya pada diri sendiri:
- Fungsi apa yang harus diimplementasikan sekarang?
- Kode apa yang layak ditulis?
Tanyakan ide-ide yang muncul di benak Anda dan evaluasi saran dari luar. Jika tidak, kode tambahan hanya dapat mematikan proyek.
Mengetahui kapan Anda seharusnya tidak menambahkan terlalu banyak akan menjaga basis kode di bawah kontrol ketat.
Di awal jalur, programmer hanya memiliki dua atau tiga file sumber. Semuanya sederhana. Mengompilasi dan menjalankan aplikasi membutuhkan waktu minimum; selalu jelas di mana dan apa yang harus dicari.
Ketika aplikasi berkembang, semakin banyak file kode muncul. Mereka mengisi direktori, masing-masing dengan ratusan baris. Untuk mengatur semua ini dengan benar, Anda harus membuat direktori tambahan. Pada saat yang sama, semakin sulit untuk mengingat fungsi mana yang bertanggung jawab untuk apa dan tindakan apa yang mereka sebabkan; menangkap bug juga membutuhkan waktu lebih lama. Manajemen proyek menjadi lebih rumit, bukan hanya satu, tetapi beberapa pengembang diminta untuk melacak semuanya. Dengan demikian, biaya, baik moneter dan sementara, tumbuh, dan proses pengembangan terhambat.
Proyek akhirnya menjadi besar, menambahkan setiap fungsi baru diberikan dengan kesulitan besar dan luar biasa. Bahkan untuk sesuatu yang sangat tidak penting Anda harus menghabiskan beberapa jam. Koreksi kesalahan yang ada mengarah pada munculnya yang baru, tanggal rilis aplikasi terganggu.
Sekarang kita harus berjuang demi kehidupan proyek. Mengapa
Faktanya adalah bahwa Anda sama sekali tidak mengerti ketika Anda tidak perlu menambahkan kode tambahan, dan mereka menjawab "ya" untuk setiap kalimat dan ide. Anda buta, keinginan untuk menciptakan sesuatu yang baru membuat Anda mengabaikan fakta-fakta penting.
Kedengarannya seperti naskah film horor, kan?
Inilah yang akan terjadi jika Anda terus mengatakan ya. Cobalah untuk memahami ketika kode tidak layak ditambahkan. Hapus yang tidak perlu dari proyek - ini akan sangat memudahkan hidup Anda dan memperpanjang keberadaan aplikasi.
"Salah satu hari saya yang paling produktif adalah ketika saya menghapus 1000 baris kode."
- Ken Thompson.
Belajar memahami ketika Anda tidak perlu menulis kode itu sulit. Tapi itu perlu.
Ya, saya tahu Anda baru saja memulai jalur pengembang dan ingin menulis kode. Ini bagus, jangan kehilangan kesan pertama ini, tetapi jangan lupa faktor-faktor penting karena antusiasme. Kami menyadari semuanya melalui coba-coba. Anda juga akan membuat kesalahan dan belajar darinya. Tetapi jika Anda dapat belajar dari pelajaran di atas, pekerjaan Anda akan menjadi lebih sadar.
Teruslah membuat, tetapi tahu kapan harus mengatakan tidak.
Skillbox merekomendasikan: