Titik kompleksitas tidak bisa kembali. Kamu menyebutnya apa?


13

Sebagai pengembang perangkat lunak, salah satu tugas utama saya adalah mengendalikan kompleksitas.

Namun, dalam beberapa proyek, ada saat ketika tingkat kompleksitas tumbuh begitu tinggi sehingga mencapai semacam "tidak kembali". Melewati momen ini, Anda tidak pernah dapat mengembalikan proyek ke tingkat kompleksitas yang dapat diterima dalam waktu yang lebih singkat daripada yang Anda butuhkan untuk menulis ulang semuanya dari awal.

Apakah momen khusus ini memiliki nama dalam dialek programmer (sesuatu yang mirip dengan hukum Godwin untuk troll)?

--edit--

Maaf jika saya tidak jelas. Saya tidak berpikir "momen" ini memiliki nama resmi, atau merupakan metrik yang serius. Saya sedang memikirkan sesuatu dalam semangat "Ballmer peak" di xkcd .


1
Saya melihat satu kontroversi dalam definisi Anda tentang poin yang dimaksud: ... dalam waktu yang lebih singkat bahwa Anda perlu menulis ulang semuanya dari awal , yang menyiratkan mereka yang akan menulis ulang proyek cukup baik, atau setidaknya lebih baik daripada mereka yang menciptakan kekacauan di tempat pertama;)
mojuba

1
Saya pikir salah satu alasan tidak ada nama yang disepakati adalah tergantung pada siapa yang melihat kode tersebut. Apa yang tampak sangat rumit atau tidak dapat dipelihara untuk satu pengembang dapat tampak cukup masuk akal bagi yang lain. Dalam kasus yang parah, saya hanya mengkompilasi menjadi DLL dengan awalan "ms" dan mengatakan itu berasal dari Microsoft.
Kevin Hsu

1
Mungkin ini bisa dilakukan: Horizon Event Utang Teknis
PeterAllenWebb

Jawaban:


20

Ini lebih merupakan masalah pemeliharaan daripada kompleksitas.

Fenomena ini disebut "utang teknis", dan begitu mencapai tingkat kritis, proyek ini menuju kebangkrutan.

Apakah itu yang kamu maksud?


Terima kasih atas jawaban Anda. Saya mengetahui konsep "dept teknis". Setiap proyek memiliki semacam hutang teknis. Maksud saya adalah: bagaimana Anda menyebut saat utang ini menjadi begitu tinggi sehingga Anda lebih suka membuang proyek ke sampah dan mulai lagi?
Thibault J

3
Saya suka istilah Anda 'kebangkrutan teknis'. Ini menunjukkan bahwa seperti dalam kebangkrutan nyata, Anda harus melihat dengan hati-hati bagian mana yang bisa diselamatkan dan mana yang harus ditinggalkan. Dan mungkin beberapa restrukturisasi hutang adalah yang benar-benar dibutuhkan :)
Jaap

2
@Thibault J: Saya tidak percaya ada istilah khusus untuk saat itu. Ini lebih tentang menyadari jika Anda masih bahagia sebelum waktu itu atau sayangnya melewati itu.

1
@ Art Pengembang: ... menyadari jika Anda masih bahagia sebelum waktu itu atau sayangnya melewati itu - saya pikir itulah kunci dalam memberikan definisi yang baik tentang titik: proyek yang melampaui titik adalah salah satu yang tidak akan ada insinyur ambil alih secara sukarela.
mojuba

3
Saya akan pergi untuk istilah "kebangkrutan teknis", saya menyukainya. Dan saya juga akan menggunakan definisi Anda.
Thibault J

16

"Titik kompleksitas berlebih" disebut dalam bahasa Inggris sebagai:

OH Tuhanku APA ITU CRAP INI.

Masalahnya adalah, ini dapat diterapkan pada sesuatu yang sebenarnya sederhana, tetapi diterapkan sedemikian rupa sehingga Anda memiliki reaksi yang sama.

Jadi membedakan sesuatu yang sangat kompleks dari sesuatu yang sangat mengerikan bisa jadi sulit.

NAMUN: Apa yang sebenarnya cenderung terjadi pada semua perangkat lunak adalah proses sedikit seperti ini:

Langkah 1: Miliki spec yang bagus, lakukan desain yang bagus, terapkan hal-hal yang bagus. Semua orang senang.

Pada akhir langkah 1: para pengembang mengucapkan selamat kepada diri mereka sendiri atas keanggunan indah dari desain mereka, dan pergi dengan senang berpikir "Saya memiliki warisan yang luar biasa di sini bagi orang lain untuk menambahkan sesuatu di masa depan, itu akan luar biasa dan dunia akan menjadi tempat yang lebih baik."

Langkah 2: Beberapa perubahan dibuat, hal ditambahkan, fungsi baru disertakan. Arsitektur dan struktur dari Langkah 1 membuat proses ini cukup menyakitkan. [Tapi oops, "faktor kesalahan" hanya sedikit meningkat.]

Pada akhir langkah 2: para pengembang mengucapkan selamat kepada diri mereka sendiri atas keanggunan indah dari desain mereka, dan pergi dengan senang berpikir "Ya ampun aku telah membuat semua kelonggaran dalam Langkah 1. Ini berjalan dengan sangat baik. Saya memiliki warisan yang luar biasa di sini bagi orang lain untuk menambahkan hal-hal di masa depan, itu akan luar biasa dan dunia akan menjadi tempat yang lebih baik. "

Langkah 3: Lebih banyak perubahan dilakukan, lebih banyak hal ditambahkan, lebih banyak fungsi baru, banyak hal diubah, umpan balik pengguna sebenarnya sedang didengarkan.

Pada akhir langkah 3: para pengembang mengucapkan selamat kepada diri mereka sendiri atas keanggunan indah dari desain mereka, dan pergi dengan pemikiran yang cukup bahagia "Wah arsitektur ini cukup baik untuk memungkinkan begitu banyak perubahan untuk hanya slot masuk dengan mudah. ​​Tapi saya sedikit tidak senang tentang X dan Y dan Z. Mereka bisa dibersihkan sedikit sekarang. Tapi !!! Ahhh !!! Saya sangat pintar untuk membuat semua uang saku pada Langkah 1. Ini berjalan sangat baik. Saya memiliki warisan yang indah di sini untuk orang lain untuk menambahkan hal-hal di masa depan, itu akan luar biasa dan dunia akan menjadi tempat yang lebih baik. "

Langkah 4: sama seperti langkah 3. Kecuali:

Pada akhir langkah 4: para pengembang berpikir: "Hal-hal yang sangat baik ini membuat UGLY tetap mempertahankan. Ini benar-benar membutuhkan beberapa perubahan serius. Saya tidak benar-benar suka mengerjakan ini. Perlu refactoring. Saya ingin tahu apa yang dilakukan bosnya. akan mengatakan ketika saya memberitahunya perlu 6 minggu dan tidak akan ada yang bisa dilihat pengguna di akhir ini ... tapi saya akan mendapatkan 5 tahun lagi ruang lingkup modifikasi yummy di masa depan dengan melakukan ini .... hmmm .. "Waktu untuk pergi ke pub untuk minum bir."

Langkah 5: Banyak perubahan perlu dilakukan.

Dan SELAMA langkah 5 pengembang berkata satu sama lain: "Kode ini payah. Siapa yang menulis ini? Mereka harus ditembak. Mengerikan. Kita HARUS MENULISNYA."

Langkah 5 fatal. Di sinilah faktor cruft menjadi sangat buruk sehingga kode tidak bisa hanya memiliki beberapa perubahan lagi, perlu beberapa perubahan BESAR.

Masalah pada Langkah 5 adalah keinginan untuk membuangnya dan memulai lagi. Alasan ini fatal adalah "The Netscape Factor". Go google it. Perusahaan DIE pada titik ini, karena memulai lagi berarti Anda mulai dengan asumsi sekitar 50%, bukannya fakta, 150% antusiasme, bukannya pengetahuan, 200% arogansi, bukan kerendahan hati ("Orang-orang itu sangat bodoh!"). Dan Anda memperkenalkan sejumlah bug baru.

Hal terbaik untuk dilakukan adalah refactor. Ubah sedikit demi sedikit. Jika arsitekturnya sedikit lelah, perbaiki. Tambah, perluas, tingkatkan. Bertahap. Di setiap langkah di sepanjang jalan, uji, uji, dan uji lagi. Perubahan tambahan seperti ini berarti bahwa 10 tahun kemudian kode saat ini dan asli seperti kapak kakek ("memiliki 10 kepala baru dan 3 pegangan baru tetapi masih kapak kakek"). Dengan kata lain, tidak ada banyak kesamaan. Tapi Anda pindah dari yang lama ke yang baru secara bertahap dan hati-hati. Ini mengurangi risiko, dan bagi pelanggan, itu mengurangi faktor kesal.


Saya yakin Anda akan mendapatkan lebih banyak suara jika Anda mempersingkat langkah Anda.
Codism

Saya harus menambahkan bahwa sebagian besar bisnis tidak menganggarkan untuk ini, jadi refactoring selalu terlambat. Untuk mengelola peningkatan entropi sistem adalah untuk mengatur, bahwa sejak hari 1, anggaran (10% -20%) dialokasikan dari setiap pekerjaan untuk rumah tangga. Ini bukan anggaran untuk perbaikan bug. Pengeluaran anggaran ditentukan oleh teknik, bukan manajemen atau pemasaran atau penjualan. Ini hanya digunakan untuk faktor keluar entropi yang diciptakan oleh pengembangan, dan pengeluaran berkurang ketika produk mendekati akhir hidup.
mattnz

Sepakat. Manajemen selalu ingin memangkas hal semacam itu. Kadang-kadang Anda dapat menyembunyikannya (Tambahkan sekitar 20% ke perkiraan pengembangan untuk melakukan apa pun, dan ketika refactoring diperlukan - LAKUKAN).
cepat

1
Ada titik di mana Anda benar-benar tidak bisa menolak. Jika Anda memiliki beberapa aplikasi bisnis berbeda yang bergantung pada antarmuka atau basis data buruk yang sama, Anda tidak dapat memperbaiki hal-hal mendasar dengan sangat baik tanpa merusak semua aplikasi lain yang bergantung pada fondasi jelek. Pada titik ini Anda benar-benar kacau.
John Cromartie

2

Saya setuju bahwa momen itu sulit dikenali, dan dapat dihindari dengan proses yang tepat. Namun, pertanyaannya adalah tentang apa sebutannya. Dalam ekonomi riil, ada konsep "hasil yang semakin berkurang": titik di mana peningkatan input untuk satu sumber daya dalam suatu proses menurunkan keseluruhan laba per unit. Ini tentu saja berlaku untuk pengkodean, dan bahkan hal-hal baik seperti abstraksi, penggunaan kembali dll memiliki titik pengembalian yang semakin berkurang. Istilah umum pemrograman khusus adalah "rekayasa ulang". Untuk seseorang yang cenderung melakukan ini, saya suka istilah Joel " astronot arsitektur ".


1

Terlalu sering kode yang baik dibuang di bawah kesan salah bahwa tim baru dengan alat baru dapat melakukannya dengan lebih murah, lebih cepat dengan keandalan lebih, hanya untuk menemukan bahwa

  • Kompleksitasnya ada pada persyaratan dokumen
  • Alat baru lebih sulit digunakan daripada situs web flash yang dijanjikan
  • Tim baru tidak sepanas yang mereka kira

Mungkin waktu yang telah Anda jelaskan tiba dengan beberapa basis kode (Dulu saya pikir begitu). Saya tidak pernah secara pribadi mengalami kasus kode lama yang menyebabkan proyek memuncak, atau menulis ulang kode untuk menyimpan proyek.

Saya tidak memasukkan dalam kasus ini di mana metrik telah digunakan untuk mengidentifikasi modul atau desain yang bermasalah khusus, yang kemudian diambil dan diganti.


Ya, saya sudah melihat proyek yang sangat rumit sehingga anggaran pemeliharaan mereka adalah tiga atau empat kali anggaran pengembangan awal. Bagaimanapun, istilah yang saya cari bukanlah hal yang "resmi" dan serius, tetapi lebih seperti "Ballmer peak" di xkcd. Maaf jika saya tidak begitu jelas.
Thibault J

Tapi bagaimana bisa begitu cepat? Jika itu karena persyaratan kompleks, manajemen yang buruk, lebih dari insinyur optimis, mengapa menulis ulang memperbaikinya?
mattnz

Karena tim menulis ulang itu tidak sama dengan yang menulisnya di awal?
Thibault J

1

Masalah sebenarnya dengan "momen" teoretis ini adalah bahwa itu hanya pernah dikenali setelah fakta. Kecuali kolega Anda adalah psikopat, setiap komitmen pada basis kode dilakukan dengan keyakinan bahwa ini merupakan peningkatan pada basis kode itu. Itu hanya melihat kembali kekacauan yang terjadi sehingga Anda dapat melihat bahwa Anda telah melewati "momen" itu.

Tapi saya suka kita bisa memberi nama. "Tuan-tuan," bisa dibilang, menarik rekan-rekan pengembangmu di sekitarmu, "Kami sudah melewati Maintainability Hellespont. Kirim pesan ke istrimu dan beri tahu dia bahwa kamu tidak akan melihatnya sebentar."


"Setiap komitmen dalam basis kode dilakukan dengan keyakinan bahwa ini merupakan peningkatan pada basis kode itu." Sepertinya kita tidak pernah bekerja di perusahaan yang sama :)
Thibault J

@ThibaultJ - Mungkin kolega Anda adalah psikopat?
Dan Ray

@Thibault J: Saya percaya bahwa setiap commit dilakukan dengan keyakinan bahwa ini merupakan peningkatan pada basis kode itu. Kepercayaan itu terkadang diteliti dengan buruk dan tidak berdasar, tentu saja.
David Thornley

Pada pekerjaan terakhir saya, saya tidak berpikir ada komitmen pemeliharaan yang pernah dilakukan siapa pun dengan keyakinan bahwa itu adalah peningkatan basis kode.
Bobby Tables

Kadang-kadang persyaratan proyek dapat berubah cukup untuk memaksa penggantian dengan desain baru, tetapi mungkin perlu untuk membuat perubahan ke versi lama. Jika sebagian besar pengguna lama dari versi lama akan menggunakan sistem baru dan tidak akan membutuhkan yang lama lagi, mungkin masuk akal untuk menghasilkan versi yang memenuhi persyaratan beberapa orang yang sistemnya tidak cocok, bahkan jika itu akan membuat sistem kurang bermanfaat bagi orang-orang yang tidak lagi membutuhkannya.
supercat

-1

Saya tidak tahu apakah ada nama tetapi jika tidak ada saya akan mengusulkan menyebutnya "titik meltdown"


Atau meminjam istilah nuklir lain: massa kritis.
John Cromartie

-2

Ini bukan pertanyaan yang sangat menarik.

Memang itu sepele.

Sangat sepele sehingga kami telah mengembangkan banyak cara untuk mengatasinya.

  1. Metodologi air terjun. Banyak orang menghabiskan banyak waktu meninjau persyaratan dan dokumen desain untuk memastikan bahwa kompleksitas dikelola.

  2. Metodologi tangkas. Lebih sedikit orang yang menghabiskan lebih sedikit waktu untuk mendiskusikan apa yang dapat diterapkan untuk memecahkan masalah seseorang dan merilis perangkat lunak untuk mereka. Kompleksitas dikelola karena semua orang fokus untuk merilis sesuatu.

Satu-satunya saat seseorang bergulat dengan "kompleksitas" adalah karena kegagalan untuk mengikuti metodologi dan mengatur waktu mereka dengan benar.

  • Tidak ada pengawasan terperinci dalam metodologi air terjun. Mereka tidak dipaksa untuk meninjau produk kerja menengah pada persyaratan, arsitektur, desain tingkat tinggi atau ulasan desain rinci.

  • Tidak ada tenggat waktu sprint atau prioritas kasus penggunaan yang layak dalam metodologi Agile. Mereka tidak fokus untuk merilis sesuatu kepada pengguna secepat mungkin.

Kompleksitas harus dibatasi dengan menetapkan tujuan.

Bergulat dengan kompleksitas berarti bahwa gol tidak ditentukan atau tidak dihargai dengan benar.

Tidak ada "titik balik". Jika manajemen kompleksitas entah bagaimana merupakan masalah, ada sesuatu yang salah secara organisasi.


1
Saya tidak mengerti intinya. Proyek yang dikelola dengan baik sangat tidak mungkin mencapai titik pengembalian, tetapi tidak semua proyek berjalan dengan baik. Beberapa proyek yang dijalankan dengan buruk akan tetap berhasil, dan sisanya akan gagal karena berbagai alasan, kadang-kadang mencapai titik kompleksitas tidak dapat kembali dan kadang-kadang tidak.
David Thornley

@ David Thornley: Itulah poin saya. "Titik kompleksitas tanpa pengembalian" tidak ada. Itu hanya manajemen yang buruk. Tidak perlu untuk nama yang canggih atau aturan. Kompleksitas hanyalah gejala dari manajemen yang buruk. Tidak terlalu menarik.
S.Lott

@ S.Lott: Saya pikir itu ada, meskipun tidak dalam proyek yang dikelola dengan baik. Ada banyak proyek yang dikelola dengan buruk di luar sana, dan beberapa dari mereka akan masuk ke dalam cakrawala peristiwa kompleksitas dan beberapa tidak. Saya benar-benar tidak berpikir itu berguna untuk menyatukan semua manajemen yang buruk.
David Thornley

@ David Thornley: Saya pikir sangat sulit untuk memisahkan manajemen yang buruk (yang mengarah pada kompleksitas yang mengerikan) dari manajemen yang buruk (yang membuat semua orang berhenti). Saya tidak bisa melihat cara untuk mengetahui apakah suatu proyek akan menjadi terlalu kompleks atau hanya terlambat atau tidak kompeten.
S.Lott

@ S.Lott: Namun, ada perbedaan antara proyek di mana semua orang berhenti atau menderita gangguan kesehatan besar dan proyek di mana kompleksitasnya menjadi terlalu banyak. Ada berbagai cara untuk gagal, dan mungkin menarik atau bahkan berguna untuk mengategorikannya.
David Thornley

-2

Ada metode untuk memvisualisasikan dan memantau risiko meningkatnya kompleksitas untuk proyek (besar) dan kode. Ketika mereka diterapkan secara wajar semoga nama baru untuk point of no return tidak diperlukan. (Ada MOOC terkait di openHPI: https://open.hpi.de/courses/softwareanalytics2015/ )

Kompleksitas Struktural adalah masalah desain umum - tidak hanya untuk desain perangkat lunak dalam tim besar. Visualisasi adalah langkah pertama dalam manajemen kompleksitas struktural. Matriks dan grafik berarah juga dapat digunakan untuk tujuan ini.

Beberapa metode untuk mengurangi kompleksitas struktural adalah http://www.buch.de/shop/home/suche/?fq=3540878890 :

  • modularisasi
  • menghindari loop umpan balik
  • triangulasi

Lebih jauh lagi ada konsep desain aksiomatik: https: \ en.wikipedia.org \ wiki \ Axiomatic_design \ Dengan konsep ini masalah reliabiltiy karena kompleksitas yang tidak perlu dapat dihindari.

Jadi ada banyak metode yang tersedia. Pada akhirnya selalu tentang keputusan untuk memikirkan mereka karena sebuah proyek menjadi cukup besar.


Ini tidak menjawab pertanyaan.
Hulk
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.