Tôi là một nhà phát triển web sắp mở khóa thành tích "Thư viện hạng nhất được xuất bản" trong sự nghiệp của tôi và tôi đang đổ mồ hôi đạn (tôi thức cả đêm vì căng thẳng). Tôi muốn khai thác trải nghiệm của cộng đồng để xem có ai có bất kỳ đề xuất hoặc đề xuất nào để đảm bảo việc này diễn ra suôn sẻ nhất có thể không. Có bất kỳ chi tiết cụ thể hoặc gotchas tôi cần phải nhận thức? Bất cứ điều gì đặc biệt về quá trình xây dựng có thể quay lại cắn tôi?

Đây là nơi tôi đang ở:

• Thư viện là đơn vị được thử nghiệm và có độ bao phủ mã khoảng 97%
• API được ghi lại tốt và các tài liệu xml để hỗ trợ intellisense đã được tạo
• Tôi đã đảm bảo rằng những người truy cập lớp công / tư là chính xác và chính xác. Điều tương tự cũng xảy ra với tất cả các getters / setters
• Việc xử lý lỗi không phải là duyên dáng như tôi mong muốn, nhưng tôi đã hết thời hạn và đã chấp nhận rằng đó là "tốt như nó sẽ xảy ra" cho đến bây giờ
• Không đăng nhập thân thiện. Debug.Writeline đã được sử dụng rộng rãi ... Gần đây tôi đã biết rằng đây là sự phản ánh về sự thiếu kinh nghiệm của tôi :(

Lời khuyên của bạn rất hay!

Thư viện sẽ được sử dụng để tạo báo cáo. Mũ tiêu chuẩn - kết nối với cơ sở dữ liệu chỉ đọc, thực hiện calcs, định dạng và xuất dữ liệu ra luồng phản hồi.

Tôi đã khai thác như một nguồn tài nguyên bên lề để điền vào một trong những lập trình viên đã bỏ việc, và nhiệm vụ này được giao cho tôi như một dự án "cắt răng của bạn". Thư viện lớp sẽ được phát hành cho các lập trình viên khác trong công ty sử dụng trong khi họ viết mã sản xuất.

Khóa API

Nghệ thuật xây dựng API hiệu quả cũng giống như quản lý các kỳ vọng cũng như về cấu trúc.

Khi tôi nói API, tôi đặc biệt đề cập đến cách các lớp / phương thức công khai / nội bộ được đặt tên và mức độ truy cập của chúng là gì (tức là riêng tư / công khai / nội bộ).

Nếu bạn lo lắng rằng mã có thể chưa hoàn toàn sẵn sàng cho thời gian chính, ban đầu bạn luôn có thể xuất bản nó dưới dạng beta.

Phát hành:

• Beta (tức là trước 1.0)

  • có thể chứa nhiều thay đổi phá vỡ API
  • có thể thiếu các thay đổi tương thích ngược giữa các phiên bản
  • có thể thiếu đánh bóng

• Chính thức (1.0+)

  • API bị khóa cho đến khi phát hành chính tiếp theo
  • mọi thay đổi được giới thiệu sẽ đảm bảo khả năng tương thích ngược

• Nhỏ (ví dụ 1.1)

  • chứa sửa lỗi và - hoặc triển khai tính năng
  • có thể bổ sung nhưng không lấy đi từ API đã xác định

Nếu bạn nghĩ rằng API cần phải được làm cứng một số thì hãy phát hành nó trong một thời gian dưới dạng beta. Điều đó báo hiệu rằng nó có sẵn để sử dụng nhưng không nên được sử dụng cho sản xuất và / hoặc mã quan trọng.

Nhiều người coi các sơ đồ phiên bản được đánh số như hogwash nhưng khi chúng được sử dụng hiệu quả, chúng có thể được sử dụng để cung cấp một số phòng ngọ nguậy cho đến khi bạn sắp xếp cấu trúc.

Giả định của bạn về cách nó sẽ được sử dụng là sai

Cho dù thứ gì đó được thiết kế tốt đến đâu, mọi người sẽ tìm cách lạm dụng hoặc tạo ra một cách sử dụng thay thế.

Một cách để xử lý vấn đề này là khóa càng nhiều việc triển khai càng tốt bằng cách sử dụng các bộ truy cập (tức là riêng tư / công cộng / nội bộ) nhưng không có số lượng thiết kế hoặc kỹ thuật nào sẽ cung cấp cho bạn nhiều thông tin chi tiết như phát hành mã cho người dùng.

Nó thực sự không quan trọng đến mức nào "hoàn hảo" mà bạn nghĩ rằng mã của bạn có thể trở thành, người dùng của bạn sẽ chứng minh rằng không phải như vậy.

Tôi sẽ lập luận rằng đây là lý do chính tại sao việc sử dụng một cơ sở mã hiện có luôn tốt hơn là viết lại đầy đủ. Tốt nhất là một bản viết lại hoàn chỉnh sẽ cắt bớt sự phình to nhưng có khả năng cao là cơ sở mã mới sẽ chứa nhiều lỗi (và có thể nhiều hơn) như cơ sở mã gốc.

Trong trường hợp của bạn, bạn đang chiến đấu căng thẳng từ đầu để có thể bắt đầu.

Có vẻ như bạn có phần còn lại của căn cứ của bạn được bảo hiểm. Tài liệu API rất quan trọng và các thử nghiệm sẽ tốt để đảm bảo sự ổn định khi các thay đổi được thực hiện trong tương lai.

Việc thực hiện một lược đồ ghi nhật ký nhất quán sẽ rất quan trọng trước khi mã được phát hành để sản xuất vì bạn sẽ cần một cách để bật / tắt / lọc toàn bộ nhật ký trên toàn cầu. BTW, trong hầu hết các trường hợp, việc ghi nhật ký chỉ thực sự liên quan đến việc nhập thư viện và thay đổi các cuộc gọi đầu ra từ Debug.WriteLine () thành một cái gì đó như Logging.Debug (), Logging.Info (), Logging.Error (). Bản thân logger chỉ cung cấp một triển khai tiêu chuẩn cho cấu hình, lọc và một phạm vi rộng hơn của các lược đồ đầu ra (tệp ex, console, v.v.).

Ngoài ra, tôi muốn lấy mã ra và được sử dụng. Ngay cả khi chỉ bởi một số lượng nhỏ người dùng để bắt đầu.

Đây là hai điều mà tôi thấy là chìa khóa để phát hành phần mềm:

• Biết chính xác những gì bạn đã phát hành
• Quản lý kỳ vọng

Bạn muốn có thể quay lại và sửa lỗi những gì bạn đã phát hành và bạn muốn mọi người hiểu vấn đề mà mã của bạn sẽ giải quyết.

Biết những gì bạn đã phát hành

Hãy chắc chắn rằng bạn đã có phiên bản và ký chính xác (nếu bị khủng bố). Sử dụng kiểm soát nguồn của bạn để gắn thẻ \ gắn nhãn mã được liên kết với phiên bản được phát hành chính thức. Điều này sẽ giúp bạn xác định các lỗi dễ dàng hơn vì bạn có thể quay lại chính xác mã nguồn bạn đã phát hành. Nó cũng sẽ giúp giảm dòng khi bạn có thể có một vài phiên bản phát hành khác nhau.

Cố gắng làm cho phiên bản mới nhất dễ dàng nắm bắt và cập nhật. Cho dù đó là một trình cài đặt, hay chỉ đơn giản là đưa nó vào một chia sẻ chung phụ thuộc vào ai \ khi nào \ bạn sẽ giao hàng thường xuyên như thế nào.

Hãy chắc chắn rằng bạn có ai đó xem lại bản phát hành cuối cùng của bạn, bao gồm cả tài liệu. Rất dễ trở nên lo lắng hoặc phấn khích về việc phát hành phần mềm và bỏ lỡ điều gì đó.

Quản lý kỳ vọng

Tài liệu về những hạn chế và làm cho chúng rõ ràng hợp lý cho các nhà phát triển. Thật tốt khi bạn đã tìm thấy chúng. Mọi người thường hiểu hơn nếu họ biết những hạn chế với phần mềm của bạn, đặc biệt nếu bạn có kế hoạch sửa chúng.

Tài liệu bạn muốn phản hồi như thế nào, tốt hay xấu. Vì đây là một dự án nội bộ, nếu mọi người đều có quyền truy cập vào một hệ thống theo dõi lỗi phổ biến, hãy yêu cầu họ gửi các lỗi chống lại dự án phù hợp.

Trong tương lai, tránh thay đổi API nếu có thể, đây là một điều có khả năng gây khó chịu cho khách hàng của bạn. Hãy nhớ rằng các ngoại lệ cũng là một phần của API, mặc dù trong C # chúng không phải là một phần của tài liệu phương thức. Có thể cải thiện các ngoại lệ được đưa ra vào một ngày sau đó, nhưng bạn sẽ cần nói chuyện với người dùng cuối và xem nó sẽ có tác động gì.

Tôi có một danh sách kiểm tra các triển khai mà bạn có thể thấy hữu ích. Tôi làm phát triển máy tính để bàn nhưng một số điều này nên dịch. Đây là một số trong đó:

Chung:

• Đặt trong kiểm tra null cho các tham số chức năng không nên null. Điều này giúp tôi thất bại sớm.
• Xóa các bình luận không cần thiết và các tập tin nhận xét. Những nguyên nhân công việc trong tương lai.
• Tìm kiếm mọi bình luận "// TODO". Đôi khi tôi để lại ghi chú cho chính mình. Đôi khi tôi quên chúng.
• Chạy thử nghiệm mã của tôi bằng cơ sở dữ liệu sản xuất nếu có thể. Điều này giúp đảm bảo tôi có tất cả các thay đổi cơ sở dữ liệu của mình trên máy chủ sản xuất.
• Đưa vào đăng nhập nhiều. Đặc biệt là cho một triển khai ban đầu. Trong thực tế, tôi lưu ghi nhật ký cuối cùng vì mã của tôi thường được ghi một số điểm tại thời điểm này. Bạn không muốn ở trong một tình huống mà bạn gặp sự cố và bạn tự nói với mình "Giá như tôi biết giá trị của X là gì vào lúc này". Hãy cố gắng lên kế hoạch trước.
• Cố gắng bọc các cuộc gọi thư viện của bên thứ ba trong Mặt tiền. Điều này giúp dễ dàng thay đổi thư viện trong tương lai cũng như cung cấp danh sách kiểm tra những gì bạn yêu cầu từ thư viện.

.Net cụ thể:

• Đảm bảo tôi đang gọi Dispose () trên các đối tượng dùng một lần. Tôi sử dụng Phân tích mã hoặc FxCop để giúp tìm các trường hợp này.
• Đảm bảo tôi không xử lý tất cả các trình xử lý sự kiện đúng cách. Điều này ngăn chặn rò rỉ bộ nhớ.