Açık kaynaklı bir ECM ile etkileşim kurmak için yeni bir çerçeve tasarlamaya ve geliştirmeye başlamam gerekiyor. Bu, web sitesi geliştiricilerinin bu ECM ile etkileşime girmesine yardımcı olmak için özelleştirilmiş bir veri modeli içerir, bu nedenle düğümlerin manipülasyonunun ayrıntılarını ve diğer düşük düzey ayrıntılarını önemsemeleri gerekmez. Bu sadece bir grup ders ve geliştirilecek yöntem.

Bu projenin organizasyonu ve yönetimiyle ilgili bazı şüphelerim var: Bu tür bir projeyi geliştirmek için izlenecek bazı genel kurallar, ipuçları, en iyi uygulamalar veya akılda tutulması gereken bir şey var mı?

Eminim ki bir çerçevenin veya kütüphanenin geliştirilmesi ile bir uygulama arasında bir fark vardır.

İlk olarak çerçeve atık sendromundan kaçınmak için 2 kuralım:

• İhtiyacımın% 80'ini karşılayan ve son% 20'ye uyacak şekilde genişletilebilen mevcut bir kişinin yokluğu
• Başka bir uygulamada tekrar kullanacağım kesinliği

Bunları geçtikten sonra şuna bakın:

• 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) Özellikler, yalnızca çalışma kodundan çıkarıldıklarında bir Framework'e eklenmelidir. Başka bir deyişle, havalı yeni fikrinizi havalı yeni çerçevenize eklemeden önce, çalışan, gerçek dünya uygulamasında gerçekten değer kattığından ve tekrarlamayı azalttığından emin olun.

2) Dokümantasyon, dokümantasyon, dokümantasyon.

3) Dokümantasyon, dokümantasyon, dokümantasyon.

Acı veren deneyim ve çok fazla boşa giden çaba bu tavsiyeye yol açar: çalışan yazılımlardan bir çerçeveyi çıkarın veya yeniden düzenleyin. Gelecekte bir çerçeve ayıklamak isteyeceğinizi düşünerek bu yazılımı geliştirin, ancak önce çerçeveyi oluşturmayın.

Çerçeve Tasarım Yönergeleri kitabını öneririm . Birkaç yaşında, ancak ilkeler geçerli. Bir ton desen vardır ve bir çerçeve oluştururken vereceğiniz kararların ardındaki mantığı açıklar.

1) En başından itibaren iyi sözleşmelere sadık kalın, çok özel bir sözleşmeyi belgelediğinizden emin olun, en iyi çerçeveler dahili olarak tutarlı olanlardır.

2) İyi kod yorumlarından en önemli fonksiyonların neye ihtiyaç duyduğunu ve ürettiğini açıklamaya kadar her şeyin son derece belgelendiğinden emin olun, size çok basit görünse bile, birisinin 14. düz saatte kullanmasını sağlayabilirsiniz ve o zaman sadece bir şeye ihtiyacım var.

3) Çerçevenin gerçekleştirmesini istediğiniz şey, gerçekçi hedefler ve genel önceliklerle kendiniz için bir proje özeti hazırlayın.

4) Kişilerin kullanabileceği bir yer varsa, bir tür destek süreci / hata takibi uyguladığınızdan emin olun. Hatalar olacak, bu hepimize olur, ancak onları kapalı olarak yönetebilirseniz hayatınızı kolaylaştıracaktır.

Sonuçta, herhangi bir uygulama oluşturmaya benzer bir yaklaşım, ancak geliştiriciler kullanıcılardan bile daha karışıktır ve en iyi çerçeveler, alabileceğimiz, anlamlandırabildiğimiz ve savaşmak zorunda olmadığımız çerçevelerdir.

Söylenenlerin çoğuna katılmıyorum ve sıfırdan başlayacağımdan daha fazlasının bahsedilmediğini hissediyorum.

Çevik Metodolojiler

Çerçeve gelişiminiz sırasında değişime uyum sağlayabilmeniz, birlikte gösterimlere hızlı tepki verebilmeniz ve işlevsel, kaliteli bir nihai ürün sağlayabilmeniz için çevik metodolojiler benimseyin. Çevik metodolojiler, "Çevik Manifesto" ya göre öncelik verilenlerdir:

Bireyler ve etkileşimler üzerinde süreçleri ve araçları
yazılım Çalışma üzerinde kapsamlı dokümantasyon
Müşteri işbirliği üzerinde sözleşme müzakere
yanıt değiştirmek için üzerinde bir plan şu

Doğru. İşlevselliğin dokümantasyondan daha önemli olduğunu söyledim. "Agile Manifesto" nun sağdaki önceliklerin hala soldakilerden daha az önemli olduğunu belirtti.

İletişim

Çerçeveyi kimin bilmesi gerekiyor:

1. Nasıl kullanılacaktır: hedef uygulama
2. Hangi sorunu çözmesi amaçlanıyor: hedef problem
3. Kim kullanacak: hedef kitle

Örneğin, bir şirket ASP .NET ile son bir uygulama geliştirmeyi planlıyor olsaydı, programcılarına yukarıdakileri söylemeden "bu çerçeveyi yapmasını" söylemek aptalca olur. Programcılar hedef uygulamayı bilmiyorlarsa, web tabanlı yapamazlar. Eğer sorunu bilmiyorlarsa, farklı bir amaç için bir çerçeve oluşturabilirler. Eğer izleyiciyi bilmiyorlarsa, çerçeveyi C ++ ile programlayabilirler. Bu koşullardan herhangi biri, ortaya çıkan çerçeveyi işe yaramaz hale getirecektir.

stil

Söylemeye gerek yok, bir programlama stili / formatı oluşturun ve buna bağlı kalın.

E'ler

1. Modülerlik : Kodu tam anlamıyla değil, programlı olarak yeniden kullanın.
2. Verimlilik : Kodunuz yeniden kullanılmak üzere tasarlanmıştır. Hızlanacak her türlü zarar çoğalır.
3. Sürdürülebilirlik : Söz konusu programları değiştirmek zorunda kalmadan birkaç programı güncellemek için çerçeveyi düzenlemek isteyebilirsiniz.
4. Kullanılabilirlik : Uygulamalar çerçevenizi kasnaklardan atlamaksızın kullanabilir mi?
5. Pratiklik : Gerekmiyorsa tekerleği yeniden icat etmeyin. Çerçeveniz diğer çerçevelere bağlı olabilir.
6. Artıklık : Yakalama istisnaları / hataları. Her yerde. Onları idare edin. Her yerde. Biliyor olsanız bile, yerel kapsamdaki hataları işlemek için başka hiçbir koda güvenmeyin.

Eminim ki bir çerçevenin veya kütüphanenin geliştirilmesi ile bir uygulama arasında bir fark vardır.

Geliştirme süreçleri esasen aynıdır. En büyük farklılıkların genellikle proje kapsamı ve tanımı açısından olduğunu fark etsem de, farklılıklar pazarlama ve dağıtım sorunlarına gelebilir. Bir Uygulamanın bir çerçeve veya kütüphane içerebileceğini veya kullanabileceğini, bir çerçevenin bir kütüphane koleksiyonu olabileceğini unutmayın.

Bu projenin organizasyonu ve yönetimiyle ilgili bazı şüphelerim var: Bu tür bir projeyi geliştirmek için izlenecek bazı genel kurallar, ipuçları, en iyi uygulamalar veya akılda tutulması gereken bir şey var mı?

Proje organizasyonu ve yönetimi, herhangi bir geliştirme projesi için yine aynıdır. Yine kapsama giriyor. Bununla birlikte, bir çerçeve yazmak söz konusu olduğunda, elde etmeye çalıştığınız şey hakkında çok net bir vizyona sahip olmak ve API'nın sunumu açısından tutarlılığı sağlamak için çerçeveye genel arayüze katı tasarım kuralları koymak gerekir. Her geliştiricinin kendi işini yapmasına izin verirseniz, karmaşık bir karmaşa ve çok beceriksiz bir API tasarımı elde edersiniz.

Kitabın kendisi .NET tabanlı çerçeveler geliştirmeyi amaçlasa da Ryan Hayes'in Çerçeve Tasarım Yönergeleri'ni okuma önerisini kullanacağım , çünkü genel tavsiye, kullanmayı seçebileceğiniz belirli uygulama teknolojilerinden bağımsız olarak uygulanabilir.

Deneyimden, önce en basit kamu arayüzlerini uygulayarak ve daha sonra daha fazla kontrol ve derinlik sunmak için genişleyerek klasik YAGNI prensibine bağlı kalmanızı tavsiye ederim, ancak yöntemlerin veya sınıfların neden genişletildiğini göstermek için yararlı isimler kullanmaya dikkat edin. Yöntem adlarına "Ex" veya diğer benzer sonekleri eklemenin veya genişletilmiş Arayüz tanımlarına sayı eklemenin hayranıyım. İşlevselliği farklılaştırın ve arayüz / yöntem adlarınız daha net olmalı ve umarım daha az gizlenmiş ve kafa karıştırıcı olmalıdır.