Mengapa kita tidak dapat menangkap desain perangkat lunak dengan lebih efektif? [Tutup]


14

Sebagai insinyur, kita semua "merancang" artefak (bangunan, program, sirkuit, molekul ...). Itu adalah aktivitas (desain-kata kerja) yang menghasilkan semacam hasil (desain-kata benda).

Saya pikir kita semua sepakat bahwa desain-kata benda adalah entitas yang berbeda dari artefak itu sendiri.

Aktivitas utama dalam bisnis perangkat lunak (memang, dalam bisnis mana pun di mana artefak produk yang dihasilkan perlu ditingkatkan) adalah memahami "desain (kata benda)". Namun kita, sebagai sebuah komunitas, tampaknya gagal total dalam merekamnya, sebagaimana dibuktikan dengan banyaknya upaya yang dilakukan orang untuk menemukan kembali fakta-fakta tentang basis kode mereka. Minta seseorang untuk menunjukkan kepada Anda desain kode mereka dan lihat apa yang Anda dapatkan.

Saya pikir desain untuk perangkat lunak memiliki:

  • Spesifikasi eksplisit untuk apa yang seharusnya dilakukan perangkat lunak dan seberapa baik melakukannya
  • Versi eksplisit dari kode (bagian ini mudah, semua orang memilikinya)
  • Penjelasan untuk bagaimana setiap bagian kode berfungsi untuk mencapai spesifikasi (misalnya, hubungan antara fragmen spesifikasi dan fragmen kode)
  • Sebuah alasan mengapa kode adalah cara itu (misalnya, mengapa pilihan tertentu daripada yang lain)

Apa yang BUKAN desain adalah perspektif tertentu pada kode. Misalnya [tidak memilih secara khusus] diagram UML bukan desain. Sebaliknya, mereka adalah properti yang dapat Anda peroleh dari kode, atau bisa dibilang, properti yang Anda harapkan dapat berasal dari kode. Tetapi sebagai aturan umum, Anda tidak dapat memperoleh kode dari UML.

Mengapa setelah 50+ tahun membangun perangkat lunak, mengapa kita tidak memiliki cara reguler untuk mengekspresikan ini? (Jangan ragu untuk membantah saya dengan contoh-contoh eksplisit!)

Bahkan jika kita melakukannya, sebagian besar komunitas tampaknya sangat fokus pada mendapatkan "kode" sehingga desain-kata benda hilang pula. (IMHO, sampai desain menjadi tujuan rekayasa, dengan artefak diekstraksi dari desain, kita tidak akan menyiasati ini).

Apa yang Anda lihat sebagai sarana untuk merekam desain (dalam arti saya telah menggambarkannya)? Referensi eksplisit untuk makalah akan baik. Menurut Anda mengapa cara spesifik dan umum belum berhasil? Bagaimana kita bisa mengubahnya?

[Saya punya ide sendiri yang menyempurnakan sudut pandang di atas, tapi saya tertarik dengan jawaban orang lain ... dan sulit untuk mengimplementasikan skema saya [[dan mungkin itulah masalah sebenarnya: -]]]

EDIT 2011/1/3: Salah satu utas jawaban mengisyaratkan bahwa "dokumentasi" (mungkin tekstual, khususnya yang tidak formal) mungkin memadai. Saya kira saya harus mengklarifikasi bahwa saya tidak percaya ini. Alat CASE muncul di tempat kejadian mulai tahun 80-an, tetapi alat awal kebanyakan hanya menangkap piksel untuk diagram apa pun yang Anda gambar; sementara alat-alat itu bisa dibilang sukses secara komersial, mereka benar-benar tidak sangat membantu. Wawasan utama adalah, bahwa jika artefak "desain" tambahan tidak dapat ditafsirkan secara formal, Anda tidak dapat memperoleh bantuan alat yang serius. Saya percaya wawasan yang sama berlaku untuk setiap bentuk penangkapan desain yang berguna dalam jangka panjang: jika tidak memiliki struktur formal, itu tidak akan ada gunanya. Dokumen teks cukup gagal dalam tes ini.


1
Disetujui pada UML - alat komunikasi terbaik, berkontribusi pada deskripsi desain, tetapi tidak dengan sendirinya menjadi desain. Namun yang terburuk, UML adalah kode sumber grafis.
Steve314

menghitung "seberapa baik ia melakukannya"
Steven A. Lowe

Ketika saya membangun sistem, saya harus bertemu banyak "nonfungsional" persyaratan: dikodekan dalam ini bahasa, penggunaan yang basis data, menangani 1E10 catatan dalam dengan waktu 100ms rata-rata respon, ... Anda tidak dapat meninggalkan ini keluar dari spesifikasi. (Tanpa persyaratan non-fungsional, loop selamanya adalah program yang memadai untuk setiap spesifikasi fungsional). Seluruh poin saya tentang penangkapan "desain" adalah untuk menangani persyaratan nonfungsional lainnya: "dapat dipelihara".
Ira Baxter

Diskusi Anda terlihat menarik tetapi saya masih tidak yakin apa sebenarnya pertanyaan itu. Apakah Anda pikir Anda bisa mencoba memberikan sesuatu seperti contoh nyata atau sesuatu untuk memperjelas apa yang sebenarnya Anda minati. Saya sedang memikirkan sesuatu seperti contoh FFT di mana Anda bisa memberikan gambaran penuh dari 4 poin peluru dalam pertanyaan Anda seperti Anda melihatnya dan mungkin hal-hal seperti apa yang ingin Anda lakukan dengan hasil yang pernah ditangkap.
n1ckp

Saya tidak tahu mengapa masalah ini, tapi itu masalah Fred Brooks '' Desain Desain ' . (Permintaan maaf jika Anda sudah terbiasa.) Dia membahas contoh-contoh dari pemrograman dan arsitektur. Dia terutama mencatat bahwa menangkap alasan (baik untuk desain, dan menolak desain alternatif) sangat berguna, dan tidak terlayani dengan baik oleh alat saat ini.
Paul D. Waite

Jawaban:


8

Saya pikir ada beberapa alasan mengapa kita masih tidak pandai dalam hal ini.

  1. Orang-orang untuk waktu yang lama meskipun perangkat lunak seperti rumah, dan menggunakan proses dan ide dari konstruksi. "Arsitek perangkat lunak" adalah judul yang diinginkan semua programmer. Selama sepuluh tahun terakhir, arsitek perangkat lunak hampir mati. Gagasan proses air terjun di mana Anda pertama kali memiliki arsitek yang mengatakan bagaimana perangkat lunak harus bekerja dan terlihat, dan kemudian membuat orang membuat diagram tentang bagaimana itu harus dibangun dan terakhir memiliki kode monyet yang mengimplementasikan alur kerja yang bagus ini / diagram UML untuk menentukan, ide ini adalah sekarang banyak diejek. Jadi sebenarnya, seluruh industri menggonggong ke jalur yang salah selama 40 tahun.

  2. Alat yang kami gunakan selalu berubah dan ditingkatkan. Pemrograman adalah teka-teki logis, dan kami datang dengan ide-ide dan teknik yang lebih baik untuk abstrak teka-teki itu dan membuatnya dimengerti. Cara kita memodelkan ini harus berkembang pada kecepatan yang sama, tetapi masih tertinggal. Teknik yang ditingkatkan untuk abstrak teka-teki pemrograman juga berarti kita dapat meningkatkan kompleksitas. Dan begitulah yang kita lakukan. Pemrograman selalu terletak di tepi kompleksitas yang kita sebagai pemrogram dapat tangani.

  3. Membuat cara untuk menggambarkan program adalah semacam abstraksi. Jika kita dapat menemukan cara yang bagus untuk mengabstraksikan perangkat lunak, kita juga bisa memasukkan abstraksi itu langsung ke alat pengembangan, dan karenanya menambahkan abstraksi / penyederhanaan lain ke pemrograman. Ini telah terjadi berulang kali. Contoh abstraksi tersebut adalah fungsi, kelas dan perpustakaan.

  4. Karena itu; Jika Anda memiliki model perangkat lunak yang sukses dan akurat , model itu akan setara dengan perangkat lunak. Yang agak membuat seluruh upaya sia-sia, yang pada gilirannya menguatkan poin 1 di atas: Pemodelan perangkat lunak jauh lebih berguna daripada yang diperkirakan sebelumnya. Lebih baik mengekstrak data tentang perangkat lunak dari kode. Membuat model UML dari tampilan kode sebenarnya jauh lebih mencerahkan daripada membuat model UML dan mencoba menerapkan model teoretis itu.


2
Jangan setuju dengan poin terakhir Anda. Ya, itu akan agak setara dengan perangkat lunak, tetapi masih lebih mudah untuk menggambar ulang model daripada untuk memperbaiki perangkat lunak yang sebenarnya ketika (tidak jika) Anda menemukan sesuatu yang bukan ide yang bagus. Saya tidak akan meremehkan pentingnya langkah desain.
Joris Meys

1
@Joris Meys: Masalahnya adalah Anda tidak akan tahu apa dan apa yang bukan ide yang baik sampai Anda menerapkannya. (Kecuali dalam kasus-kasus sepele, tetapi Anda tidak akan banyak menggunakan diagram UML). Anda juga tidak boleh melebih-lebihkan betapa sulitnya untuk memperbaiki kode. Saya merekomendasikan untuk membaca buku-buku Kent Becks tentang XP dan Test Driven Design.
Lennart Regebro

@Lennart: thx untuk tip
Joris Meys

2
@Lennart: Perbedaan antara Anda dan Ayub adalah bahwa Anda tampaknya setuju bahwa spesifikasi yang diungkapkan entah bagaimana mungkin diperlukan, meskipun saya tidak tahu bagaimana set abstraksi yang saat ini dapat diprogram melakukan itu. Tapi bayangkan saya perlu program pemrosesan sinyal yang mengekstrak frekuensi utama. Perhatikan saya tidak menyarankan caranya. Anda mungkin memutuskan untuk menggunakan Fast Fourier Transform, dan saya pasti akan menemukan jejak kaki di seluruh kode yang mengimplementasikan bit FFT. Tapi di mana fakta bahwa Anda memutuskan untuk menggunakan FFT yang direkam secara eksplisit? Saya percaya Anda membutuhkannya kecuali pembaca Anda mengetahui semua.
Ira Baxter

1
@Ira Baxter: Bagaimana "Kami memilih untuk mengimplementasikan pemrosesan sinyal dengan FFT"? Kode sumber memiliki komentar, Anda tahu. Dan saya juga bisa menulisnya dalam file README. Ekspresi spesifikasi eksplisit adalah kode. Baris teks seperti "Kami memilih untuk menerapkannya dengan FFT" tidak eksplisit, atau desain dalam arti posting asli Anda. Ini dokumentasi implementasi. Anda tampaknya telah berakhir dalam mode argumentatif, tetapi saya tidak mengerti apa yang Anda coba bantah.
Lennart Regebro

5

Anda mungkin tertarik meninjau literatur penelusuran perangkat lunak. Tanpa urutan tertentu:

  • CUBRANIC, D., MURPHY, GC, SINGER, J., DAN BOOTH KELLOGG, S. Hipikat: memori proyek untuk pengembangan perangkat lunak. Transaksi pada Rekayasa Perangkat Lunak 31, 6 (2005), 446-65.
  • TANG, A., BABAR, MA, GORTON, I., DAN HAN, J. Sebuah survei penggunaan dan dokumentasi alasan desain arsitektur. Dalam Proc dari Konferensi IEEE / IFIP Kerja ke-5 tentang Arsitektur Perangkat Lunak (2005).
  • RAMESH, B., POWERS, T., STUBBS, C., DAN EDWARDS, M. Menerapkan persyaratan keterlacakan: Sebuah studi kasus. Dalam Proc of the Int'l Symp on Requirements Engineering (York, 1995).
  • HORNER, J., DAN ATWOOD, ME Rasional desain: rasional dan hambatan. Dalam Proc dari Konferensi Nordic ke-4 tentang Interaksi Manusia-Komputer: Mengubah Peran (Oslo, Norwegia, 2006).
  • CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., DAN CLARK, S. Praktik terbaik untuk keterlacakan otomatis. Komputer 40, 6 (Juni 2007), 27–35.
  • ASUNCION, H., FRANÇOIS, F., DAN TAYLOR, RN Alat penelusuran perangkat lunak industri end-to-end. Dalam Proc dari Pertemuan Gabungan ke-6 dari Konf Perangkat Lunak Eropa dan ACM SIGSOFT Int'l Symp tentang Yayasan Rekayasa Perangkat Lunak (ESEC / FSE) (Dubrovnik, 2007).

Perhatikan bahwa ini hanyalah puncak gunung es, dan saya yakin saya telah meninggalkan beberapa dokumen penting.

Pada catatan terpisah, pekerjaan saya sendiri di Arcum adalah sarana bagi pemrogram untuk mengekspresikan kepada IDE penggunaan idiom desain crosscutting. Setelah diekspresikan, programmer kemudian dapat mengubah kode sumber mereka untuk menggunakan implementasi alternatif:

Kebetulan, Arcum juga terkait dengan pekerjaan DMS Anda.


1
+1 untuk ini. RT bukanlah segalanya tetapi itu salah satu dari beberapa langkah positif untuk benar-benar menyelesaikan masalah alih-alih membuat alasan lama yang sama untuk itu.
Aaronaught

2

UML adalah untuk program apa rencananya untuk bangunan dalam pandangan saya yang rendah hati. Rencana saja bukan desain tentunya, Anda memerlukan spesifikasi bahan (alat kode yang digunakan) untuk itu, pandangan umum bangunan (beberapa representasi skematis dari seluruh perangkat lunak, termasuk desain GUI), bagaimana bangunan ditanam di sekitarnya (skema yang jelas tentang bagaimana perangkat lunak berinteraksi dengan orang lain / ditanam di dalam OS), bagaimana berdiri dengan iklim dan tanah (interaksi dengan perangkat keras), ... Banyak buku tentang desain mencoba untuk mendefinisikannya, tetapi seperti begitu banyak hal dalam sains, setiap ilmuwan memiliki sedikit definisi sendiri.

Sekarang, saya juga tidak setuju dengan pengamatan Anda bahwa Anda tidak dapat memperoleh kode dari UML. Anda dapat, jika Anda memiliki informasi tambahan yang disebutkan. Tetapi kode sebenarnya bukan desain lagi, itu artefak. Anda juga tidak dapat mengekstraksi batu dan beton asli dari rencana, tetapi Anda membutuhkan rencana untuk meletakkan batu dan beton asli dalam bentuk dan tempat yang benar.

Dalam terang itu, saya menemukan artikel berikut yang menarik (saya bertemu dalam konteks yang berbeda ketika saya sedang mencari perangkat lunak grafik, tetapi tetap saja ...). Pendekatan grafik untuk mendeskripsikan desain masuk akal bagi saya, walaupun - lagi - ini hanya bagian dari desain menurut saya. Hal yang menarik adalah bahwa pendekatan ini memberikan kerangka kerja untuk memahami dan mereformasi desain (sebagai lawan refactor perangkat lunak), seperti yang ditunjukkan dalam makalah berikut:

Ada banyak pendekatan lain untuk menggambarkan (bagian dari) desain, seperti desain terstruktur (HIPO Charts) atau desain program terintegrasi , pola desain , ...

Namun, selama tidak ada standar industri yang ditetapkan, tidak mungkin untuk mendapatkan cara "biasa" untuk mengekspresikan ini. Bahkan setelah 50+ tahun. Dan jujur, jika perusahaan Anda menemukan cara yang baik untuk mengekspresikan desain, apakah Anda akan membagikannya kepada dunia?


Jika perusahaan Anda menemukan cara yang baik untuk melakukan ini, programmer akan memberi tahu orang lain dengan sangat cepat. :-)
Lennart Regebro

Saya pikir Anda kehilangan poin saya tentang UML (dan notasi "tunggal" lainnya). UML-before-code merupakan kendala bagaimana Anda ingin membangun perangkat lunak. Begitu juga semua notasi lainnya (ya, saya sudah melihat banyak ini, saya sudah sekitar beberapa saat). Diberi batasan, bisa dibilang memungkinkan untuk menghasilkan pertemuan kode yang membatasi (metode lelucon: menghasilkan semua program yang mungkin dan memeriksa untuk melihat mana yang cocok dengan kendala, pilih salah satu dari mereka). Dalam pengertian ini Anda dapat "menghasilkan kode dari UML". Tetapi (jika kita tetap menggunakan diagram kelas) kode itu tidak akan mengimplementasikan fungsi yang Anda inginkan ...
Ira Baxter

... dan sebagian besar skema notasi lainnya juga mengalami hal ini, mereka tidak benar-benar menangkap spesifikasi dari apa yang seharusnya dilakukan oleh program. Mereka juga tidak memberikan sesuatu seperti alasan; mengapa UML Anda memetakan bentuknya? Bagian mana dari kode yang dapat saya ubah tanpa melanggar grafik? Bisakah saya mengubah cara yang tidak merusak niat di balik grafik?
Ira Baxter

@Ira: Setelah mengunjungi halaman web Anda, menjadi lebih jelas bagi saya. Tetapi saya harus mengakui bahwa diskusi semantik tingkat tinggi tentang masalah ini berada di luar keahlian saya. Namun, jika Anda mempertimbangkan nyata kode sebagai bagian dari desain, maka di mana adalah artefak yang sebenarnya? UML - atau notasi lainnya - menurut pendapat saya adalah cetak biru dari struktur kode, dan itu sesuatu yang saya suka sebut bagian dari desain. Lebih dari kode sebenarnya. pikiran bagian . Ini bukan desain, tetapi masih merupakan kontribusi penting untuk itu. lagi, menurut pendapat saya. Dasar pemikiran, dll. Dapat ditambahkan seperti yang dijelaskan.
Joris Meys

@ Jeanis: Sebagian besar notasi diagram dapat dianggap sebagai proyeksi (artefak disimpulkan) dari kode (setidaknya setelah selesai) atau dapat dianggap sebagai pedoman untuk membangun kode (cetak biru). Ada banyak diagram yang mungkin (beberapa tercantum dalam jawaban Anda). Manakah yang mendasar bagi kode yang Anda miliki, dan mana yang merupakan kecelakaan? Diagram alir adalah digram, sehingga harus memenuhi syarat; namun saya cukup yakin bahwa diagram alur beberapa kode tidak akan dianggap sebagai bagian dari desainnya. Jadi, apa yang mendasar? Apa yang tidak disengaja?
Ira Baxter

2

Dari pengalaman pribadi saya, saya berpendapat bahwa kita baik menangkap desain perangkat lunak. Kami memiliki database dokumen persyaratan dan desain untuk setiap fitur tunggal yang pernah kami terapkan pada platform kami. Saya kira keadaan saya mungkin unik. Berikut adalah beberapa hal yang perlu dipikirkan.

Setiap orang di tim saya memiliki gelar teknik ... sebagian besar EE atau CE. Rekayasa mengajarkan Anda desain sebagai bagian dari kurikulum.

Saya pikir ada banyak yang disebut insinyur perangkat lunak yang berasal dari latar belakang CS. Desain perangkat lunak bukan bagian integral dari sebagian besar program CS. Saya tidak mengatakan bahwa semua jurusan CS buruk dalam hal desain, tetapi saya berani bertaruh bahwa sebagian besar tidak memiliki pendidikan formal yang mengajarkannya. Saya pikir banyak orang berasumsi bahwa jika Anda dapat memprogram Anda dapat merancang perangkat lunak, yang tidak benar. Mengingat bahwa banyak programmer tidak memiliki latar belakang teknik, tidak terlalu mengejutkan bahwa banyak proyek perangkat lunak tidak memiliki tim yang pandai menangkap desain.


Jadi, metode spesifik apa yang dibutuhkan untuk menulis dan mendesain dokumen yang Anda gunakan? (Saya melihat bio Anda dan mengharapkan untuk melihat seseorang dari ruang pertahanan dan terkejut). Saya berasumsi dengan persyaratan maksud Anda beberapa teks bahasa alami? ... jika demikian, Anda tidak memiliki argumen tentang mereka? (Saya membedakan persyaratan bahasa alami dari spesifikasi formal). Apakah sudah lengkap? Dan dokumen desainnya? Apakah mereka mutakhir sepenuhnya untuk sistem pengiriman saat ini? Saya akan setuju bahwa banyak yang disebut programmer dan insinyur perangkat lunak tidak, jadi kita bisa tetap membahas apa yang harus dilakukan.
Ira Baxter

1
Saya tidak yakin ada nama khusus untuk metode kami. Persyaratan kami adalah apa yang saya sebut hibrid antara persyaratan bahasa alami dan dokumen desain tingkat tinggi. Kami biasanya memiliki dua putaran pengeditan. Pertama, kami mendokumentasikan apa yang perlu dilakukan fitur dalam bahasa Inggris. Kemudian kami menentukan dengan tepat bagaimana ini akan bekerja dari perspektif pengguna. Dokumen tersebut memiliki dua tujuan. Pertama, kami ingin memberikan dokumen yang dapat ditinjau oleh tim Pemasaran kami untuk memastikan kami memenuhi kebutuhan bisnis kami. Dua, kami ingin memberikan dokumen yang dapat digunakan oleh tim QA kami untuk diuji.
Pemdas

1
Dokumen desain kami jauh lebih formal dan terperinci. Mereka selalu termasuk yang berikut: Beberapa jenis analisis kasus penggunaan, penjelasan tentang perdagangan atau alasan kami memilih cara tertentu dalam melakukan sesuatu, referensi ke desain lain, definisi antarmuka eksplisit, struktur data ... dll. Kami tidak perlu memiliki komentar eksplisit mengenai bagaimana kode spesifik memenuhi persyaratan tertentu. Saya ragu apakah saya pikir ini penting atau tidak.
Pemdas

1
Saya akan mengatakan bahwa dokumen kami mutakhir 95%. Beberapa hal di sana-sini lolos dari celah.
Pemdas

2

Saya melihat dua masalah.

Yang pertama adalah bahwa sangat sulit untuk menjaga sinkronisasi kode dan dokumentasi. Jika mereka terpisah, mereka akan berbeda dan dokumentasi akan menjadi tidak berguna. Pemrogram telah mencoba menggunakan alat untuk melakukan pekerjaan menjaga mereka tetap sinkron (seperti alat KASUS), tetapi alat ini didapat antara pemrogram dan kode mereka, yang melakukan lebih banyak kerusakan daripada kebaikan. Salah satu wawasan kunci dari desain berbasis domain (Evans, 2004) adalah bahwa desain yang baik sangat sulit, jadi untuk mendapatkan sesuatu dari itu, Anda harus:

  • pilih area sekecil mungkin dari program Anda di mana desain yang baik akan menghasilkan manfaat besar, yang disebut domain inti
  • bekerja sangat keras untuk mendapatkan desain yang bagus dalam bentuk bahasa di mana-mana yang semua anggota tim gunakan sepanjang waktu
  • sebisa mungkin, buat bagian desain kode

Masalah besar lainnya dengan cara kita melakukan desain, adalah bahwa metode-desain kita tidak cukup matematis. Abstraksi yang bocor tidak memungkinkan mereka untuk mendapatkan kesimpulan yang kuat dari mereka, dan dunia logika yang diterapkan secara ketat dan kebenaran yang jelas disebut matematika, yang sebagian besar programmer hindari.

Beberapa alat matematika yang kita miliki, seperti metode formal, sangat sulit digunakan.

Mengurangi peta adalah contoh matematika yang bagus dalam pemrograman. Ide intinya adalah ini: Ketika Anda memiliki operasi biner asosiatif, Anda dapat mendistribusikan eksekusi dengan sangat mudah. Operasi biner adalah fungsi dengan dua parameter, asosiasi menunjukkan bahwa (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 adalah

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) di mana As, B, dan Cs secara sepele dapat ditambahkan secara sepele pada lokasi yang berbeda, hasilnya dikumpulkan dan diringkas dalam waktu singkat.

Pengurangan peta adalah ide yang sangat sederhana. Itu bisa dijelaskan di selembar kertas. Jika Anda dapat berasumsi bahwa pembaca memiliki pemahaman yang kuat tentang konsep asosiatif, jika cocok dengan selembar kertas yang cukup kecil. Sekarang coba jelaskan pengurangan peta kepada seseorang tanpa menggunakan istilah associativity atau merujuknya secara tidak langsung. Saya menantang Anda.

Desain perangkat lunak tanpa abstraksi matematika seperti mencoba melakukan arsitektur tanpa harus bersusah payah mempelajari geometri.

Mungkin Haskell dapat memperbaikinya seiring waktu. Penggunaan konsep dari teori kategori untuk menggambarkan program terlihat menjanjikan bagi saya. Teori kategori sangat abstrak sehingga bahkan matematikawan tidak banyak menggunakannya, tetapi rupanya kategori, yang abstrak di luar pengakuan, tampaknya cukup abstrak untuk menggambarkan struktur perangkat lunak. Kami akan mencari tahu. Perlahan.

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.