Các đặc điểm hoặc tính năng của mã chất lượng sản xuất là gì?

Đây là lần đầu tiên tôi sẽ phân phối mã cho một dự án tự do (ứng dụng web) và vì tôi không có nhiều kinh nghiệm về mã vận chuyển, tôi gặp khó khăn trong việc quyết định liệu chương trình của tôi đã sẵn sàng để triển khai hay chưa.

Tôi hiểu rằng mã cấp độ sản xuất phải có các đặc điểm sau:

Khả năng chịu lỗi : khả năng sống sót ngoại lệ
Dự phòng dữ liệu : không bao giờ mất dữ liệu người dùng
Khả năng mở rộng : Xử lý tải thêm không nên yêu cầu viết lại ứng dụng
Kiểm tra phạm vi : một lượng mã "khá" được kiểm tra

Một số đặc điểm này dành riêng cho chương trình, trong khi các đặc điểm khác liên quan đến môi trường hơn (cho dù sử dụng nhiều cụm). Tuy nhiên, ngay cả các đặc điểm phụ thuộc vào môi trường cũng ảnh hưởng đến cách thiết kế chương trình.

Câu hỏi của tôi là: các đặc điểm khác làm cho mã sản xuất khác với mã không có nghĩa là gì để sản xuất?

Chỉ cần giảm phạm vi câu hỏi, vui lòng chỉ tập trung vào các ứng dụng web .

Chỉnh sửa : Tôi sẽ cố gắng thu hẹp phạm vi bằng cách yêu cầu các đặc điểm cụ thể cho tình huống của tôi. Là một người làm việc tự do, tôi chịu trách nhiệm về mọi thứ, từ việc mua VPS, cấu hình nó, viết mã, triển khai nó. Mặc dù dự án và thiết lập của nó được ghi lại tốt, khách hàng sẽ không thể duy trì nó. Ứng dụng này không phức tạp, nhưng phụ thuộc vào rất nhiều thành phần bên ngoài, điều này khiến nó thực sự dễ bị hỏng nếu các thành phần này thay đổi / biến mất. Mục tiêu là thiết lập một dịch vụ có thể tồn tại lâu nhất có thể mà không cần sự can thiệp của khách hàng.

web-applications freelancing production

— rấtbadalloc
nguồn

Khả năng mở rộng cũng có thể đề cập đến khả năng cho một hệ thống mở rộng theo yêu cầu. Một số người gọi nó là Khả năng mở rộng. Có lẽ điều đó xứng đáng một điểm trong danh sách của bạn. Thực tế là, nếu nó không thể được gia hạn một cách dễ dàng .. bạn lãng phí thời gian để viết lại lớn chỉ để thêm một tính năng .. và trong một số trường hợp (không phải tất cả) .. bạn không thể tính thêm thời gian đó.

— Simon Whitehead

Có quá nhiều câu trả lời có thể, hoặc câu trả lời tốt sẽ quá dài cho định dạng này. Vui lòng thêm chi tiết để thu hẹp bộ câu trả lời hoặc để cách ly một vấn đề có thể được trả lời trong một vài đoạn.

— gnat

Mục đích dự định của ứng dụng của bạn là gì? Có phải nó đang chơi âm thanh rắm? Có phải nó đang kiểm soát lại tàu con thoi?

— el.pescado

"Mã chất lượng sản xuất" là bất cứ người dùng nào khác, không phải bạn, là ...

có thể sử dụng mà không cần hoặc hỗ trợ tối thiểu. Nếu mọi hành động đều gặp lỗi, phần mềm của bạn sẽ rơi vào thùng rác
có thể hiểu làm thế nào để sử dụng với sự hỗ trợ hoặc tài liệu tối thiểu. Nếu người dùng của bạn không thể hiểu cách sử dụng phần mềm của bạn, nó sẽ đi vào thùng rác.
sẵn sàng sử dụng vì nó làm tăng giá trị Nếu phần mềm của bạn thêm đủ giá trị, có thể họ thậm chí sẽ cho bạn tiền cho nó. Nếu nó không thêm đủ giá trị để bạn cung cấp miễn phí, phần mềm của bạn sẽ bị vứt vào thùng rác.

ĐÓ LÀ NÓ.

Một số người cần khả năng chịu lỗi tuyệt đối. Những người khác không bận tâm nhiều nếu một số dữ liệu bị mất khi có sự cố ... giả sử họ thấy sự cố rất không thường xuyên. Không có phẩm chất hoặc yêu cầu thiết lập cứng. Và không có khách hàng quan tâm đến phạm vi kiểm tra, điều họ quan tâm là ba điểm trên. Kiểm tra bảo hiểm là một công cụ (một trong nhiều) bạn có thể sử dụng để đạt được điều đó, nhưng rất nhiều phần mềm, một số phần mềm thậm chí còn tốt, đã được xây dựng mà không có gì ngoài kiểm tra thủ công.

Dù bạn xây dựng phần mềm nào, các yêu cầu nằm giữa bạn và khách hàng của bạn và nếu bạn đang xây dựng phần mềm cho tiêu dùng chung, thì hãy chọn một hoặc một vài nhóm mục tiêu và đừng cố gắng trở thành tất cả mọi người. Cố gắng đưa ra một số loại khuôn chung có vẻ như tôi khá ngớ ngẩn.

Thay vào đó, để cố gắng dự đoán hoặc đoán khi nào phần mềm của bạn sẽ sẵn sàng sản xuất, tại sao bạn không làm việc với khách hàng của mình? Cung cấp cho họ một bản xem trước nhưng giải thích rằng nó không sẵn sàng sản xuất. Xuất bản nó trên máy chủ của riêng bạn và yêu cầu họ sử dụng nó, chọc ngoáy và cung cấp cho bạn thông tin phản hồi. Tiếp tục làm việc với họ cho đến khi họ hài lòng với những gì bạn đã cho họ. Nói cách khác, họ sẽ cho bạn biết khi nào nó sẵn sàng sản xuất.

— DXM
nguồn

Mã chất lượng sản xuất là mã đáp ứng yêu cầu của khách hàng, và đó là nó.

— Robert Harvey

@RobertHarvey: danh sách 3 điểm đó là một nỗ lực để đưa ra một phiên bản "thỏa mãn yêu cầu của khách hàng" hơn một chút, rõ ràng đó không phải là một nỗ lực rất thành công, nhưng vâng ... đó là khá nhiều

— DXM

@DXM Tôi thích ý tưởng xác định "sẵn sàng sản xuất" với khách hàng. Tôi đoán sai lầm của tôi đã không làm như vậy là một phần của các yêu cầu. Điều gì về các yếu tố không thể được demo mặc dù (ví dụ phục hồi từ thất bại)?

— Verybadalloc

@verybadalloc Tôi muốn nói rằng các định nghĩa này thực sự nên có trong hợp đồng hoặc SoW chứ không phải là yêu cầu, nhưng có, xác định những gì bạn có nghĩa là 'hoàn thành' càng sớm càng tốt

— jk.

@verybadalloc: thật không may là bạn thực sự nên thảo luận như là một phần của hợp đồng. Bây giờ nếu bạn hỏi họ, "bạn có muốn chịu lỗi hoàn toàn không", câu trả lời tất nhiên sẽ là có. Làm toán: P = khả năng sản phẩm của bạn gặp sự cố; L = khi gặp sự cố có khả năng mất dữ liệu như thế nào; C = mất dữ liệu thực tế như thế nào? (tức là chúng ta đang nói toàn bộ DB hoặc 5 phút giao dịch cuối cùng? tạo nên sự khác biệt). P x L x C = giá trị âm trong thiết kế hiện tại của bạn. Điều này có thể bù đắp cho tất cả các tích cực bạn đang cung cấp? Nếu có, bạn phải sửa nó. Nếu bạn nghĩ rằng khách hàng của bạn ...

— DXM