Bagaimana saya membuktikan atau menyangkal “benda-benda Tuhan” salah?

Ringkasan Masalah:

Singkat cerita, saya mewarisi basis kode dan tim pengembangan yang tidak diizinkan untuk saya ganti dan penggunaan Obyek Allah adalah masalah besar. Ke depan, saya ingin meminta kami mempertimbangkan kembali faktor-faktor tetapi saya mendapat balasan dari tim-tim yang ingin melakukan segalanya dengan Objects God "karena lebih mudah" dan ini berarti saya tidak akan diizinkan untuk memasukkan kembali faktor. Saya mendorong kembali dengan mengutip pengalaman saya selama bertahun-tahun dalam pengembangan, bahwa saya adalah bos baru yang disewa untuk mengetahui hal-hal ini, dll, dan begitu juga dengan pihak ketiga dari perwakilan penjualan akun perusahaan luar negeri, dan ini sekarang berada di tingkat eksekutif dan pertemuan saya adalah besok dan saya ingin masuk dengan banyak amunisi teknis untuk mengadvokasi praktik terbaik karena saya merasa akan lebih murah dalam jangka panjang (Dan saya pribadi merasa itulah yang dikhawatirkan pihak ketiga) bagi perusahaan.

Masalah saya adalah dari tingkat teknis, saya tahu itu jangka panjang yang baik tetapi saya mengalami masalah dengan jangka pendek ultra dan jangka 6 bulan, dan sementara itu sesuatu yang saya "tahu" saya tidak bisa membuktikannya dengan referensi dan sumber daya yang dikutip di luar satu orang (Robert C. Martin, alias Paman Bob), karena itulah yang saya diminta untuk lakukan karena saya diberitahu memiliki data dari satu orang dan hanya satu orang (Robert C Martin) tidak cukup baik dari argumen .

Pertanyaan:

Apa sajakah sumber daya yang dapat saya kutip secara langsung (Judul, tahun diterbitkan, nomor halaman, kutipan) oleh para ahli terkenal di bidang yang secara eksplisit mengatakan bahwa penggunaan "Dewa" Objek / Kelas / Sistem ini buruk (atau baik, karena kami mencari untuk solusi yang paling valid secara teknis)?

Penelitian yang telah saya lakukan:

1. Saya memiliki sejumlah buku di sini dan saya telah mencari indeks mereka untuk penggunaan kata-kata "objek dewa" dan "kelas dewa". Saya menemukan bahwa anehnya hampir tidak pernah digunakan dan salinan buku GoF yang saya miliki misalnya, tidak pernah menggunakannya (Setidaknya menurut indeks di depan saya) tetapi saya telah menemukannya di dua buku di bawah ini, tetapi saya ingin lebih Saya bisa menggunakan.
2. Saya memeriksa halaman Wikipedia untuk "God Object" dan saat ini tulisan rintisan dengan sedikit tautan referensi jadi meskipun saya pribadi setuju dengan yang dikatakannya, itu tidak memiliki banyak yang bisa saya gunakan di lingkungan di mana pengalaman pribadi tidak dianggap valid. Buku yang dikutip juga dianggap terlalu tua untuk valid oleh orang-orang yang saya perdebatkan dengan poin-poin teknis dengan argumen yang mereka buat adalah bahwa "dulu dianggap buruk tetapi tidak ada yang bisa membuktikannya, dan sekarang perangkat lunak modern mengatakan" tuhan "Objek bagus untuk digunakan". Saya pribadi percaya bahwa pernyataan ini tidak benar, tetapi saya ingin membuktikan kebenaran, apa pun itu.
3. Dalam Robert C Martin "Prinsip Agile, Pola, dan Praktek di C #" (ISBN: 0-13-185725-8, hardcover) di mana di halaman 266 itu menyatakan "Semua orang tahu bahwa kelas dewa adalah ide yang buruk. Kami tidak ingin untuk memusatkan semua kecerdasan suatu sistem menjadi satu objek atau fungsi tunggal. Salah satu tujuan OOD adalah mempartisi dan mendistribusikan perilaku ke dalam banyak kelas dan banyak fungsi. " - Dan kemudian mengatakan kadang-kadang lebih baik menggunakan Kelas Tuhan kadang-kadang (Mengutip mikro-controller sebagai contoh).
4. Dalam Robert C Martin "Clean Code: A Handbook of Agile Software Craftsmanship" halaman 136 (Dan hanya halaman ini) berbicara tentang "kelas Dewa" dan menyebutnya sebagai contoh utama dari pelanggaran terhadap aturan "kelas harus kecil" dia gunakan untuk mempromosikan Prinsip Tanggung Jawab Tunggal "mulai dari halaman 138.

Masalah yang saya miliki adalah semua referensi dan kutipan saya berasal dari orang yang sama (Robert C. Martin), dan saya berasal dari satu orang / sumber yang sama. Saya diberi tahu bahwa karena ia hanya satu pandangan, keinginan saya untuk tidak menggunakan "Kelas God" tidak valid dan tidak diterima sebagai praktik standar terbaik dalam industri perangkat lunak. Apakah ini benar? Apakah saya melakukan hal yang salah dari sudut pandang teknis dengan mencoba terus mengikuti ajaran Paman Bob?

Pemrograman dan Desain Object Object dan Berorientasi Objek:

Semakin saya memikirkan hal ini, semakin saya pikir ini adalah sesuatu yang Anda pelajari ketika Anda belajar OOP dan tidak pernah secara eksplisit dipanggil; Yang tersirat dalam desain yang baik adalah pemikiran saya (Silakan koreksi saya, tolong, karena saya ingin belajar), masalahnya adalah saya "tahu" ini, tetapi tidak semua orang melakukannya, jadi dalam hal ini tidak dianggap sebagai argumen yang valid karena Saya secara efektif menyebutnya sebagai kebenaran universal ketika pada kenyataannya kebanyakan orang secara statistik tidak mengetahuinya karena secara statistik kebanyakan orang bukan pemrogram.

Kesimpulan:

Saya bingung apa yang harus dicari untuk mendapatkan hasil tambahan terbaik untuk dikutip, karena mereka membuat klaim teknis dan saya ingin tahu kebenarannya dan dapat membuktikannya dengan kutipan seperti insinyur / ilmuwan sungguhan, bahkan jika Saya bias terhadap benda-benda dewa karena pengalaman pribadi saya dengan kode yang menggunakannya. Setiap bantuan atau kutipan akan sangat dihargai.

Kasus untuk setiap perubahan praktik dilakukan dengan mengidentifikasi titik-titik nyeri yang diciptakan oleh desain yang ada. Khususnya, Anda perlu mengidentifikasi apa yang lebih sulit daripada seharusnya karena desain yang ada, apa yang rapuh, apa yang melanggar sekarang, perilaku apa yang tidak dapat diimplementasikan dengan cara sederhana sebagai hasil langsung (atau bahkan agak tidak langsung) dari implementasi saat ini, atau, dalam beberapa kasus, bagaimana kinerja menderita, berapa banyak waktu yang diperlukan untuk mempercepat anggota tim baru, dll.

Kedua, kode kerja mengalahkan argumen apa pun tentang teori atau desain yang baik. Ini benar bahkan untuk kode yang buruk, sayangnya. Jadi, Anda harus memberikan alternatif yang lebih baik, yang berarti Anda, sebagai pendukung pola dan praktik yang lebih baik, perlu refactor untuk mencari desain yang lebih baik. Temukan pesawat gaya pelacak-peluru yang sempit melalui desain yang ada, dan terapkan solusi yang, mungkin, untuk iterasi satu, membuat implementasi objek dewa bekerja, tetapi menghambat implementasi aktual ke desain baru. Kemudian tulis beberapa kode yang mengambil keuntungan dari desain baru ini, dan pamerkan apa yang Anda menangkan karena perubahan ini, apakah itu kinerja, pemeliharaan, fitur, koreksi bug atau kondisi balapan, atau pengurangan beban kognitif untuk pengembang.

Seringkali merupakan tantangan untuk menemukan area permukaan yang cukup kecil untuk diserang dalam sistem yang dirancang buruk, mungkin butuh waktu lebih lama daripada yang ingin Anda berikan beberapa nilai awal, dan hasil awal mungkin tidak terlalu mengesankan bagi semua orang, tetapi Anda juga dapat bekerja untuk menemukan beberapa pendukung pendekatan baru Anda jika Anda memasangkannya dengan anggota tim yang setidaknya sedikit simpatik.

Lamenting the God Object hanya berfungsi ketika Anda berkhotbah di paduan suara. Ini adalah alat untuk menamai masalah, dan hanya berfungsi untuk menyelesaikannya ketika Anda memiliki audiens yang reseptif yang senior dan cukup termotivasi untuk melakukan sesuatu tentang itu. Memperbaiki objek Dewa memenangkan argumen.

Karena kekhawatiran langsung Anda tampaknya adalah keterlibatan eksekutif, saya pikir Anda sebaiknya membuat kasus yang mengganti kode ini harus menjadi tujuan strategis dan mengikat mereka dengan tujuan bisnis yang menjadi tanggung jawab Anda. Saya pikir Anda dapat membuat kasus bahwa Anda dapat memberikan beberapa arahan teknis dengan terlebih dahulu mengerjakan lonjakan teknis tentang apa yang menurut Anda harus dilakukan untuk menggantinya, sebaiknya melibatkan sumber daya dari satu atau dua orang teknis yang memiliki keberatan tentang desain saat ini.

Saya pikir Anda telah menemukan sumber daya yang cukup untuk membenarkan argumen Anda; orang-orang dalam pertemuan semacam itu hanya akan memperhatikan ringkasan penelitian Anda, dan mereka akan berhenti mendengarkan setelah Anda menyebutkan dua atau tiga sumber yang menguatkan. Fokus Anda semula seharusnya adalah melakukan buy-off untuk menyelesaikan masalah yang Anda lihat, belum tentu membuktikan kesalahan orang lain atau diri Anda sendiri. Ini adalah masalah sosial, bukan yang logis.

Dalam peran kepemimpinan teknologi, Anda perlu mengikat setiap inisiatif Anda dengan tujuan bisnis, jadi hal terpenting untuk menyampaikan kasus Anda kepada eksekutif adalah apa yang akan dilakukan pekerjaan untuk tujuan tersebut. Karena Anda juga dianggap sebagai "orang baru," Anda tidak bisa hanya berharap orang untuk membuang pekerjaan mereka atau berharap untuk cepat mengantre; Anda perlu membangun kepercayaan dengan membuktikan bahwa Anda bisa mewujudkannya. Sebagai perhatian jangka panjang, dalam peran kepemimpinan, Anda juga perlu belajar untuk menjadi fokus pada hasil, tetapi tidak harus melekat pada spesifik dari hasil. Anda sekarang di sana untuk memberikan arahan strategis, menghilangkan hambatan taktis dari kemajuan oleh tim Anda, dan menawarkan bimbingan tim Anda, bukan memenangkan pertempuran kredibilitas dengan anggota tim Anda sendiri.

Membuat keputusan top-down jarang akan kredibel kecuali Anda memiliki kulit dalam permainan; jika Anda berada dalam situasi yang sama lagi, Anda harus lebih fokus pada pembangunan konsensus dalam organisasi Anda daripada meningkat setelah Anda merasa situasinya di luar kendali.

Tetapi mempertimbangkan di mana Anda berada sekarang, saya akan mengatakan taruhan terbaik Anda adalah dengan berargumen bahwa pendekatan Anda akan membawa manfaat jangka panjang yang terukur berdasarkan pengalaman Anda dan itu sejalan dengan pekerjaan oleh para praktisi terkenal seperti paman Bob dan rekan. , dan Anda ingin menghabiskan beberapa hari / minggu memimpin dengan memberikan contoh pada refactoring sempit dari aspek bang-for-buck tertinggi, untuk menunjukkan seperti apa tampilan desain yang baik Anda. Anda harus menyelaraskan apa pun kasus Anda dengan tujuan bisnis tertentu di luar preferensi pribadi Anda.

Pertama, Anda perlu menunjukkan bahwa organisasi yang terukur perlu mengadopsi praktik terbaik industri. Mengatakan bahwa "itu hanya bekerja untuk kita!" tidak dapat diukur, baik dalam waktu atau sumber daya karena tidak dapat diprediksi. Rekayasa perangkat lunak adalah ilmu sebanyak bidang ilmu lainnya, dan konsep-konsep ini telah dipelajari, diteliti, diuji, dan didokumentasikan.

1. yang Object Allah adalah anti-pola yang menyatakan bahwa

   Dalam rekayasa perangkat lunak, anti-pola (atau antipattern) adalah pola yang digunakan dalam operasi sosial atau bisnis atau rekayasa perangkat lunak yang mungkin umum digunakan tetapi tidak efektif dan / atau kontraproduktif dalam praktiknya.

2. Dalam konferensi Google IO 2009 , subjek ini sebagian dijelaskan ketika pola MVP dijelaskan. Ini mungkin tidak relevan dengan Obyek Tuhan, tetapi mungkin memberi Anda beberapa amunisi.

3. Juga, menggunakan anti-pola ini melanggar prinsip tanggung jawab tunggal dalam desain berorientasi objek, yang menyatakan bahwa:

   setiap kelas harus memiliki satu tanggung jawab tunggal, dan tanggung jawab itu harus sepenuhnya dienkapsulasi oleh kelas. Semua layanannya harus selaras dengan tanggung jawab itu.

4. The Decaying Kode blog juga berbicara tentang ini dan tentang solusi itu.

5. Kita tidak dapat berbicara tentang prinsip tanggung jawab tunggal tanpa membicarakan tentang penggandengan objek .

   [...] kopling atau ketergantungan adalah sejauh mana setiap modul program bergantung pada masing-masing modul lainnya.

   Dimana memiliki sistem yang digabungkan secara ketat dapat menyebabkan assembly of modules [to] require more effort and/or time [to maintain] due to the increased inter-module dependency.tingkat yang lebih tinggi dari objek couping berarti lebih sedikit kohesi, dan sebaliknya. Objek-objek Tuhan adalah contoh yang baik dari kopling ketat karena mereka tahu lebih banyak dari yang seharusnya, sehingga membebani mereka dengan tanggung jawab, sehingga sangat membatasi penggunaan kembali kode.

6. Ketika merancang aplikasi yang kompleks, kesederhanaan harus muncul di benak Anda. Masalah besar harus diuraikan menjadi masalah yang lebih kecil, yang lebih mudah untuk dikelola, diuji, dan didokumentasikan. Ini terutama benar dalam paradigma berorientasi objek.

   Dengan argumen ini, kita kembali ke argumen anti-pola, tetapi paradigma ini adalah semua tentang pola, representasi objek dunia nyata dan, akhirnya, enkapsulasi data.

7. Anda benar ketika Anda mengatakan bahwa "praktik baik" ini lebih ada di ruang kelas. Namun, saya memiliki pengalaman mengajar di perguruan tinggi (dan beberapa universitas) dan saya hanya melihat prinsip-prinsip ini diajarkan di universitas, terutama di fakultas teknik. Yang menyedihkan. Tetapi seperti praktik yang baik, mereka yang berusaha untuk memperbaiki diri biasanya mempelajari beberapa pola desain dasar , dan akhirnya memahami bagaimana berhimpitan antara penggandengan dan kohesi.

   Apa yang biasanya saya ajarkan kepada siswa adalah bahwa, mungkin tampaknya membutuhkan lebih banyak upaya untuk mengadopsi standar pemrograman yang baik, tetapi selalu terbayar dalam jangka panjang. Contoh yang baik adalah seseorang yang meminta seorang programmer untuk menulis fungsi penyortiran. Programmer memiliki dua pilihan; 1) menulis fungsi penyortiran gelembung cepat (kurang dari 5 menit) yang tidak akan berkelanjutan saat daftar elemen bertambah, atau 2) menulis algoritma penyortiran yang lebih kompleks (alias dioptimalkan) (penyortiran cepat, dll.) Yang akan menskala lebih baik dengan daftar yang lebih besar.

Oh, begini, necro pertanyaan lama lain tapi saya akan menebak Anda tidak memenangkan argumen ini dan inilah sebabnya.

Kedengarannya Seperti Masalah Budaya

Anda adalah manajer mereka tetapi Anda tidak dapat menggantinya dan Anda harus pergi ke manajer Anda untuk membuat mereka melakukan apa yang Anda yakini harus mereka lakukan yang dalam kasus ini saya anggap setidaknya menjatuhkannya dengan dewa benda bergerak maju. Bagi saya itu kedengarannya seperti kasus klasik yang mencerminkan budaya tempat kelahirannya. Dengan kata lain objek dewa adalah cara perusahaan ini bekerja. Ingin membuat perubahan berarti apa pun? Anda selalu pergi ke tempat yang sama untuk akhirnya karena semua keputusan tampaknya harus diselesaikan di atas.

Setelah mengetahui beberapa upaya yang gagal pada pembersihan kode lama dan perubahan kebijakan kode, saya sekarang berpendapat bahwa Anda tidak dapat melawan budaya yang membuat kode menjadi mungkin sejak awal ketika budaya itu masih tertanam kuat atau setidaknya, berjuang budaya adalah pekerjaan berat yang sangat sulit sehingga tidak mungkin ada orang yang bisa membayar saya cukup atau memberi saya kekuatan yang cukup untuk merasa itu adalah usaha yang berharga yang kemungkinan akan berhasil lagi.

Sebelum ada perubahan, mereka harus termotivasi untuk berubah dan sayangnya sebagai programmer yang cukup banyak untuk membaca Stack sesekali sulit bagi kita untuk memahami bahwa tidak semua orang termotivasi oleh hal-hal yang sama. Saya telah memenangkan banyak argumen rasional dalam pengalaman saya, tetapi pada akhirnya perusahaan itu menderita devs yang malas secara intelektual karena suatu alasan.

Mungkin masalah bisnis telah termotivasi untuk memikirkan tentang hari esok daripada minggu depan atau lima tahun ke depan (skenario yang membuat frustasi ketika Anda adalah anak imigran dari negara yang membangun tempat penyimpanan benih di Kutub Utara dalam kasus kiamat). Mungkin mereka takut akan perubahan. Mungkin mereka menghargai senioritas terlalu banyak sampai pada titik bahwa rantai komando tidak ada artinya bahkan ketika mereka harus menyewa dari luar untuk membawa pemimpin atau manajer tim dev karena mereka menyadari tidak ada seorang pun di tim all-lifer mereka yang telah cukup berkembang dalam waktu mereka. di sana (atau karena orang seumur hidup tidak menginginkan risiko yang terkait dengan tanggung jawab). Atau, dan saya telah melihat ini, mungkin itu adalah fenomena mediokritas yang sangat nyata dan menyedihkan yang memperjuangkan dirinya sendiri karena ia tahu jauh di lubuk hatinya bahwa ia dapat '

Bagaimana Anda melawan masalah yang pada akhirnya berakar pada rasa takut atau metrik untuk kesuksesan? Saya akan mengatakan ini kepada Anda, dibutuhkan jauh lebih banyak daripada bahkan tim pengembang kualitas yang berkomitmen dan Anda memiliki lebih sedikit dari itu dari suara itu pada saat Q ini diposting.

Dalam Acara Yang Tidak Mungkin Itu Bukan Masalah Budaya yang Menarik ...

Sekarang dengan asumsi orang-orang di atas sangat menerima perubahan, dan mereka benar-benar mau mempercayai Anda untuk membuatnya, Anda benar-benar hanya perlu menandai semua argumen Anda dengan uang dan kehilangan peluang.

Setiap kali dibutuhkan waktu lebih lama untuk melatih orang baru pada basis kode konyol ini, setiap kali dibutuhkan lebih lama untuk memodifikasi atau menambahkan fitur baru ke sesuatu, setiap kali menjadi sangat sulit untuk mengekspos titik akhir ke sistem lain dari perusahaan yang ingin Anda bermitra dengan , itu adalah biaya uang. Banyak uang yang menakutkan. Yang paling penting itu membuat jendela terbuka bagi pesaing kecil yang lebih gesit untuk masuk, menempatkan Anda pada posisi di mana yang dapat Anda lakukan adalah bereaksi terhadap mereka terlalu lambat, dan pada akhirnya merenggutnya semua dari Anda.

Ketahuilah bahwa budaya yang keras kepala dan bodoh akan mempertahankan status quo dengan cara apa pun, bahkan jika atap fisik perusahaan sebenarnya terbakar karena hal itu.

Anda bisa mengutip beberapa prinsipal OOP paling dasar seperti kopling longgar dan kohesi tinggi. "Objek Tuhan" terdengar seperti pasangan yang tidak berhubungan kelas dan memiliki kohesi rendah.

Anda selalu bisa bertanya pada Paman Bob sendiri.

Masalahnya, itu sangat jelas bagi orang-orang dengan pengertian bahwa begitu itu dijabarkan, tidak perlu direferensikan oleh banyak penulis. Hanya perlu satu sumber.

Istilah lain yang mungkin ingin Anda mulai ketika mencari sumber adalah:

• PADAT
• Hukum Demeter
• Bola Lumpur Besar

Semua ini mengungkapkan konsep terkait yang mungkin menghasilkan sumber referensi yang layak, meskipun mereka tidak benar-benar menamakannya seperti itu.

Namun akhirnya, Anda adalah bosnya. Alasan melakukannya adalah karena Anda mengatakannya, dan meskipun dianggap sebagai manajer yang baik, Anda harus siap untuk membenarkan keputusan Anda; Anda sudah melakukan itu, dan jika masih ada perlawanan, tindakan yang benar adalah agar tim Anda melakukan apa yang diperintahkan.

Bagaimana saya membuktikan atau menyangkal benda "dewa" salah?

Kamu tidak bisa.

Dugaan semacam ini tidak sesuai dengan bukti matematis, dan bukti matematis adalah satu-satunya jenis bukti yang masuk akal.

Bahkan jika Anda mencoba mengganti kata emotif "salah" dengan ukuran efek efek yang dapat diukur dari menggunakan objek dewa, Anda akan menemukan bahwa:

1. langkah-langkah yang tersedia adalah mentah,
2. ada beberapa studi kredibel di mana langkah-langkah tersebut telah dikuantifikasi untuk kode yang dihasilkan oleh programmer profesional
3. ada beberapa studi kredibel di mana konstruksi bahasa atau pola desain (anti-) telah dikaitkan dengan langkah-langkah tersebut.

Dan itu mengabaikan masalah memutuskan kapan objek tertentu adalah objek "dewa".

Paling-paling, studi semacam ini hanya bisa menunjukkan korelasi empiris. Bukan bukti asli.

Apa yang sebenarnya Anda lakukan adalah memperdebatkan pro dan kontra dari objek "dewa" dengan maksud untuk mengubah pendapat orang lain ... dan kemudian praktik organisasi Anda.

Jangan menggunakan kata-kata seperti "bukti" atau orang-orang yang Anda ajak berdebat cenderung menertawakan Anda.

Anda mungkin ingin bertemu guru minggu ke-84 . Ini semua tentang benda dewa (monolit) dan bagaimana mereka buruk.

Ekstrak:

(Mayor) Ini mengisolasi fungsionalitas yang berpotensi independen di dalam kelas [...] (Kecil) Ini dapat mencegah perluasan kelas dengan fungsionalitas baru [...]

Saya tidak yakin jika tim Anda benar-benar tertarik pada proove akademik bahwa "objek Tuhan salah".

Dari sudut pandang psikologis, pendekatan refactoring Anda dapat disalahpahami sebagai menyerang kompetensi tim a la: "tim telah melakukan pekerjaan yang buruk" meskipun program bekerja seperti yang diharapkan.

Apa yang benar-benar ingin Anda lakukan adalah mengatasi efek samping negatif dari "kode spagetti" dan "objek Dewa": biaya explodig untuk menambahkan fitur baru karena meningkatnya bug yang disebabkan oleh efek samping.

Memberi pertanyaan yang sangat spesifik dan bertanya daripada memberikan jawaban mungkin lebih bermanfaat:

manager > Why did implement the new tax-calculation schema took more than 4 weeks
team > because {reason a}
manager > And why was {reason a}?
team > because {reason b}
manager > And why was {reason b}?
...
team > because {reason z}
manager > what could we do to avoid {reason z} ?
team > refactor code