Apakah dokumen uraian arsitektur merupakan pelanggaran terhadap Prinsip KERING?

11

Prinsip KERING (Jangan Ulangi Diri Sendiri) menyatakan bahwa "setiap pengetahuan harus memiliki perwakilan tunggal, tidak ambigu, berwibawa dalam suatu sistem." Sebagian besar waktu ini mengacu pada kode, tetapi sering juga diperluas ke dokumentasi.

Dikatakan bahwa setiap sistem perangkat lunak memiliki arsitektur apakah Anda memilihnya atau tidak. Dengan kata lain, perangkat lunak yang Anda buat memiliki struktur dan struktur "seperti yang dibangun" adalah arsitektur perangkat lunak. Karena sistem perangkat lunak yang dibangun dilengkapi dengan arsitektur, apakah membuat deskripsi arsitektur dari sistem itu melanggar Prinsip KERING? Lagi pula, jika Anda perlu tahu arsitekturnya maka Anda selalu bisa hanya melihat kode ...

— Michael
sumber

Apakah Anda benar-benar yakin dapat membedakan arsitektur dengan melihat kodenya? Kode ini akan memberi tahu Anda semua persyaratan fungsional dan nonfungsional, pertukaran arsitektural, masalah penyebaran, konteks bisnis, skenario penggunaan, dll, dll? Jika kode Anda SANGAT bisa memberi tahu Anda, itu adalah sistem yang sepele.

— luis.espinal

@ luis.espinal, Dimungkinkan untuk membedakan struktur statis dan dinamis dari masing-masing kode dan sistem yang sedang berjalan. Apakah struktur itu setara dengan arsitektur sistem akan tergantung pada aliran pemikiran Anda. Seperti yang telah Anda tunjukkan, Anda masih akan kehilangan sejumlah besar termasuk driver arsitektur dan alasan di balik keputusan desain.

— Michael

Apa aliran pemikiran yang menyamakan struktur yang diturunkan kode dengan arsitektur sistem? Jika kita tahu bahwa kita akan kehilangan sebagian besar termasuk driver arsitektur, maka kita kehilangan seluruh arsitektur. Ini membuktikan secara sepele bahwa struktur statis dan dinamis yang dapat dilihat dari kode saja tidak mewakili keseluruhan arsitektur (terlepas dari mazhab pemikiran). Jika kita melihat definisi sistem dan arsitektur perangkat lunak yang cukup mapan (mis. SEI atau INCOSE's), mereka jelas dalam kode itu hanya sebagian kecil dari arsitektur.

— luis.espinal

Inti masalah. Arsitektur suatu sistem mungkin mengharuskan saya untuk menggunakan sejumlah mesin, dengan antarmuka eksternal dimatikan dan dihidupkan dalam urutan tertentu. Struktur statis dan dinamis yang berasal dari kode saja tidak akan menangkap itu (jika sama sekali.) Namun yang jelas, ini adalah bagian dari aspek penyebaran dan operasional arsitektur sistem. Dan setiap struktur kode yang diturunkan hanya akan berkaitan dengan realisasi aspek statis arsitektur aplikasi perangkat lunak (atau komponen). Itu tidak pernah bisa untuk arsitektur sistem .

— luis.espinal

1

@ luis.espinal, saya mengundang Anda untuk mengirimkan jawaban atas pertanyaan ini! Sepertinya Anda membawa perspektif yang sangat bagus yang menurut saya akan menambah nilai nyata pada topik ini. Anda berkhotbah kepada paduan suara tentang ini, jadi mengapa tidak membuat jawaban yang sepenuhnya menjelaskan pemikiran Anda sehingga semua orang bisa mendapat manfaat? Itu sebabnya saya mengajukan pertanyaan di tempat pertama.

— Michael

11

Apakah menduplikasi pemikiran Anda ke dalam kode melanggar prinsip KERING?

Ya ampun, jika Anda hanya bisa mengetahui arsitektur dengan melihat ke kode, tidak akan ada yang namanya "dokumen deskripsi arsitektur" di tempat pertama. Ini bukan repitisi, ini adalah level deskripsi sistem yang lain , yang tidak dapat disimpulkan secara sepele dari kode, dan sebaliknya. Jadi ia memiliki hak penuh untuk tetap ada bahkan jika Anda merangkul KERING.

— P Shved
sumber

7

Jangan menganggap KERING sebagai aturan yang keras dan cepat. Ini hal yang baik, tetapi Anda hanya bisa memperkirakannya dalam praktik.

Juga saya pikir itu tidak ditulis dengan baik. "Don't repeat yourself" tampaknya tidak mencakup kasus yang sama pentingnya dengan membuat perubahan semantik atau fungsional Anda harus mengedit teks sumber di banyak tempat, mengatakan hal-hal yang berbeda tetapi terkoordinasi.

Daripada menganggapnya sebagai perintah untuk tidak dilanggar, lebih baik untuk memahami mengapa itu adalah ide yang baik dan membuat pilihan yang masuk akal tentangnya. Alasan mengapa harus melakukan pengeditan yang terkoordinasi di banyak tempat adalah karena Anda, editor, melakukan kesalahan. Anda tidak 100% andal untuk melakukan perubahan tanpa kesalahan. Jika Anda harus membuat 10 perubahan teks sumber yang berbeda, dan Anda hanya memperbaikinya 9, Anda telah memasukkan bug . Itulah sebabnya mengatur teks sumber untuk meminimalkan jumlah perubahan terkoordinasi adalah hal yang baik. Ini meminimalkan bug.

Kami bukan milik agama di mana KERING adalah salah satu perintah. Ini hanya cara yang berguna, meskipun sedikit menyesatkan, untuk merangkum akal sehat.

— Mike Dunlavey
sumber

4

Uraian Arsitektur, atau Uraian Desain Perangkat Lunak memang melanggar KERING. Namun, dalam sebuah organisasi besar, di mana proyek-proyek tahun terakhir, pengembang datang dan pergi, dan sistem itu terlalu besar untuk satu orang untuk menyimpan semua detail di kepala mereka, itu adalah dokumen penting. Jumlah "pengulangan" yang diperlukan untuk tetap selaras benar-benar layak untuk upaya yang disimpannya selama pembaruan atau pemeliharaan berikutnya.

— ASHelly
sumber

1

Itu adalah kesalahpahaman atau aplikasi KERING yang buta. Deskripsi arsitektur bukanlah pelanggaran terhadapnya. Jika seseorang secara membabi buta menerapkan KERING dengan cara ini, maka apa pun kecuali kode itu merupakan pelanggaran terhadapnya ... dan jelas ini bukan maksud dari mereka yang datang dengan gagasan itu.

— luis.espinal

2

Deskripsi arsitektur tidak melanggar prinsip KERING.

Sistem perangkat lunak Anda hadir dengan arsitektur, tentu saja. Dan itu tersebar di banyak file, di banyak kelas, dengan banyak tambahan dan detail yang tidak perlu untuk ikhtisar.

Dokumen arsitektur Anda harus seperti paragraf pertama dari laporan berita: ini adalah garis besar, ringkasan, peta jalan proyek.

— Frank Shearar
sumber

1

Jika Anda memberi tanggal pada dokumen, itu kemudian menjelaskan arsitektur pada saat penulisan.

Sedangkan kode mewakili arsitektur saat ini.

Dua hal yang terpisah - bukan pengetahuan yang sama.

Selama Anda menyatakan bahwa dokumen tersebut mewakili architecure pada saat penulisan, Anda tidak menduplikasi pengetahuan IMO karena pengetahuan yang berbeda jika itu tentang sistem di titik lain waktu.

— Tak seorangpun
sumber

Kode tidak pernah mewakili arsitektur. Itu hanya manifestasi dari arsitektur. Kode yang diubah hari ini mungkin masih mewakili arsitektur kemarin. Selain itu, mungkin tidak mewakili arsitektur yang dimaksudkan (atau diperlukan secara kontrak), yang merupakan hal yang paling Anda khawatirkan. Kode tidak memberi tahu Anda apakah itu benar atau salah, hanya saja kode itu berjalan. Untuk mengetahui apakah itu benar atau salah, Anda harus melihat arsitektur yang dimaksud dan persyaratan yang mendorong sistem untuk memulai.

— luis.espinal