Apakah praktik pemrograman yang buruk khas dalam industri perangkat lunak? [Tutup]

Saya baru saja memulai pekerjaan pertama saya sebagai pengembang perangkat lunak lebih dari sebulan yang lalu. Semua yang saya pelajari tentang OOP, SOLID , KERING , YAGNI, pola desain, SRP , dll. Dapat dibuang keluar jendela.

Mereka menggunakan C # .NET Webforms dan melakukan hampir semua yang ada dalam Code Behind dengan sangat sedikit Kelas eksternal, jelas tidak disebut objek. Mereka memang menggunakan kontrol khusus dan menggunakannya kembali. Tentang satu-satunya objek yang digunakan adalah oleh Entity Framework . Mereka menggunakan kembali Kode Di Balik untuk setiap klien. Mereka memiliki metode yang panjang 400 baris melakukan semua jenis barang. Untuk klien baru, mereka mengambil aspx dan aspx.cs dan menghapus kode klien dan mulai menambahkan kode khusus klien baru.

Alasan pertama mereka adalah menambahkan perawatan tambahan, dan lebih banyak kode adalah lebih banyak perawatan. Ini adalah toko kecil dari tiga pengembang termasuk saya. Satu pengembang memiliki lebih dari 30 tahun pengalaman dan yang lainnya memiliki 20+ tahun pengalaman. Satu digunakan untuk menjadi pengembang game dan yang lainnya selalu bekerja di C dan C ++.

Seberapa umum hal ini dalam industri perangkat lunak? Bagaimana saya bisa memastikan bahwa saya tetap di atas OOP dan prinsip-prinsip terkait? Saya berlatih di waktu luang, dan saya merasa saya benar-benar perlu bekerja di bawah pengembang yang lebih berpengalaman untuk menjadi lebih baik di OOP.

1. Prinsip-prinsip yang Anda kutip dalam pertanyaan Anda hanyalah ... prinsip. Itu bukan mandat, hukum atau perintah.
2. Sementara orang-orang yang mengemukakan prinsip-prinsip ini sangat cerdas, mereka bukan otoritas absolut. Mereka hanya orang-orang yang menawarkan wawasan dan bimbingan mereka.
3. Tidak ada cara yang "benar" untuk memprogram. Ini dibuktikan oleh fakta bahwa cara "diterima" yang kita lakukan telah berubah, dan terus berubah, secara radikal seiring waktu.
4. Pengiriman produk seringkali dapat diutamakan daripada melakukannya dengan cara yang "benar". Ini adalah praktik yang lazim sehingga memiliki nama: Hutang Teknis.

5. Beberapa arsitektur perangkat lunak yang umum digunakan tidak ideal. Praktik terbaik berkembang dari aplikasi monolitik yang besar ke arah koleksi modul yang longgar.

6. Konteks itu penting. Banyak prinsip arsitektur hanya membuktikan nilainya ketika Anda bekerja dengan program besar atau domain tertentu. Sebagai contoh, pewarisan sebagian besar berguna untuk hierarki UI dan struktur lain yang mendapat manfaat dari pengaturan yang bersarang dengan erat.

Jadi, bagaimana Anda mengikuti jalan "benar", jalan berprinsip, sehingga Anda dapat keluar dari hutan belantara?

1. Pelajari kesesuaian, alih-alih kebenaran. Cara "benar" untuk melakukan apa pun dalam pengembangan perangkat lunak adalah cara yang paling efektif memenuhi persyaratan spesifik Anda.
2. Belajar pengorbanan. Segala sesuatu dalam pengembangan perangkat lunak adalah tradeoff. Apakah Anda ingin lebih cepat atau lebih sedikit penggunaan memori? Apakah Anda ingin bahasa pemrograman yang sangat ekspresif dengan sedikit praktisi, atau bahasa yang kurang ekspresif yang diketahui banyak pengembang?

3. Belajar keabadian. Beberapa prinsip telah teruji oleh waktu dan akan selalu relevan. Sistem tipe bersifat universal. Fungsi kelas satu bersifat universal. Struktur data bersifat universal.

4. Pelajari pragmatisme. Menjadi praktis itu penting. Kemurnian matematika, arsitektur kristal-katedral dan prinsip menara gading tidak berguna jika Anda tidak bisa mengirimkannya.

5. Jadilah pengrajin, bukan fanatik. Pengembang perangkat lunak terbaik adalah mereka yang mengetahui aturan, dan kemudian tahu cara melanggarnya ketika masuk akal untuk melakukannya. Merekalah yang masih tahu bagaimana memecahkan masalah dan berpikir sendiri. Mereka menggunakan prinsip untuk menginformasikan dan membimbing pilihan mereka, bukan mendikte mereka.
6. Tulis kode Banyak sekali. Prinsip-prinsip desain perangkat lunak adalah optimasi prematur sampai Anda telah menulis banyak kode dan mengembangkan naluri bagaimana menerapkannya dengan benar.

Ini tidak biasa. Satu hal yang perlu disadari adalah bahwa industri perangkat lunak sangat beragam. Beberapa perusahaan terdepan. Universitas-universitas terkemuka dan perusahaan perangkat lunak inovatif (bahkan beberapa laboratorium di perusahaan besar!) Serta orang-orang atau kelompok-kelompok yang diberkati seperti geng beranggotakan empat orang menganalisis masalah yang terjadi dengan cara-cara umum untuk melakukan sesuatu dan menciptakan bahasa, mesin, alat, dan pola baru. Perusahaan baru, sering spin-off atau split-off, mencoba menggunakannya secara komersial, dan terkadang sukses luar biasa. Pikirkan Facebook atau Google.

Tetapi perangkat lunak digunakan hampir di mana-mana saat ini, mungkin sebagian besar di perusahaan yang sebenarnya bukan perusahaan perangkat lunak. Saya kebanyakan bekerja di industri transportasi (otomotif dan kereta api), dan ada banyak pengalaman. Tapi tak satu pun dari mereka yang mendekati "ujung tombak". Terkadang mereka tidak bisa; keamanan perangkat lunak yang relevan tergantung pada alat yang diperiksa dengan baik (kami saat ini menggunakan kompiler C ++ yang divalidasi dari tahun 1990-an). Terkadang mereka tidak memiliki orang yang tepat. Seringkali perangkat lunak dikembangkan oleh para insinyur di bidang lain yang kebetulan meluncur ke pengembangan perangkat lunak di perusahaan mereka ketika perangkat lunak menjadi semakin penting. Seseorang tidak dapat mengharapkan mereka untuk mengetahui atau menggunakan prinsip-prinsip rekayasa perangkat lunak.

Hal lain yang perlu dipertimbangkan adalah apa yang penting dalam seorang insinyur di dunia nyata. Seringkali tugas yang dihadapi adalah, secara harfiah, bukan ilmu roket. Masalah roti-dan-mentega di perusahaan non-perangkat lunak dapat diselesaikan dengan cara perangkat lunak sederhana. Apa yang membuat seorang insinyur perangkat lunak yang berguna, bahkan mungkin baik adalah sebagian yang membuat seorang insinyur umum yang baik: Dapat diandalkan; mengatur dan mendokumentasikan pekerjaan Anda secara bertanggung jawab; menjadi kooperatif; buat estimasi biaya dan waktu yang baik (validitas estimasi lebih penting daripada biaya dan waktu aktual!); memahami apa yang bisa dan tidak bisa Anda lakukan. Yang sangat hilang di sini adalah "ketahui dan gunakan alat dan prosedur canggih". Apa yang Anda gambarkan adalah perusahaan yang telah menetapkan seperangkat alat dan proses yang sesuai untuk mereka. Mereka mungkin tidak akan pernah menghasilkan sesuatu yang seksi atau luar biasa, tetapi mereka memenuhi permintaan pelanggan dengan cukup baik untuk menghasilkan aliran pendapatan yang cukup. Itu bisa menjadi definisi teknik ;-).

Jadi ya: Apa yang Anda pelajari di universitas sebenarnya tidak umum di banyak bidang.

Saya ingin menambahkan sedikit penghiburan, atau nada yang lebih optimis. Apa yang Anda pelajari tidak boleh dibuang ke luar jendela. Anda dapat menerapkan prinsip yang lebih baik dalam pekerjaan sehari-hari Anda di mana itu tidak merusak banyak hal. Mungkin akan ada jendela peluang untuk memperkenalkan alat atau pola desain baru. Peluang terbaik adalah ketika cara lama dalam melakukan sesuatu tidak menyenangkan bagi kolega, atau jika mereka mengalami masalah dengan mengelola kompleksitas atau pemeliharaan (dua masalah paling ganas yang ditangani oleh inovasi). Bersiaplah untuk menawarkan peningkatan ketika ada peluang. Menjadi pengaruh positif dan secara bertahap meningkatkan metode dan alat; sebarkan pengetahuan di mana itu dihargai.

Mereka menggunakan C # .Net Webforms dan melakukan hampir semua yang ada dalam Code Behind dengan Kelas Eksternal yang sangat sedikit

Ada penjelasan Anda di sana. Jika Anda tidak sadar, kode Formulir Web out-of-the-box cukup banyak kebalikan dari OOP, SOLID, KERING, YAGNI, Pola Desain, SRP , dll. Bahkan contoh resmi dari Microsoft dari beberapa tahun yang lalu akan membuat Anda ngeri hari ini.

Formulir Web mendorong dirinya sendiri ke arah alur prosedural, dengan beberapa "acara" palsu dipicu oleh klik kontrol dan sejenisnya. Pengembang yang menghabiskan banyak waktu dalam membuat Formulir Web juga biasanya tampak enggan untuk menyimpang dari itu juga, mungkin karena mereka tenggelam begitu banyak waktu untuk mempelajari siklus hidup halaman dan bagaimana melakukan kontrol yang diberikan secara dinamis sehingga mereka enggan membuang pengetahuan itu sekarang. dalam menghadapi metode yang lebih baru / lebih baik. Versi yang tidak disadari dari kekeliruan biaya sunk. Para dev ini telah menghabiskan waktu bertahun-tahun untuk belajar bagaimana mengatasi Formulir Web, dan sekarang tidak akan dengan mudah menyimpang dari keahlian itu, karenanya pembicaraan mereka tentang waktu "pemeliharaan".

Dan ini cukup umum di ruang .NET Web Forms, btw.

Seberapa umum hal ini dalam industri perangkat lunak?

Sangat umum. Tentang kesamaan yang sama seperti memiliki tukang ledeng menghancurkan pipa ledeng Anda, tukang kayu yang memberikan sampah, atau penjahit murah yang membuat setelan jas yang tidak pas. Yaitu, itu semua manusia.

Ada alasan bagus mengapa ini terjadi: orang yang tidak benar-benar terlatih (atau tidak antusias) harus mengimplementasikan sesuatu di bawah tekanan.

Ini bukan masalah orang-orang itu, terutama, tetapi biasanya dari struktur seputar pengembangan perangkat lunak di perusahaan itu. Sebagai contoh, sebuah perusahaan mungkin memiliki sekelompok pekerja magang mengembangkan perangkat lunak internal mereka; bahkan jika pekerja magang itu cerdas dan berpengetahuan luas, mereka hanya akan berada di sana selama beberapa minggu atau bulan, dan kepemilikan akan sering berubah.

Atau beberapa orang yang hebat dalam domain, tetapi bukan seorang programmer, mungkin meretas bersama beberapa aplikasi VBA dll karena tampaknya cukup mudah di awal.

Atau aplikasi yang dibuat dengan baik berakhir pada fase pemeliharaan, semua pengembang yang baik melanjutkan, dan kemudian terus dikembangkan oleh beberapa orang (kasus terburuk: satu) yang tahu sedikit tentang hal itu, yang tidak memiliki dokumentasi, dll.

Bagaimana saya bisa memastikan bahwa saya tetap di atas OOP dan prinsip-prinsip terkait? Saya berlatih di waktu luang dan saya merasa perlu bekerja di bawah pengembang yang lebih berpengalaman untuk menjadi lebih baik di OOP.

Ada dua kemungkinan jawaban:

• Baik: diskusikan ini dengan bos Anda dan pastikan Anda masuk ke proyek bersih. Jika tidak memungkinkan, cari bos baru.
• Atau: bertanggung jawab untuk ini sendiri. Itu berarti melakukannya sendiri - di waktu luang Anda, atau jika Anda bisa, di perusahaan, tetapi didorong oleh diri sendiri (tidak mungkin).

Jika jawaban kedua terdengar terlalu sinis untuk Anda, maka izinkan saya meyakinkan Anda bahwa jawabannya tidak. Seorang tukang kayu yang memiliki toko woodworking di rumah akan paling pasti menjadi tukang kayu yang lebih baik daripada orang yang tidak.

Sebagai contoh, sangat mungkin dan sangat menyenangkan bagi sebagian orang untuk, misalnya, menggali ke dalam bahasa baru seperti Ruby, belajar tidak hanya sintaksis, tetapi juga dalam aspek OO khusus dari bahasa itu, dan benar-benar menyelam dalam-dalam. Semua ada di waktu luang Anda, tanpa memiliki koneksi ke pekerjaan Anda. Itu hanya akan menjadi hobi, tetapi menjadi profesional terlatih seperti Anda, itu bisa sama efektifnya (atau lebih tepatnya) dengan duduk di sebelah pengembang utama dan mencoba mengikuti apa yang mereka lakukan. Ini kemudian akan semata-mata untuk pengembangan pribadi Anda dan kesenangan Anda sendiri. Jika Anda tidak bersenang-senang melakukan ini, atau jika Anda merasa tidak dapat mencapai pemahaman apa pun, goreskan itu, dan kembali ke jawaban pertama.

Bahwa pengembang memimpin yang melatih Anda telah cukup mungkin belajar hal-hal yang persis dengan cara ini ...

Saya berpikir bahwa di Spanyol adalah konstan karena ketika seorang pengembang melewati bertahun-tahun di sebuah perusahaan, dia (atau dia) biasanya dipromosikan ke bidang manajemen yang lebih seperti analisis dan manajemen proyek. Akibatnya tidak ada peer review yang dilakukan dan kode biasanya ditulis oleh orang yang kurang berpengalaman.

Kegagalan orang-orang yang berpengalaman ini tidak pernah diperbaiki: sebaliknya, satu-satunya fokus mereka adalah menyelesaikan pekerjaan. Akibatnya, semakin banyak praktik yang salah terakumulasi dalam kode.

Akhirnya beberapa keledai pintar mengatakan bahwa "solusi" terbaik adalah mengubah teknologi yang muncul yang akan menghasilkan kode yang lebih bersih dan lebih dapat dikelola, menciptakan aplikasi baru. Seolah-olah teknologi itu sendiri dapat melakukan itu.

Sekali lagi, programmer yang tidak berpengalaman dimasukkan untuk bekerja dalam teknologi baru itu, tidak ada yang meninjau kode dan lingkaran ditutup lagi .... selama-lamanya ....

Beberapa "praktik terbaik" yang Anda pelajari di sekolah tidak praktis atau hemat biaya pada proyek dunia nyata. Salah satu perubahan terbesar yang saya perhatikan adalah pemformatan dan komentar. Sebagian besar profesor saya menekankan pentingnya mendokumentasikan kode Anda secara ekstensif, tetapi di dunia nyata, kode yang baik sering (tidak selalu!) Jelas, dan yang lebih penting banyak bos tidak ingin membayar Anda untuk menghabiskan waktu menulis komentar.

Terkadang Anda akan melihat programmer yang menekan waktu menggunakan pintasan dan anti-pola yang membutuhkan pelat ketel lebih sedikit daripada solusi berkualitas.

Namun, salah satu masalah terbesar yang saya perhatikan di banyak tim dan proyek adalah keengganan untuk mempelajari hal-hal baru. Banyak programmer lama yang saya ajak bicara memulai karier mereka di periode 'Wild West' dalam rekayasa perangkat lunak ketika kualifikasi dimulai dan diakhiri dengan kemauan untuk menulis kode. Mereka sering mengambil jurusan yang benar-benar berbeda, dan terjun ke pemrograman dengan sedikit atau tanpa pendidikan formal ketika ada kesempatan (misalnya majikan mereka tidak memiliki programmer dan membutuhkan seseorang untuk belajar untuk membangun perangkat lunak internal). Beberapa pemrogram otodidak sekolah tua ini tidak pernah berupaya mempelajari praktik pengkodean modern, dan terus membuat kode dengan gaya apa pun yang mereka pelajari beberapa dekade lalu. Ketika mereka akhirnya bertanggung jawab atas proyek baru karena senioritas, mereka cenderung menahan proyek dan merusak kualitas kode secara keseluruhan.

Tentu saja hal di atas tidak berlaku untuk semua programmer yang lebih lama, dan coders generasi yang lebih baru bisa sama bersalahnya. Saya telah bekerja dengan banyak programmer yang lebih muda yang mengambil beberapa alat dan perpustakaan yang baru lulus dari perguruan tinggi dan kemudian berhenti belajar sepenuhnya. Mereka akan mengunduh IDE atau pustaka sekali dan tidak pernah memperbaruinya kecuali jika perusahaan mereka membutuhkannya (Anda kadang-kadang dapat menebak tahun berapa seorang lulusan lulus berdasarkan seberapa ketinggalan perpustakaannya). Mereka tidak mengikuti fitur baru dalam bahasa pilihan mereka, dan tidak pernah belajar bahasa baru. Mereka tidak mempelajari strategi pemrograman baru, dan dapat menyalahgunakan pola atau paradigma karena mereka tidak tahu alternatif yang lebih tepat (oh MVC, betapa beratnya Anda dilecehkan). Seiring berjalannya waktu, alur kerja mereka menjadi semakin usang, dan mereka menjadi lebih dari kewajiban daripada aset.

Ringkasnya, dua penyebab terbesar dari basis kode yang berantakan adalah tenggat waktu yang terburu-buru dan programmer dengan pengetahuan yang ketinggalan zaman atau tidak lengkap. Sayangnya, tanggung jawab untuk kedua masalah ini bisa sangat berat pada bos atau CTO, yang harus memastikan bahwa tenggat waktu realistis dan bahwa staf mutakhir tentang pengetahuan dan keterampilan mereka. Jika bos tidak tahu apa-apa tentang praktik pemrograman yang baik, yang terbaik yang dapat Anda lakukan adalah mencoba menyarankan perubahan dan berharap mereka terbuka untuk saran. Sayangnya, mereka cenderung percaya pada kata-kata programmer yang lebih senior yang tidak mengerti OOP dan suka menulis 10.000 kelas garis.

Beberapa praktik pemrograman yang buruk dihasilkan dari keharusan bekerja dengan perangkat lunak lawas yang pertama kali memulai pengembangan beberapa dekade lalu. Jika ada perangkat lunak yang sangat kompleks, menulis ulang semuanya mungkin bukan pilihan. Bahkan mungkin sangat sulit untuk memahami segala sesuatu yang sebenarnya dilakukan oleh kode. Pilihan terbaik mungkin hanya menyalin apa yang berfungsi sambil juga mencoba mengintegrasikan praktik pemrograman yang lebih baik jika Anda dapat melakukannya tanpa merusak apa pun.

Saya pikir penting untuk tidak hanya mengatakan yang benar dari yang salah tetapi untuk mengetahui alasan di balik setiap benar dan salah. Ketika Anda tahu alasannya, Anda dapat memprediksi konsekuensi. Mengapa menggunakan prinsip ini atau itu bukan karena itu dijelaskan dalam sebuah buku, tetapi karena kita tahu bagaimana itu membantu dan apa yang sebenarnya terjadi jika kita melanggarnya. Jika Anda tahu apa yang terjadi ketika Anda dapat mempertimbangkan pro dan kontra dan membuat keputusan. Ini juga akan membantu Anda memperdebatkan posisi Anda setiap kali. SOLID dan OOP juga dapat mengurangi pemeliharaan jika digunakan dengan baik.

SOLID jika digunakan terlalu dogmatis mengarah ke terlalu banyak kelas dan metode yang tidak sebagus itu juga. Jangan berlebihan. Ini sebagian merupakan masalah besar dengan buku pelajaran dan tutorial kami karena mereka sering mencoba mempromosikan ide tanpa pembenaran yang tepat. OOP juga memiliki kontra. Banyak prinsip dan paradigma yang saling bertentangan. Anda tidak perlu berada di atas, Anda harus membuat semuanya masuk akal, dibenarkan, anggun, dan sederhana.

Juga, karena ini adalah pekerjaan pertama Anda, kemungkinan programmer ini tidak terlalu ahli. Tetapi sekali lagi, mereka mungkin dipercaya dengan tugas-tugas yang tidak terlalu sulit yang dapat dilakukan tanpa banyak keterampilan dan untuk gaji yang lebih rendah dengan coders murah yang kurang terampil. Begini cara ekonomi bekerja. Setiap tempat kerja berbeda.

Saya mengerti bagaimana perasaan anda. Jangan panik . Anda akan membutuhkan apa yang Anda ketahui, mungkin tidak segera, tetapi itu akan membantu Anda. Mungkin di tempat kerja yang berbeda, mungkin di beberapa kesempatan. Anda punya waktu di depan Anda untuk melangkah lebih jauh.