Tôi cần bắt đầu thiết kế và phát triển một khung công tác mới để tương tác với ECM mã nguồn mở. Điều này bao gồm một mô hình dữ liệu tùy chỉnh để giúp các nhà phát triển trang web tương tác với ECM này, vì vậy họ không cần quan tâm đến các chi tiết về thao tác nút và các chi tiết cấp thấp khác. Đó chỉ là một loạt các lớp học và phương pháp để phát triển.

Tôi có một số nghi ngờ về cách xử lý tổ chức và quản lý dự án đó: Có một số quy tắc chung để tuân theo, mẹo, thực tiễn tốt nhất hoặc một số điều cần lưu ý để phát triển loại dự án này?

Tôi chắc chắn có một số khác biệt giữa sự phát triển của một khung hoặc thư viện và một ứng dụng.

Đầu tiên, đây là 2 quy tắc của tôi để tránh hội chứng lãng phí khung:

• Sự vắng mặt của một cái hiện có, đáp ứng 80% nhu cầu của tôi và có thể mở rộng để phù hợp với 20% cuối cùng
• Gần như chắc chắn rằng tôi sẽ sử dụng nó một lần nữa, trong một ứng dụng khác

Sau khi bạn vượt qua những điều đó, hãy kiểm tra điều này:

• http://www.sl slideshoware.net/brada/framework-design-guferences-presentation
• http://www.informit.com/podcasts/epiT.aspx?e=5a161893-c1ce-4449-8b67-31baa54ce316
• http://www.marlabsbloss.com/?tag=microsoft-framework-design-guferences

1) Các tính năng chỉ nên được thêm vào Khung khi chúng được trích xuất từ ​​mã làm việc. Nói cách khác, trước khi thêm ý tưởng mới tuyệt vời của bạn vào khuôn khổ mới tuyệt vời của bạn, hãy đảm bảo rằng nó thực sự tăng giá trị và giảm sự lặp lại trong một ứng dụng thực tế đang hoạt động.

2) Tài liệu, tài liệu, tài liệu.

3) Tài liệu, tài liệu, tài liệu.

Kinh nghiệm đau đớn và rất nhiều nỗ lực lãng phí dẫn đến lời khuyên này: trích xuất hoặc cấu trúc lại một khung từ phần mềm làm việc. Xây dựng phần mềm đó lưu ý rằng bạn nghĩ rằng bạn sẽ muốn trích xuất một khung trong tương lai, nhưng trước tiên đừng xây dựng khung.

Tôi muốn đề xuất cuốn sách Hướng dẫn thiết kế khung . Đó là một vài năm tuổi, nhưng các nguyên tắc vẫn còn đúng. Nó có rất nhiều mẫu và giải thích lý do đằng sau các quyết định bạn sẽ đưa ra khi xây dựng một khung.

1) Bám sát các quy ước tốt ngay từ đầu, đảm bảo bạn đã ghi lại một quy ước rất cụ thể, các khung tốt nhất là các quy ước nhất quán trong nội bộ.

2) Hãy chắc chắn rằng mọi thứ đều được ghi chép kỹ lưỡng, từ các bình luận mã tốt cho đến giải thích những gì các chức năng quan trọng nhất yêu cầu và sản xuất, ngay cả khi nó có vẻ siêu đơn giản đối với bạn, bạn có thể có ai đó sử dụng nó vào giờ thứ 14 liên tiếp chỉ cần một điều đó ngay sau đó

3) Đặt ra một bản tóm tắt dự án cho chính bạn, với những gì bạn muốn khung đạt được, các mục tiêu thực tế và các ưu tiên tổng thể.

4) Nếu mọi người sẽ sử dụng, hãy đảm bảo rằng bạn đã có một số hình thức hỗ trợ / theo dõi lỗi tại chỗ. Sẽ có lỗi, nó xảy ra với tất cả chúng ta, nhưng nếu bạn có thể quản lý chúng từ bên ngoài thì nó sẽ giúp cuộc sống của bạn dễ dàng hơn.

Nhìn chung, cách tiếp cận tương tự để xây dựng bất kỳ ứng dụng nào, nhưng các nhà phát triển thậm chí còn ồn ào hơn người dùng và các khung tốt nhất là những khung mà chúng ta có thể chọn, có ý nghĩa và chúng ta không phải chiến đấu.

Tôi không đồng ý với rất nhiều điều đã được nói và tôi cảm thấy rằng nhiều điều chưa được đề cập đến nên tôi sẽ bắt đầu lại từ đầu.

phương pháp Agile

Áp dụng các phương pháp nhanh trong quá trình phát triển khung của bạn để bạn có thể thích ứng với thay đổi, phản ứng nhanh với các rào cản và đảm bảo một sản phẩm cuối cùng có chất lượng, có chức năng. Các phương pháp Agile là những phương pháp mà theo "Tuyên ngôn Agile", ưu tiên:

Các cá nhân và tương tác qua các quá trình và các công cụ
phần mềm làm việc trên toàn diện các tài liệu
hợp tác của khách hàng qua đàm phán hợp đồng
ứng phó biến đổi qua sau một kế hoạch

Đúng rồi. Tôi nói chức năng quan trọng hơn tài liệu. Lưu ý rằng "Tuyên ngôn Agile" đề cập rằng các ưu tiên bên tay phải vẫn quan trọng, chỉ kém hơn các bên trái.

Giao tiếp

Bất cứ ai đang làm cho khung cần phải biết:

1. Làm thế nào nó sẽ được sử dụng: ứng dụng mục tiêu
2. Vấn đề gì nó được dự định để giải quyết: vấn đề mục tiêu
3. Ai sẽ sử dụng nó: đối tượng mục tiêu

Ví dụ, nếu một công ty đang có ý định phát triển một ứng dụng cuối cùng với ASP .NET, thật ngu ngốc khi nói với các lập trình viên của mình "tạo khung này" mà không nói với họ những điều trên. Nếu các lập trình viên không biết ứng dụng đích thì họ có thể không làm cho nó hướng đến web. Nếu họ không biết vấn đề, họ có thể tạo ra một khuôn khổ cho một mục đích khác. Nếu họ không biết khán giả, họ có thể lập trình khung trong C ++. Bất kỳ trường hợp nào trong số này sẽ khiến khung kết quả trở nên vô dụng.

Phong cách

Không cần phải nói, thiết lập một phong cách / định dạng lập trình và gắn bó với nó.

E

1. Modularity : Tái sử dụng mã theo chương trình, không theo nghĩa đen.
2. Hiệu quả : Mã của bạn được dự định để sử dụng lại. Bất kỳ bất lợi cho tốc độ được nhân lên.
3. Khả năng bảo trì : Bạn muốn có thể chỉnh sửa khung để cập nhật một số chương trình mà không phải sửa đổi các chương trình đã nói.
4. Khả năng sử dụng : Các ứng dụng thực sự có thể sử dụng khuôn khổ của bạn mà không cần nhảy qua vòng?
5. Tính thực tiễn : Đừng phát minh lại bánh xe nếu bạn không phải làm như vậy. Khung của bạn có thể phụ thuộc vào các khung khác.
6. Dự phòng : Bắt ngoại lệ / lỗi. Mọi nơi. Xử lý chúng. Mọi nơi. Không bao giờ tin tưởng bất kỳ mã nào nhưng trong phạm vi cục bộ để xử lý lỗi, ngay cả khi bạn biết rằng nó có.

Tôi chắc chắn có một số khác biệt giữa sự phát triển của một khung hoặc thư viện và một ứng dụng.

Các quá trình phát triển về cơ bản là giống nhau. Sự khác biệt có thể đến từ các vấn đề tiếp thị và triển khai, mặc dù tôi thấy rằng sự khác biệt lớn nhất thường là về phạm vi và định nghĩa dự án. Hãy nhớ rằng một Ứng dụng có thể bao gồm hoặc sử dụng một khung hoặc một thư viện, một khung có thể là một tập hợp các thư viện.

Tôi có một số nghi ngờ về cách xử lý tổ chức và quản lý dự án đó: Có một số quy tắc chung để tuân theo, mẹo, thực tiễn tốt nhất hoặc một số điều cần lưu ý để phát triển loại dự án này?

Tổ chức và quản lý dự án một lần nữa giống nhau cho bất kỳ dự án phát triển. Một lần nữa nó đi xuống phạm vi. Tuy nhiên, khi viết một khung công tác, cần phải có một tầm nhìn rất rõ ràng về những gì bạn đang cố gắng đạt được và đặt các quy tắc thiết kế nghiêm ngặt trên giao diện công cộng vào khung để đảm bảo tính nhất quán về cách trình bày của API. Nếu bạn cho phép mọi nhà phát triển thực hiện công việc của riêng họ, bạn sẽ kết thúc với một mớ hỗn độn phức tạp và thiết kế API rất không phù hợp.

Tôi sẽ khuyến nghị Ryan Hayes đọc Hướng dẫn thiết kế khung mặc dù cuốn sách này nhằm phát triển các khung dựa trên .NET, vì lời khuyên chung được áp dụng bất kể các công nghệ triển khai cụ thể mà bạn có thể chọn sử dụng.

Từ kinh nghiệm, tôi sẽ khuyên bạn nên tuân thủ nguyên tắc YAGNI cổ điển bằng cách triển khai các giao diện công cộng đơn giản nhất trước, sau đó mở rộng để cung cấp quyền kiểm soát và độ sâu lớn hơn sau này, nhưng hãy cẩn thận sử dụng các tên hữu ích để chỉ ra lý do tại sao các phương thức hoặc lớp được mở rộng. Tôi chưa bao giờ là người hâm mộ của việc thêm "Ex" hoặc các hậu tố tương tự khác vào tên phương thức hoặc thêm số vào định nghĩa Giao diện mở rộng. Phân biệt chức năng và tên giao diện / phương thức của bạn sẽ trở nên rõ ràng hơn và hy vọng ít bị xáo trộn và khó hiểu hơn.