Praktik pemrograman apa yang pernah Anda sukai, yang berubah pikiran? [Tutup]

Saat kita memprogram, kita semua mengembangkan praktik dan pola yang kita gunakan dan andalkan. Namun, seiring waktu, seiring dengan perubahan pemahaman, kedewasaan, dan bahkan penggunaan teknologi kita, kita menyadari bahwa beberapa praktik yang pernah kita anggap hebat ternyata tidak (atau tidak lagi berlaku).

Contoh praktik yang pernah saya gunakan cukup sering, tetapi beberapa tahun terakhir telah berubah, adalah penggunaan pola objek Singleton .

Melalui pengalaman saya sendiri dan perdebatan panjang dengan kolega, saya menyadari bahwa lajang tidak selalu diinginkan - mereka dapat membuat pengujian lebih sulit (dengan menghambat teknik seperti mengejek) dan dapat membuat penggabungan yang tidak diinginkan antara bagian-bagian sistem. Sebagai gantinya, saya sekarang menggunakan pabrik objek (biasanya dengan wadah IoC) yang menyembunyikan sifat dan keberadaan lajang dari bagian-bagian sistem yang tidak peduli - atau perlu diketahui. Sebaliknya, mereka mengandalkan pabrik (atau pencari layanan) untuk memperoleh akses ke objek tersebut.

Pertanyaan saya kepada masyarakat dalam semangat perbaikan diri adalah:

• Pola atau praktik pemrograman apa yang baru-baru ini Anda pertimbangkan kembali, dan sekarang coba Anda hindari?
• Dengan apa Anda memutuskan untuk menggantinya?

//Coming out of university, we were taught to ensure we always had an abundance 
//of commenting around our code. But applying that to the real world, made it 
//clear that over-commenting not only has the potential to confuse/complicate 
//things but can make the code hard to follow. Now I spend more time on 
//improving the simplicity and readability of the code and inserting fewer yet 
//relevant comments, instead of spending that time writing overly-descriptive 
//commentaries all throughout the code.

Poin pengembalian tunggal.

Saya pernah lebih suka satu titik kembali untuk setiap metode, karena dengan itu saya dapat memastikan bahwa pembersihan apa pun yang diperlukan oleh rutin tidak diabaikan.

Sejak itu, saya telah beralih ke rutinitas yang jauh lebih kecil - sehingga kemungkinan mengabaikan pembersihan berkurang dan pada kenyataannya kebutuhan untuk pembersihan berkurang - dan menemukan bahwa pengembalian awal mengurangi kompleksitas yang tampak (tingkat bersarang) dari kode. Artefak titik kembali tunggal - menyimpan variabel "hasil", mempertahankan variabel bendera, klausa bersyarat untuk situasi yang belum selesai - membuat kode tampak jauh lebih kompleks daripada yang sebenarnya, membuatnya lebih sulit untuk dibaca dan dipelihara. Keluar lebih awal, dan metode yang lebih kecil, adalah cara yang tepat.

• Mencoba membuat kode dengan sempurna pada percobaan pertama.
• Mencoba membuat model OO yang sempurna sebelum melakukan pengkodean.
• Merancang segalanya untuk fleksibilitas dan peningkatan di masa depan.

Dalam satu kata, rekayasa berlebihan .

Notasi bahasa Hongaria (baik Bentuk maupun Sistem). Aku biasa mengawali semuanya. strSomeString atau txtFoo. Sekarang saya menggunakan someString dan textBoxFoo. Jauh lebih mudah dibaca dan lebih mudah bagi orang baru untuk datang dan menjemput. Sebagai bonus tambahan, sangat mudah untuk membuatnya tetap konsisten - camelCase kontrol dan tambahkan nama yang berguna / deskriptif. Formulir Bahasa Hongaria memiliki kelemahan karena tidak selalu konsisten dan Sistem Bahasa Hongaria tidak benar-benar menguntungkan Anda. Menggabungkan semua variabel Anda tidak terlalu berguna - terutama dengan IDE modern.

Arsitektur yang "sempurna"

Saya datang dengan arsitektur THE beberapa tahun yang lalu. Dorong diri saya secara teknis sejauh yang saya bisa sehingga ada 100% lapisan yang digabungkan secara longgar, penggunaan delegasi yang ekstensif, dan objek ringan. Itu adalah surga teknis.

Dan itu omong kosong. Kemurnian teknis arsitektur hanya memperlambat tim pengembang saya untuk mencapai kesempurnaan atas hasil dan saya hampir mencapai kegagalan total.

Kami sekarang memiliki arsitektur yang jauh lebih sederhana secara teknis kurang sempurna dan tingkat pengiriman kami telah meroket.

Penggunaan caffine. Itu pernah membuat saya tetap terjaga dan dalam suasana pemrograman yang hebat, di mana kode terbang dari jari-jari saya dengan fluiditas yang luar biasa. Sekarang tidak melakukan apa-apa, dan jika saya tidak memilikinya, saya sakit kepala.

Mengomentari kode. Saya dulu berpikir bahwa kode itu berharga dan Anda tidak bisa begitu saja menghapus permata indah yang Anda buat. Sekarang saya menghapus kode komentar apa pun yang saya temukan kecuali ada TODO atau CATATAN terlampir karena terlalu berbahaya untuk membiarkannya masuk. Intinya, saya telah menemukan kelas-kelas lama dengan bagian-bagian yang diberi komentar besar dan itu benar-benar membingungkan saya mengapa mereka apakah ada: apakah mereka baru-baru ini dikomentari? apakah ini perubahan lingkungan pengembang? mengapa itu melakukan blok yang tidak terkait ini?

Serius pertimbangkan untuk tidak mengomentari kode dan hanya menghapusnya saja. Jika Anda membutuhkannya, itu masih dalam kendali sumber. YAGNI sekalipun.

Penggunaan berlebihan / penyalahgunaan perintah #region. Ini hanya hal kecil, tetapi di C #, saya sebelumnya akan menggunakan arahan #region di semua tempat, untuk mengatur kelas saya. Misalnya, saya akan mengelompokkan semua properti kelas menjadi satu dalam satu wilayah.

Sekarang saya melihat kembali kode lama dan kebanyakan hanya merasa terganggu olehnya. Saya tidak berpikir itu benar-benar membuat segalanya menjadi lebih jelas sepanjang waktu, dan kadang-kadang itu hanya memperlambat Anda. Jadi saya sekarang telah berubah pikiran dan merasa bahwa kelas yang ditata dengan baik sebagian besar lebih bersih tanpa arahan wilayah.

Pengembangan air terjun secara umum, dan secara khusus, praktik penulisan spesifikasi fungsional dan desain yang lengkap dan komprehensif yang entah bagaimana diharapkan bersifat kanonik dan kemudian mengharapkan penerapannya menjadi benar dan dapat diterima. Saya telah melihatnya diganti dengan Scrum, dan pembebasan yang bagus, kataku. Fakta sederhananya adalah bahwa sifat berubah dari kebutuhan dan keinginan pelanggan membuat spesifikasi tetap tidak berguna secara efektif; satu-satunya cara untuk benar-benar mendekati masalah adalah dengan pendekatan berulang. Bukan berarti Scrum adalah peluru perak, tentu saja; Saya telah melihatnya disalahgunakan dan disalahgunakan berkali-kali. Tapi itu mengalahkan air terjun.

Tidak pernah crash.

Sepertinya ide yang bagus, bukan? Pengguna tidak menyukai program yang macet, jadi mari kita tulis program yang tidak macet, dan pengguna harus menyukai program tersebut, bukan? Begitulah cara saya memulai.

Saat ini, saya lebih cenderung berpikir bahwa jika tidak berhasil, seharusnya tidak berpura-pura berhasil. Gagal secepat mungkin, dengan pesan kesalahan yang bagus. Jika tidak, program Anda akan macet lebih parah hanya dalam beberapa instruksi kemudian, tetapi dengan beberapa kesalahan penunjuk-nol nondescript yang akan membawa Anda satu jam untuk debug.

Pola "jangan rusak" favorit saya adalah ini:

public User readUserFromDb(int id){
    User u = null;
    try {
        ResultSet rs = connection.execute("SELECT * FROM user WHERE id = " + id);
        if (rs.moveNext()){
            u = new User();
            u.setFirstName(rs.get("fname"));
            u.setSurname(rs.get("sname"));
            // etc
        }
    } catch (Exception e) {
        log.info(e);
    }
    if (u == null){
        u = new User();
        u.setFirstName("error communicating with database");
        u.setSurname("error communicating with database");
        // etc
    }
    u.setId(id);
    return u;
}

Sekarang, alih-alih meminta pengguna Anda untuk menyalin / menempel pesan kesalahan dan mengirimkannya kepada Anda, Anda harus menyelami log untuk mencoba menemukan entri log. (Dan karena mereka memasukkan ID pengguna yang tidak valid, tidak akan ada entri log.)

Saya pikir masuk akal untuk menerapkan pola desain setiap kali saya mengenalinya.

Sedikit yang saya tahu bahwa saya sebenarnya menyalin gaya dari bahasa pemrograman asing, sementara bahasa yang saya gunakan memungkinkan solusi yang jauh lebih elegan atau lebih mudah.

Menggunakan banyak bahasa (sangat) berbeda membuka mata saya dan membuat saya sadar bahwa saya tidak perlu salah menerapkan solusi orang lain untuk masalah yang bukan milik saya. Sekarang saya merinding saat melihat pola pabrik diterapkan dalam bahasa seperti Ruby.

Tes obsesif. Saya dulunya adalah pendukung fanatik pengembangan test-first. Untuk beberapa proyek, itu sangat masuk akal, tetapi saya telah menyadari bahwa tidak hanya tidak layak, tetapi juga merugikan banyak proyek untuk secara kasar mematuhi doktrin menulis pengujian unit untuk setiap bagian fungsionalitas.

Sungguh, dengan sembrono berpegang pada apa pun bisa merugikan.

Ini adalah hal kecil, tetapi: Peduli tentang ke mana tanda kurung kurawal (pada baris yang sama atau baris berikutnya?), Disarankan panjang baris kode maksimum, konvensi penamaan untuk variabel, dan elemen gaya lainnya. Saya telah menemukan bahwa setiap orang tampaknya lebih peduli tentang ini daripada saya, jadi saya hanya mengikuti arus dengan siapa pun saya bekerja saat ini.

Sunting: Pengecualian untuk makhluk ini, tentu saja, ketika saya yang paling peduli (atau orang yang berada dalam posisi untuk mengatur gaya untuk grup). Kalau begitu, saya melakukan apa yang saya inginkan!

(Perhatikan bahwa ini tidak sama dengan tidak memiliki gaya yang konsisten. Menurut saya gaya yang konsisten dalam basis kode sangat penting untuk keterbacaan.)

Mungkin "praktik pemrograman" paling penting yang telah saya ubah sejak itu, adalah gagasan bahwa kode saya lebih baik daripada kode orang lain. Ini biasa terjadi pada programmer (terutama pemula).

Perpustakaan utilitas. Saya biasa membawa-bawa majelis dengan berbagai metode pembantu dan kelas dengan teori bahwa saya dapat menggunakannya di tempat lain suatu hari nanti.

Pada kenyataannya, saya baru saja membuat namespace besar dengan banyak fungsionalitas yang tidak terorganisir dengan baik.

Sekarang, saya membiarkannya dalam proyek tempat saya membuatnya. Kemungkinan besar saya tidak akan membutuhkannya, dan jika saya membutuhkannya, saya selalu dapat mengubah mereka menjadi sesuatu yang dapat digunakan kembali nanti. Kadang-kadang saya akan menandai mereka dengan // TODO untuk kemungkinan ekstraksi menjadi majelis umum.

Mendesain lebih dari yang saya kodekan. Setelah beberapa saat, itu berubah menjadi kelumpuhan analisis.

Penggunaan DataSet untuk menjalankan logika bisnis. Ini mengikat kode terlalu erat ke database, juga DataSet biasanya dibuat dari SQL yang membuat segalanya menjadi lebih rapuh. Jika SQL atau Database berubah, ia cenderung menetes ke semua yang disentuh DataSet.

Melakukan logika bisnis apa pun di dalam konstruktor objek. Dengan warisan dan kemampuan untuk membuat konstruktor kelebihan beban cenderung membuat perawatan menjadi sulit.

Menyingkat variabel / metode / tabel / ... Nama

Saya biasa melakukan ini sepanjang waktu, bahkan ketika bekerja dalam bahasa tanpa batasan yang dipaksakan pada panjang nama (mungkin 255 atau sesuatu). Salah satu efek sampingnya adalah banyak komentar berserakan di seluruh kode yang menjelaskan singkatan (non-standar). Dan tentu saja, jika nama diubah karena alasan apa pun ...

Sekarang saya lebih suka menyebut segala sesuatu sebagaimana adanya, dengan nama deskriptif yang bagus. termasuk singkatan standar saja. Tidak perlu menyertakan komentar yang tidak berguna, dan kodenya jauh lebih mudah dibaca dan dimengerti.

Membungkus komponen Akses Data yang ada, seperti Enterprise Library, dengan lapisan kustom metode pembantu.

• Itu tidak membuat hidup siapa pun lebih mudah
• Lebih banyak kode yang dapat memiliki bug di dalamnya
• Banyak orang tahu bagaimana menggunakan komponen akses data EntLib. Tidak seorang pun kecuali tim lokal yang tahu cara menggunakan solusi akses data internal

Saya pertama kali mendengar tentang pemrograman berorientasi objek saat membaca tentang Smalltalk pada tahun 1984, tetapi saya tidak memiliki akses ke bahasa oo sampai saya menggunakan kompiler C ++ cfront pada tahun 1992. Saya akhirnya menggunakan Smalltalk pada tahun 1995. Saya telah mengantisipasi dengan penuh semangat oo teknologi, dan membeli gagasan bahwa itu akan menghemat pengembangan perangkat lunak.

Sekarang, saya hanya melihat oo sebagai salah satu teknik yang memiliki beberapa kelebihan, tetapi itu hanya satu alat di kotak peralatan. Saya melakukan sebagian besar pekerjaan saya dengan Python, dan saya sering menulis fungsi mandiri yang bukan anggota kelas, dan saya sering mengumpulkan kelompok data dalam tupel atau daftar di mana di masa lalu saya akan membuat kelas. Saya masih membuat kelas ketika struktur datanya rumit, atau saya memerlukan perilaku yang terkait dengan data, tetapi saya cenderung menolaknya.

Saya sebenarnya tertarik untuk melakukan beberapa pekerjaan di Clojure ketika saya punya waktu, yang tidak menyediakan fasilitas, meskipun bisa menggunakan objek Java jika saya mengerti dengan benar. Saya belum siap untuk mengatakan hal seperti oo sudah mati, tapi secara pribadi saya bukan penggemar seperti dulu.

Di C #, gunakan _notationuntuk anggota pribadi. Sekarang saya pikir itu jelek.

Saya kemudian mengubah menjadi this.notationuntuk anggota pribadi, tetapi ternyata saya tidak konsisten dalam menggunakannya, jadi saya membatalkannya juga.

Saya berhenti mengikuti metode desain yang direkomendasikan universitas sebelum implementasi. Bekerja dalam sistem yang kacau dan rumit telah memaksa saya untuk mengubah sikap.

Tentu saja saya masih melakukan riset kode, terutama ketika saya akan menyentuh kode yang belum pernah saya sentuh sebelumnya, tetapi biasanya saya mencoba untuk fokus pada implementasi sekecil mungkin untuk memulai sesuatu terlebih dahulu. Inilah tujuan utamanya. Kemudian secara bertahap perbaiki logika dan biarkan desain muncul dengan sendirinya. Pemrograman adalah proses berulang dan bekerja sangat baik dengan pendekatan yang gesit dan banyak refactoring.

Kode tidak akan melihat sama sekali seperti yang pertama kali Anda pikirkan. Terjadi setiap saat :)

Saya dulu sangat menyukai desain demi kontrak. Ini berarti menempatkan banyak pemeriksaan kesalahan di awal semua fungsi saya. Kontrak masih penting, dari perspektif pemisahan masalah, tetapi alih-alih mencoba memaksakan apa yang seharusnya tidak dilakukan kode saya, saya mencoba menggunakan pengujian unit untuk memverifikasi apa yang dilakukannya.

Saya akan menggunakan statis di banyak metode / kelas karena lebih ringkas. Ketika saya mulai menulis tes, praktik itu berubah dengan sangat cepat.

Pengecualian yang Dicentang

Ide luar biasa di atas kertas - mendefinisikan kontrak dengan jelas, tidak ada ruang untuk kesalahan atau lupa memeriksa beberapa kondisi pengecualian. Saya dijual ketika saya pertama kali mendengarnya.

Tentu saja, itu berubah menjadi berantakan dalam praktiknya. Sampai saat ini memiliki perpustakaan seperti Spring JDBC, yang menyembunyikan pengecualian yang diperiksa sebelumnya sebagai salah satu fitur utamanya.

Bahwa sesuatu yang berharga hanya diberi kode dalam satu bahasa tertentu. Dalam kasus saya, saya percaya bahwa C adalah bahasa terbaik yang pernah ada dan saya tidak pernah punya alasan untuk membuat kode apa pun dalam bahasa lain ... selamanya.

Sejak saat itu, saya menghargai banyak bahasa yang berbeda dan manfaat / fungsionalitas yang mereka tawarkan. Jika saya ingin membuat kode sesuatu yang kecil - dengan cepat - saya akan menggunakan Python. Jika saya ingin mengerjakan proyek besar, saya akan membuat kode dalam C ++ atau C #. Jika saya ingin mengembangkan tumor otak, saya akan membuat kode di Perl .

Ketika saya perlu melakukan refactoring, saya pikir itu lebih cepat dan lebih bersih untuk langsung memulai dan menerapkan desain baru, memperbaiki koneksi sampai berfungsi. Kemudian saya menyadari lebih baik melakukan serangkaian refactoring kecil untuk secara perlahan tapi andal maju ke arah desain baru.

Mungkin hal terbesar yang telah berubah dalam praktik pengkodean saya, serta dalam praktik lainnya, adalah penerimaan kelas dan perpustakaan luar yang diunduh dari internet sebagai dasar untuk perilaku dan fungsionalitas dalam aplikasi. Di sekolah pada saat saya kuliah, kami didorong untuk mencari cara bagaimana membuat segalanya lebih baik melalui kode kami sendiri dan mengandalkan bahasa untuk memecahkan masalah kami. Dengan kemajuan dalam semua aspek antarmuka pengguna dan layanan / konsumsi data, ini bukan lagi gagasan yang realistis.

Ada hal-hal tertentu yang tidak akan pernah berubah dalam suatu bahasa, dan memiliki perpustakaan yang membungkus kode ini dalam transaksi yang lebih sederhana dan dalam beberapa baris kode yang harus saya tulis adalah sebuah berkah. Menghubungkan ke database akan selalu sama. Memilih elemen dalam DOM tidak akan berubah. Mengirim email melalui skrip sisi server tidak akan pernah berubah. Harus menulis ini berkali-kali membuang-buang waktu yang bisa saya gunakan untuk meningkatkan logika inti saya dalam aplikasi.

Memulai semua anggota kelas.

Saya dulu secara eksplisit menginisialisasi setiap anggota kelas dengan sesuatu, biasanya NULL. Saya telah menyadari bahwa ini:

• biasanya berarti bahwa setiap variabel diinisialisasi dua kali sebelum dibaca
• konyol karena dalam kebanyakan bahasa secara otomatis menginisialisasi variabel ke NULL.
• sebenarnya memaksakan sedikit kinerja dalam kebanyakan bahasa
• dapat mengasapi kode pada proyek yang lebih besar

Seperti Anda, saya juga telah menganut pola IoC dalam mengurangi kopling antara berbagai komponen aplikasi saya. Itu membuat perawatan dan penggantian suku cadang menjadi lebih sederhana, selama saya bisa menjaga setiap komponen independen mungkin. Saya juga menggunakan lebih banyak kerangka relasional objek seperti NHibernate untuk menyederhanakan tugas manajemen basis data.

Singkatnya, saya menggunakan kerangka "mini" untuk membantu membangun perangkat lunak dengan lebih cepat dan efisien. Kerangka kerja mini ini menghemat banyak waktu, dan jika dilakukan dengan benar dapat membuat aplikasi menjadi sangat mudah dikelola. Plug 'n Play untuk menang!