Saya perlu memulai desain dan pengembangan kerangka kerja baru untuk berinteraksi dengan ECM open source. Ini termasuk model data yang disesuaikan untuk membantu pengembang situs web berinteraksi dengan ECM ini, sehingga mereka tidak perlu peduli dengan detail manipulasi node dan detail tingkat rendah lainnya. Itu hanya sekelompok kelas dan metode untuk dikembangkan.

Saya memiliki keraguan tentang bagaimana menangani organisasi dan manajemen proyek itu: Apakah ada beberapa aturan umum untuk diikuti, tips, praktik terbaik atau sesuatu yang perlu diingat untuk mengembangkan proyek semacam ini?

Saya yakin ada beberapa perbedaan antara pengembangan kerangka kerja atau pustaka dan aplikasi.

Pertama di sini adalah 2 aturan saya untuk menghindari sindrom limbah kerangka:

• Tidak adanya yang sudah ada, mencakup 80% dari kebutuhan saya dan dapat diperpanjang untuk mencocokkan 20% terakhir
• Kepastian yang dekat bahwa saya akan menggunakannya lagi, di aplikasi lain

Setelah Anda melewati itu, lihat ini:

• http://www.slideshare.net/brada/framework-design-guidelines-presentation
• http://www.informit.com/podcasts/episode.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsblogs.com/?tag=microsoft-framework-design-guidelines

1) Fitur hanya dapat ditambahkan ke Kerangka ketika mereka diekstraksi dari kode kerja. Dengan kata lain, sebelum menambahkan ide baru yang keren ke kerangka kerja baru yang keren, pastikan itu benar-benar menambah nilai dan mengurangi pengulangan dalam aplikasi dunia nyata yang berfungsi.

2) Dokumentasi, dokumentasi, dokumentasi.

3) Dokumentasi, dokumentasi, dokumentasi.

Pengalaman yang menyakitkan dan banyak usaha yang sia-sia mengarah pada saran ini: mengekstrak atau memperbaiki kerangka kerja dari perangkat lunak yang berfungsi. Bangun perangkat lunak itu dengan mengingat bahwa Anda pikir Anda ingin mengekstraksi kerangka kerja di masa depan, tetapi jangan membangun kerangka kerja terlebih dahulu.

Saya akan menyarankan buku Kerangka Desain Pedoman . Ini berumur beberapa tahun, tetapi prinsip-prinsipnya tetap benar. Ini memiliki banyak pola dan menjelaskan alasan di balik keputusan yang akan Anda buat ketika membangun kerangka kerja.

1) Tetap pada konvensi yang baik sejak awal, pastikan Anda telah mendokumentasikan konvensi yang sangat spesifik, kerangka kerja terbaik adalah yang konsisten secara internal.

2) Pastikan semuanya terdokumentasi dengan baik, mulai dari komentar kode yang baik hingga menjelaskan apa fungsi paling penting yang diperlukan dan hasilkan, bahkan jika itu tampak sangat sederhana bagi Anda, Anda mungkin memiliki seseorang menggunakannya pada jam 14 dan mereka hanya perlu satu hal saat itu.

3) Tetapkan ringkasan proyek untuk diri Anda sendiri, dengan kerangka kerja yang ingin Anda capai, target yang realistis dan prioritas keseluruhan.

4) Jika tersedia untuk digunakan orang, pastikan Anda memiliki beberapa bentuk proses dukungan / pelacakan bug. Akan ada bug, itu terjadi pada kita semua, tetapi jika Anda bisa mengelolanya dari sana akan membuat hidup Anda lebih mudah.

Semua dalam semua, pendekatan yang mirip untuk membangun aplikasi apa pun, tetapi pengembang bahkan lebih fussier daripada pengguna, dan kerangka kerja terbaik adalah yang kita bisa ambil, masuk akal, dan kita tidak perlu berjuang.

Saya tidak setuju dengan banyak hal yang telah dikatakan dan saya merasa lebih banyak yang tidak disebutkan sehingga saya akan mulai dari awal.

Metodologi Agile

Adopsi metodologi lincah selama pengembangan kerangka kerja Anda sehingga Anda dapat beradaptasi dengan perubahan, bereaksi cepat terhadap penghalang jalan, dan memastikan produk akhir yang fungsional dan berkualitas. Metodologi Agile adalah metodologi yang, menurut "Agile Manifesto", memprioritaskan:

Individu dan interaksi lebih proses dan alat
Bekerja software lebih dokumentasi yang komprehensif
kolaborasi Pelanggan lebih negosiasi kontrak
Menanggapi mengubah lebih mengikuti rencana

Betul. Saya mengatakan fungsionalitas lebih penting daripada dokumentasi. Perhatikan bahwa "Agile Manifesto" menyebutkan bahwa prioritas tangan kanan masih penting, hanya lebih sedikit daripada prioritas di sebelah kiri.

Komunikasi

Siapa pun yang membuat kerangka kerja perlu tahu:

1. Bagaimana ini akan digunakan: aplikasi target
2. Masalah apa yang dimaksudkan untuk dipecahkan: masalah target
3. Siapa yang akan menggunakannya: audiens target

Sebagai contoh, jika sebuah perusahaan berniat untuk mengembangkan aplikasi final dengan ASP. NET akan bodoh untuk mengatakan kepada programmer-nya "membuat kerangka kerja ini" tanpa memberi tahu mereka hal di atas. Jika pemrogram tidak tahu aplikasi target mereka mungkin tidak membuatnya berorientasi web. Jika mereka tidak tahu masalahnya, mereka mungkin membuat kerangka kerja untuk tujuan yang berbeda. Jika mereka tidak tahu audiens mereka dapat memprogram kerangka kerja di C ++. Salah satu dari keadaan ini akan membuat kerangka yang dihasilkan tidak berguna.

Gaya

Tak perlu dikatakan, membangun gaya / format pemrograman dan tetap menggunakannya.

E's

1. Modularitas : Penggunaan kembali kode secara terprogram, bukan secara harfiah.
2. Efisiensi : Kode Anda dimaksudkan untuk digunakan kembali. Kerugian apa pun terhadap kecepatan dikalikan.
3. Maintainability : Anda ingin dapat mengedit kerangka kerja untuk memperbarui beberapa program, tanpa harus memodifikasi program tersebut.
4. Kegunaan : Dapatkah aplikasi benar-benar menggunakan kerangka kerja Anda tanpa melewati rintangan?
5. Kepraktisan : Jangan menemukan kembali roda jika Anda tidak harus melakukannya. Kerangka kerja Anda dapat bergantung pada kerangka kerja lain.
6. Redundansi : Menangkap pengecualian / kesalahan. Dimana mana. Tangani mereka. Dimana mana. Jangan pernah mempercayai kode apa pun kecuali itu dalam lingkup lokal untuk menangani kesalahan, bahkan jika Anda tahu itu benar.

Saya yakin ada beberapa perbedaan antara pengembangan kerangka kerja atau pustaka dan aplikasi.

Proses pengembangan pada dasarnya sama. Perbedaannya mungkin berkaitan dengan masalah pemasaran dan penyebaran, meskipun saya menemukan bahwa perbedaan terbesar biasanya dalam hal cakupan dan definisi proyek. Ingat bahwa Aplikasi dapat menyertakan atau menggunakan kerangka kerja atau perpustakaan, kerangka kerja mungkin kumpulan perpustakaan.

Saya memiliki keraguan tentang bagaimana menangani organisasi dan manajemen proyek itu: Apakah ada beberapa aturan umum untuk diikuti, tips, praktik terbaik atau sesuatu yang perlu diingat untuk mengembangkan proyek semacam ini?

Organisasi dan manajemen proyek sekali lagi sama untuk setiap proyek pengembangan. Sekali lagi turun ke ruang lingkup. Namun ketika harus menulis kerangka kerja, membayar untuk memiliki visi yang sangat jelas tentang apa yang ingin Anda capai, dan untuk menempatkan aturan desain yang ketat pada antarmuka publik ke kerangka kerja untuk memastikan konsistensi dalam hal presentasi API. Jika Anda mengizinkan setiap pengembang untuk melakukan hal mereka sendiri, Anda akan berakhir dengan kekacauan yang rumit, dan desain API yang sangat tidak elegan.

Saya akan merekomendasikan Ryan Hayes yang kedua untuk membaca Pedoman Desain Kerangka meskipun buku itu sendiri bertujuan untuk mengembangkan kerangka kerja berbasis .NET, karena saran umum ini berlaku terlepas dari teknologi implementasi spesifik yang mungkin Anda pilih untuk digunakan.

Dari pengalaman, saya akan menyarankan berpegang teguh pada prinsip YAGNI klasik dengan mengimplementasikan antarmuka publik yang paling sederhana terlebih dahulu, dan kemudian berkembang untuk menawarkan kontrol dan kedalaman yang lebih besar di kemudian hari, tetapi berhati-hatilah untuk menggunakan nama-nama yang berguna untuk menunjukkan mengapa metode atau kelas diperluas. Saya tidak pernah menjadi penggemar menambahkan "Ex" atau sufiks serupa lainnya ke nama metode, atau menambahkan angka ke definisi Antarmuka yang diperluas. Bedakan fungsi, dan nama antarmuka / metode Anda akan menjadi lebih jelas, dan semoga tidak terlalu membingungkan dan membingungkan.