Apa pendapat Anda tentang pemrograman yang paling kontroversial?

Ini pasti subyektif, tetapi saya ingin mencoba agar tidak menjadi argumentatif. Saya pikir itu bisa menjadi pertanyaan yang menarik jika orang memperlakukannya dengan tepat.

Gagasan untuk pertanyaan ini berasal dari utas komentar dari jawaban saya terhadap "Apa lima hal yang Anda benci tentang bahasa favorit Anda?" pertanyaan . Saya berpendapat bahwa kelas dalam C # harus disegel secara default - Saya tidak akan memasukkan alasan saya dalam pertanyaan, tetapi saya mungkin menulis penjelasan yang lebih lengkap sebagai jawaban untuk pertanyaan ini. Saya terkejut dengan panasnya diskusi di komentar (25 komentar saat ini).

Jadi, apa pendapat Anda ? Saya lebih suka menghindari hal-hal yang akhirnya menjadi sangat religius dengan dasar yang relatif sedikit (misalnya menempatkan penjepit) tetapi contoh-contoh mungkin termasuk hal-hal seperti "unit testing sebenarnya tidak sangat membantu" atau "bidang publik benar-benar oke". Yang penting (bagi saya, bagaimanapun) adalah bahwa Anda punya alasan di balik pendapat Anda.

Mohon sampaikan pendapat dan alasan Anda - saya akan mendorong orang untuk memilih pendapat yang diperdebatkan dengan baik dan menarik, baik Anda kebetulan setuju atau tidak dengan mereka.

Programmer yang tidak membuat kode di waktu luang mereka untuk bersenang-senang tidak akan pernah sebaik yang melakukannya.

Saya pikir bahkan orang yang paling cerdas dan paling berbakat tidak akan pernah menjadi programmer yang benar-benar baik kecuali mereka memperlakukannya lebih dari sekedar pekerjaan. Berarti mereka melakukan proyek kecil di samping, atau hanya mengacaukan banyak bahasa dan ide yang berbeda di waktu luang mereka.

(Catatan: Saya tidak mengatakan programmer yang baik tidak melakukan apa-apa selain pemrograman, tetapi mereka melakukan lebih dari program dari jam 9 sampai jam 5)

Satu-satunya "praktik terbaik" yang harus Anda gunakan sepanjang waktu adalah "Gunakan Otak Anda".

Terlalu banyak orang yang menggunakan terlalu banyak kereta musik dan mencoba memaksakan metode, pola, kerangka kerja dll ke hal-hal yang tidak menjamin mereka. Hanya karena sesuatu itu baru, atau karena seseorang yang dihormati memiliki pendapat, tidak berarti itu cocok untuk semua :)

EDIT: Hanya untuk mengklarifikasi - Saya tidak berpikir orang harus mengabaikan praktik terbaik, pendapat yang dihargai dll. Hanya saja orang tidak boleh hanya secara membabi buta melompat pada sesuatu tanpa memikirkan MENGAPA "hal" ini begitu hebat, IS itu berlaku untuk apa yang saya Sedang melakukan, dan APA manfaat / kelemahan yang dibawanya?

"Googling it" tidak apa-apa!

Ya, saya tahu itu menyinggung beberapa orang di luar sana bahwa tahun-tahun mereka menghafal yang intens dan / atau tumpukan buku pemrograman mulai jatuh di pinggir jalan ke sumber daya yang dapat diakses siapa pun dalam hitungan detik, tetapi Anda tidak boleh berpegang teguh pada orang-orang yang menggunakannya.

Terlalu sering saya mendengar jawaban googling untuk masalah hasil kritik, dan itu benar-benar tidak masuk akal. Pertama-tama, harus diakui bahwa setiap orang membutuhkan bahan untuk referensi. Anda tidak tahu segalanya dan Anda perlu mencari sesuatu. Mengakui itu, apakah benar-benar masalah dari mana Anda mendapatkan informasi itu? Apakah penting jika Anda mencarinya di sebuah buku, mencarinya di Google, atau mendengarnya dari katak yang berbicara bahwa Anda berhalusinasi? Tidak. Jawaban yang benar adalah jawaban yang benar.

Yang penting adalah bahwa Anda memahami materi, menggunakannya sebagai sarana untuk mengakhiri solusi pemrograman yang sukses, dan klien / atasan Anda senang dengan hasilnya.

(walaupun jika Anda mendapatkan jawaban dari katak berbicara berhalusinasi, Anda mungkin harus mendapatkan bantuan sama saja)

Sebagian besar komentar dalam kode sebenarnya merupakan bentuk duplikasi kode yang merusak.

Kami menghabiskan sebagian besar waktu kami mempertahankan kode yang ditulis oleh orang lain (atau diri kami sendiri) dan komentar yang buruk, salah, ketinggalan zaman, menyesatkan harus berada di dekat bagian atas daftar artefak yang paling menjengkelkan dalam kode.

Saya pikir pada akhirnya banyak orang yang hanya mengosongkannya, terutama kelainan flowerbox itu.

Jauh lebih baik untuk berkonsentrasi membuat kode dapat dibaca, refactoring seperlunya, dan meminimalkan idiom dan quirkiness.

Di sisi lain, banyak kursus mengajarkan bahwa komentar hampir lebih penting daripada kode itu sendiri, mengarah ke baris berikutnya ini menambahkan satu ke gaya komentar faktur .

XML sangat berlebihan

Saya pikir terlalu banyak melompat ke kereta XML sebelum menggunakan otak mereka ... XML untuk hal-hal web sangat bagus, karena dirancang untuk itu. Kalau tidak, saya pikir beberapa definisi masalah dan pemikiran desain harus mendahului keputusan apa pun untuk menggunakannya.

5 sen saya

Tidak semua programmer diciptakan sama

Cukup sering manajer berpikir bahwa DeveloperA == DeveloperB hanya karena mereka memiliki tingkat pengalaman yang sama dan seterusnya. Pada kenyataannya, kinerja satu pengembang dapat 10x atau bahkan 100x yang lain.

Secara politis berisiko membicarakannya, tetapi kadang-kadang saya merasa ingin menunjukkan hal itu, meskipun beberapa anggota tim tampaknya memiliki keahlian yang sama, tidak selalu demikian. Saya bahkan telah melihat kasus-kasus di mana pengembang utama 'di luar harapan' dan pengembang junior melakukan semua pekerjaan yang sebenarnya - saya memastikan mereka mendapat pujian. :)

Saya gagal memahami mengapa orang berpikir bahwa Jawa benar-benar bahasa pemrograman "pertama" terbaik untuk diajarkan di universitas.

Untuk satu, saya percaya bahwa bahasa pemrograman pertama harus sedemikian rupa sehingga menyoroti kebutuhan untuk belajar aliran kontrol dan variabel, bukan objek dan sintaksis

Untuk yang lain, saya percaya bahwa orang yang belum memiliki pengalaman dalam debugging kebocoran memori di C / C ++ tidak dapat sepenuhnya menghargai apa yang dibawa Java ke tabel.

Juga perkembangan alami harus dari "bagaimana saya bisa melakukan ini" menjadi "bagaimana saya bisa menemukan perpustakaan yang melakukan itu" dan bukan sebaliknya.

Jika Anda hanya tahu satu bahasa, tidak peduli seberapa baik Anda mengetahuinya, Anda bukan programmer yang hebat.

Tampaknya ada sikap yang mengatakan begitu Anda benar-benar pandai C # atau Java atau bahasa lain apa pun yang Anda mulai pelajari maka hanya itu yang Anda butuhkan. Saya tidak percaya itu - setiap bahasa yang pernah saya pelajari telah mengajari saya sesuatu yang baru tentang pemrograman yang saya dapat bawa kembali ke pekerjaan saya dengan semua yang lain. Saya pikir siapa pun yang membatasi diri pada satu bahasa tidak akan pernah sebaik mereka.

Ini juga menunjukkan kepada saya kurangnya ketidaktahuan dan kemauan untuk bereksperimen yang tidak selalu cocok dengan kualitas yang saya harapkan untuk menemukan dalam programmer yang benar-benar baik.

Kinerja memang penting.

Pernyataan cetak adalah cara yang valid untuk men-debug kode

Saya percaya itu baik-baik saja untuk men-debug kode Anda dengan mengotori dengan System.out.println(atau pernyataan cetak apa pun bekerja untuk bahasa Anda). Seringkali, ini bisa lebih cepat daripada debugging, dan Anda dapat membandingkan hasil cetak dengan menjalankan aplikasi lainnya.

Pastikan untuk menghapus pernyataan cetak ketika Anda pergi ke produksi (atau lebih baik, ubah menjadi pernyataan logging)

Pekerjaan Anda adalah membuat diri Anda tidak bekerja.

Saat Anda menulis perangkat lunak untuk atasan Anda, perangkat lunak apa pun yang Anda buat harus ditulis sedemikian rupa sehingga dapat diambil oleh pengembang mana pun dan dipahami dengan sedikit usaha. Ini dirancang dengan baik, ditulis dengan jelas dan konsisten, diformat dengan bersih, didokumentasikan di mana perlu, dibangun setiap hari seperti yang diharapkan, diperiksa ke dalam repositori, dan versi yang sesuai.

Jika Anda tertabrak bus, diberhentikan, dipecat, atau keluar dari pekerjaan, majikan Anda harus dapat menggantikan Anda dengan pemberitahuan sesaat, dan lelaki berikutnya dapat masuk ke peran Anda, mengambil kode Anda dan bangun dan berjalan dalam seminggu puncak. Jika dia tidak bisa melakukan itu, maka Anda telah gagal total.

Menariknya, saya menemukan bahwa memiliki tujuan itu telah membuat saya lebih berharga bagi atasan saya. Semakin saya berusaha untuk sekali pakai, semakin saya menjadi berharga bagi mereka.

1) lelucon Aplikasi Bisnis :

Saya pikir seluruh kerangka kerja "Enterprise" adalah asap dan cermin. J2EE, .NET, mayoritas kerangka kerja Apache dan sebagian besar abstraksi untuk mengelola hal-hal seperti itu menciptakan kompleksitas yang jauh lebih banyak daripada yang mereka pecahkan.

Ambil Java atau .NET ORM biasa, atau kerangka kerja MVC apa pun yang dianggap modern baik yang melakukan "sihir" untuk menyelesaikan tugas-tugas sederhana yang membosankan. Anda akhirnya menulis sejumlah besar XML boilerplate jelek yang sulit untuk divalidasi dan ditulis dengan cepat. Anda memiliki API masif di mana setengahnya hanya untuk mengintegrasikan pekerjaan API lain, antarmuka yang tidak mungkin didaur ulang, dan kelas abstrak yang diperlukan hanya untuk mengatasi ketidakfleksibelan Java dan C #. Kami tidak membutuhkan sebagian besar dari itu.

Bagaimana dengan semua server aplikasi yang berbeda dengan sintaks descriptor terkutuk mereka sendiri, basis data yang terlalu rumit dan produk-produk groupware?

Intinya bukan kompleksitas == buruk, tapi kompleksitas yang tidak perlu == buruk. Saya telah bekerja di instalasi perusahaan besar-besaran di mana beberapa di antaranya diperlukan, tetapi bahkan dalam sebagian besar kasus, beberapa skrip buatan sendiri dan antarmuka web sederhana adalah semua yang diperlukan untuk menyelesaikan sebagian besar kasus penggunaan.

Saya akan mencoba mengganti semua aplikasi enterprisey ini dengan kerangka kerja web sederhana, DB open source, dan konstruksi pemrograman sepele.

2) Tahun-pengalaman-diperlukan:

Kecuali jika Anda memerlukan konsultan atau teknisi untuk menangani masalah spesifik terkait aplikasi, API, atau kerangka kerja, maka Anda tidak benar-benar membutuhkan seseorang dengan pengalaman 5 tahun dalam aplikasi itu. Yang Anda butuhkan adalah pengembang / admin yang dapat membaca dokumentasi, yang memiliki pengetahuan domain dalam apa pun yang Anda lakukan, dan yang dapat belajar dengan cepat. Jika Anda perlu mengembangkan dalam beberapa jenis bahasa, pengembang yang baik akan mengambilnya dalam waktu kurang dari 2 bulan. Jika Anda memerlukan administrator untuk server web X, dalam dua hari ia seharusnya sudah membaca halaman manual dan newsgroup dan mempercepatnya. Kurang dari itu dan orang itu tidak sebanding dengan apa yang dia bayar.

3) Kurikulum tingkat umum "ilmu komputer":

Mayoritas derajat ilmu komputer dan rekayasa perangkat lunak adalah banteng. Jika bahasa pemrograman pertama Anda adalah Java atau C #, maka Anda melakukan sesuatu yang salah. Jika Anda tidak mendapatkan beberapa kursus yang penuh dengan aljabar dan matematika, itu salah. Jika Anda tidak mempelajari pemrograman fungsional, itu tidak lengkap. Jika Anda tidak dapat menerapkan invarian loop ke sepele untuk loop, Anda tidak layak mendapatkan garam sebagai ilmuwan komputer. Jika Anda keluar dengan pengalaman dalam bahasa x dan y dan orientasi objek, itu penuh dengan omong kosong. Seorang ilmuwan komputer nyata melihat bahasa dalam hal konsep dan sintaks yang digunakannya, dan melihat metodologi pemrograman sebagai salah satu di antara banyak, dan memiliki pemahaman yang baik tentang filosofi yang mendasari baik bahwa memilih bahasa baru, metode desain, atau bahasa spesifikasi harus sepele.

Getters dan Setters sangat sering digunakan

Saya telah melihat jutaan orang mengklaim bahwa bidang publik itu jahat, sehingga mereka menjadikannya pribadi dan menyediakan getter dan setter untuk mereka semua. Saya percaya ini hampir identik dengan membuat bidang publik, mungkin sedikit berbeda jika Anda menggunakan utas (tetapi umumnya tidak demikian) atau jika pengakses Anda memiliki logika bisnis / presentasi (setidaknya sesuatu yang 'aneh').

Saya tidak mendukung bidang publik, tetapi menentang membuat pengambil / penyetel (atau Properti) untuk semua orang, dan kemudian mengklaim bahwa melakukan itu adalah enkapsulasi atau menyembunyikan informasi ... ha!

MEMPERBARUI:

Jawaban ini telah menimbulkan beberapa kontroversi dalam komentar itu, jadi saya akan mencoba sedikit memperjelasnya (saya akan membiarkan yang asli tidak tersentuh karena itulah yang banyak dipilih orang).

Pertama-tama: siapa pun yang menggunakan bidang publik layak waktu penjara

Sekarang, menciptakan bidang swasta dan kemudian menggunakan IDE untuk secara otomatis menghasilkan getter dan setter untuk setiap satu dari mereka adalah seburuk seperti menggunakan bidang publik.

Banyak orang berpikir:

private fields + public accessors == encapsulation

Saya katakan (otomatis atau tidak) pembuatan pasangan pengambil / penyetel untuk bidang Anda secara efektif bertentangan dengan enkapsulasi yang Anda coba capai.

Terakhir, izinkan saya mengutip Paman Bob dalam topik ini (diambil dari bab 6 "Kode Bersih"):

Ada alasan mengapa kami merahasiakan variabel kami. Kami tidak ingin orang lain bergantung pada mereka. Kami ingin kebebasan untuk mengubah jenis atau implementasi mereka atas kemauan atau dorongan hati. Jadi, mengapa begitu banyak programmer secara otomatis menambahkan getter dan setter ke objek mereka, memperlihatkan bidang pribadi mereka seolah-olah mereka publik?

Diagram UML sangat dibesar-besarkan

Tentu saja ada diagram yang berguna misalnya diagram kelas untuk Pola Komposit , tetapi banyak diagram UML yang sama sekali tidak memiliki nilai.

Opini: SQL adalah kode. Perlakukan itu seperti itu

Yaitu, sama seperti C #, Java, atau bahasa objek / prosedur favorit lainnya, kembangkan gaya pemformatan yang mudah dibaca dan dipelihara.

Aku benci ketika aku melihat kode SQL berformat bebas ceroboh. Jika Anda berteriak ketika Anda melihat kedua gaya kurung kurawal pada halaman, mengapa atau mengapa Anda tidak berteriak ketika Anda melihat SQL atau SQL yang diformat gratis yang mengaburkan atau mengaburkan kondisi GABUNG?

Keterbacaan adalah aspek terpenting dari kode Anda.

Bahkan lebih dari sekadar kebenaran. Jika bisa dibaca, mudah diperbaiki. Ini juga mudah dioptimalkan, mudah diubah, mudah dimengerti. Dan semoga pengembang lain dapat belajar sesuatu darinya juga.

Jika Anda seorang pengembang, Anda harus dapat menulis kode

Saya melakukan cukup banyak wawancara tahun lalu, dan untuk bagian wawancara saya saya harus menguji cara orang berpikir, dan bagaimana mereka menerapkan algoritma sederhana-sedang di papan tulis. Saya awalnya mulai dengan pertanyaan seperti:

Mengingat bahwa Pi dapat diperkirakan menggunakan fungsi 4 * (1 - 1/3 + 1/5 - 1/7 + ...) dengan lebih banyak istilah yang memberikan akurasi lebih besar, tulislah fungsi yang menghitung Pi dengan akurasi 5 tempat desimal .

Ini masalah yang seharusnya membuat Anda berpikir, tetapi seharusnya tidak berada di luar jangkauan pengembang berpengalaman (bisa dijawab dalam sekitar 10 baris C #). Namun, banyak dari kandidat kami (yang seharusnya sudah diperiksa oleh agen) bahkan tidak dapat mulai menjawabnya, atau bahkan menjelaskan bagaimana mereka akan menjawabnya. Jadi setelah beberapa saat saya mulai mengajukan pertanyaan sederhana seperti:

Mengingat luas lingkaran diberikan oleh Pi kali jari-jari kuadrat, tulis fungsi untuk menghitung luas lingkaran.

Hebatnya, lebih dari setengah kandidat tidak dapat menulis fungsi ini dalam bahasa apa pun (saya dapat membaca bahasa paling populer sehingga saya membiarkan mereka menggunakan bahasa apa pun yang mereka pilih, termasuk pseudo-code). Kami memiliki "pengembang C #" yang tidak dapat menulis fungsi ini dalam C #.

Saya terkejut dengan ini. Saya selalu berpikir bahwa pengembang harus dapat menulis kode. Tampaknya, saat ini, ini adalah pendapat yang kontroversial. Tentu saja itu di antara kandidat wawancara!

Edit:

Ada banyak diskusi dalam komentar tentang apakah pertanyaan pertama itu baik atau buruk, dan apakah Anda harus mengajukan pertanyaan serumit ini dalam wawancara. Saya tidak akan membahas hal ini di sini (itu pertanyaan yang sama sekali baru) selain untuk mengatakan bahwa Anda sebagian besar kehilangan titik posting .

Ya, saya katakan orang tidak bisa membuat kemajuan dengan ini, tetapi pertanyaan kedua adalah sepele dan banyak orang juga tidak bisa membuat kemajuan dengan itu! Siapa pun yang menyebut diri mereka seorang pengembang harus dapat menulis jawaban untuk yang kedua dalam beberapa detik tanpa berpikir. Dan banyak yang tidak bisa.

Penggunaan notasi hungaria harus dihukum dengan kematian.

Itu harus cukup kontroversial;)

Pola desain lebih banyak merusak desain yang baik daripada membantu.

Desain perangkat lunak IMO, terutama desain perangkat lunak yang baik terlalu beragam untuk dapat ditangkap secara bermakna dalam pola, terutama dalam sejumlah kecil pola yang dapat diingat oleh orang - dan itu terlalu abstrak bagi orang untuk benar-benar mengingat lebih dari segelintir. Jadi mereka tidak banyak membantu.

Dan di sisi lain, terlalu banyak orang yang terpikat dengan konsep dan mencoba menerapkan pola di mana-mana - biasanya, dalam kode yang dihasilkan Anda tidak dapat menemukan desain yang sebenarnya antara semua Singleton (yang sama sekali tidak berarti) dan Pabrik Abstrak.

Lebih sedikit kode lebih baik daripada lebih banyak!

Jika pengguna mengatakan "itu saja?", Dan pekerjaan Anda tetap tidak terlihat, itu dilakukan dengan benar. Kemuliaan dapat ditemukan di tempat lain.

PHP payah ;-)

Buktinya ada di puding.

Unit Testing tidak akan membantu Anda menulis kode yang baik

Satu-satunya alasan untuk memiliki tes Unit adalah untuk memastikan bahwa kode yang sudah berfungsi tidak rusak. Menulis tes terlebih dahulu, atau menulis kode untuk tes itu konyol. Jika Anda menulis tes sebelum kode, Anda bahkan tidak akan tahu apa tepi kasus itu. Anda dapat memiliki kode yang lulus tes tetapi masih gagal dalam kondisi yang tidak terduga.

Dan lebih jauh lagi, pengembang yang baik akan menjaga kohesi rendah, yang akan membuat penambahan kode baru tidak menyebabkan masalah dengan hal-hal yang ada.

Bahkan, saya akan menggeneralisasi itu lebih jauh,

Kebanyakan "Praktik Terbaik" dalam Rekayasa Perangkat Lunak ada untuk menjaga programmer yang buruk dari melakukan terlalu banyak kerusakan .

Mereka ada di sana untuk berpegangan tangan pada pengembang yang buruk dan mencegah mereka membuat kesalahan bodoh. Tentu saja, karena sebagian besar pengembang buruk, ini adalah hal yang baik, tetapi pengembang yang baik harus mendapatkan izin.

Tulis metode kecil. Tampaknya programmer suka menulis metode loooong di mana mereka melakukan banyak hal yang berbeda.

Saya pikir suatu metode harus dibuat dimanapun Anda dapat menyebutkannya.

Tidak apa-apa menulis kode sampah sesekali

Terkadang hanya sepotong kode sampah yang cepat dan kotor yang diperlukan untuk memenuhi tugas tertentu. Pola, ORM, SRP, apa pun ... Membuang Konsol atau Aplikasi Web, menulis beberapa inline sql (terasa enak), dan menghapus persyaratan.

Kode == Desain

Saya bukan penggemar diagram UML yang canggih dan dokumentasi kode tanpa akhir. Dalam bahasa tingkat tinggi, kode Anda harus dapat dibaca dan dimengerti apa adanya. Dokumentasi dan diagram yang rumit tidak lagi mudah digunakan.

Berikut adalah artikel tentang topik Code as Design .

Pengembangan perangkat lunak hanyalah pekerjaan

Jangan salah paham, saya sangat menikmati pengembangan perangkat lunak. Saya telah menulis blog selama beberapa tahun terakhir tentang masalah ini. Saya telah menghabiskan cukup waktu di sini untuk memiliki> 5000 poin reputasi. Dan saya bekerja di sebuah perusahaan rintisan yang biasanya bekerja selama 60 jam seminggu dengan uang yang jauh lebih sedikit daripada yang saya dapat sebagai kontraktor karena timnya fantastis dan pekerjaannya menarik.

Tapi dalam skema besar, itu hanya pekerjaan.

Ini menempati peringkat penting di bawah banyak hal seperti keluarga, pacar saya, teman, kebahagiaan dll., Dan di bawah hal-hal lain saya lebih suka melakukan jika saya memiliki persediaan uang tunai yang tidak terbatas seperti mengendarai sepeda motor, kapal layar, atau snowboarding.

Saya pikir kadang-kadang banyak pengembang lupa bahwa pengembangan hanyalah sesuatu yang memungkinkan kita untuk memiliki hal-hal yang lebih penting dalam hidup (dan memilikinya dengan melakukan sesuatu yang kita nikmati) daripada menjadi tujuan akhir itu sendiri.

Saya juga berpikir tidak ada yang salah dengan memiliki binari dalam kontrol sumber .. jika ada alasan yang bagus untuk itu. Jika saya memiliki rakitan saya tidak memiliki sumber untuk, dan mungkin belum tentu berada di tempat yang sama pada setiap mesin devs, maka saya biasanya akan menempelkannya di direktori "binari" dan merujuknya dalam proyek menggunakan jalur relatif .

Cukup banyak orang yang berpikir saya harus dibakar di tiang pancang untuk menyebut "kendali sumber" dan "biner" dalam kalimat yang sama. Saya bahkan tahu tempat-tempat yang memiliki peraturan ketat yang mengatakan Anda tidak bisa menambahkannya.

Setiap pengembang harus terbiasa dengan arsitektur dasar komputer modern. Ini juga berlaku untuk pengembang yang menargetkan mesin virtual (mungkin lebih dari itu, karena mereka telah diberitahu berkali-kali bahwa mereka tidak perlu khawatir dengan manajemen memori dll.)

Arsitek / Desainer Perangkat Lunak Berlebihan

Sebagai pengembang, saya benci gagasan Arsitek Perangkat Lunak. Mereka pada dasarnya adalah orang-orang yang tidak lagi berkode penuh waktu, membaca majalah dan artikel, dan kemudian memberi tahu Anda cara mendesain perangkat lunak. Hanya orang yang benar-benar menulis perangkat lunak untuk mencari nafkah yang seharusnya melakukan itu. Saya tidak peduli jika Anda adalah pembuat kode terbaik dunia 5 tahun yang lalu sebelum Anda menjadi seorang Arsitek, pendapat Anda tidak berguna bagi saya.

Bagaimana itu kontroversial?

Sunting (untuk memperjelas): Saya pikir sebagian besar Arsitek Perangkat Lunak menjadi Analis Bisnis yang hebat (berbicara dengan pelanggan, persyaratan penulisan, tes, dll.), Saya hanya berpikir mereka tidak punya tempat dalam merancang perangkat lunak, tingkat tinggi atau sebaliknya.

Tidak ada pendekatan "satu ukuran untuk semua" untuk pembangunan

Saya terkejut bahwa ini pendapat yang kontroversial, karena menurut saya itu masuk akal. Namun, ada banyak entri di blog populer yang mempromosikan pendekatan "satu ukuran cocok untuk semua" untuk pengembangan, jadi saya pikir saya mungkin benar-benar minoritas.

Hal yang saya sudah melihat-sebut sebagai yang pendekatan yang benar untuk setiap proyek - sebelum informasi yang diketahui tentang hal itu - hal-hal seperti penggunaan Test Driven Development (TDD), Domain Driven Design (DDD), Object-Relational Mapping (ORM) , Agile (kapital A), Orientasi Objek (OO), dll. Yang mencakup segala sesuatu mulai dari metodologi hingga arsitektur hingga komponen. Semua dengan akronim yang bagus, tentu saja.

Orang-orang bahkan tampaknya melangkah lebih jauh dengan memasang lencana di blog mereka seperti "I'm Test Driven" atau serupa, seolah-olah kepatuhan mereka terhadap satu pendekatan tunggal apa pun rincian proyek proyek sebenarnya adalah hal yang baik .

Bukan itu.

Memilih metodologi, arsitektur, dan komponen yang benar, dll., Adalah sesuatu yang harus dilakukan berdasarkan per proyek , dan tidak hanya bergantung pada jenis proyek yang sedang Anda kerjakan dan persyaratan uniknya, tetapi juga ukuran dan kemampuannya. dari tim yang bekerja dengan Anda.