Ưu tiên mã hóa: Hiệu suất, Tính bảo trì, Khả năng sử dụng lại?

Question

Điều này chủ yếu là do câu trả lời cho các câu hỏi SQL. Các truy vấn của UDF và Sub được cố ý bỏ qua vì hiệu suất. Tôi đã không bao gồm độ tin cậy không phải là nó phải được thực hiện cho các cấp, nhưng mã đã làm việc.

Hiệu suất có luôn đến trước không? Vì vậy, nhiều câu trả lời được cung cấp với hiệu suất là ưu tiên chính. Người dùng của tôi dường như quan tâm hơn đến việc sửa đổi mã nhanh như thế nào. Vì vậy, một báo cáo mất 15 giây thay vì 12 để chạy. Họ có thể sống với điều đó miễn là tôi không bào chữa vì không cung cấp giải pháp.

Rõ ràng nếu 15 giây chuyển thành 15 phút, có sự cố nhưng người dùng muốn có chức năng. Họ muốn ứng dụng thích ứng với các thay đổi về quy tắc kinh doanh và các yêu cầu nâng cao. Tôi muốn có thể xem mã 6 tháng kể từ bây giờ và có thể thực hiện thay đổi ở một vị trí được xác định một cách dễ dàng và không truy tìm tất cả những nơi được sao chép và dán mã bởi vì họ nghĩ gọi một hàm hoặc thường trình phụ hoặc Udf khác cản trở hiệu suất.

Tất cả những gì được nói, tôi sẽ đặt hàng: Duy trì (Thay đổi là một thực tế của cuộc sống.), Hiệu suất (Không ai thích nhìn chằm chằm vào đồng hồ cát.), Khả năng sử dụng lại (Khó xác định mã nào nên được sử dụng lại). .

Answer 1

1. Tính bảo trì: Nếu mã không đọc được thì vô dụng, cho dù nó có nhanh đến mức nào. Và nó chắc chắn sẽ không được tái sử dụng.

2. Khả năng sử dụng lại: Không phải tất cả mã đều có thể sử dụng được, nhưng rất nhiều mã được sử dụng. Nếu bạn có thể, bằng mọi cách, hãy làm cho mã của bạn đơn giản hơn. Cách dễ nhất là chia và chinh phục. Ví dụ, tạo các thành phần đơn giản bạn sẽ sử dụng hơn và hơn và hơn. Tiện ích con giao diện người dùng phổ biến nhất. Nhưng nó tương tự với các tiện ích. Đồng thời, việc tạo cấu trúc/khung công tác cho mã của bạn sẽ giúp bạn. Mã xác thực lỗi, v.v.

3. Hiệu suất: Nói chung, hầu hết mã đều có hiệu suất đủ. Và nếu không, hãy sử dụng một trình lược tả mã. Thường xuyên hơn các nút cổ chai sẽ vượt xa bất kỳ tối ưu hóa mã nhỏ bạn có thể đã thực hiện với chi phí của một trong hai khả năng đọc hoặc tái sử dụng.

Answer 2

Sửa 2010/03/02: Các câu hỏi ban đầu:

Mọi người làm việc cho NASA? Hiệu suất có luôn đến trước không? Vì vậy, nhiều câu trả lời ...

Không ai trong chúng ta không làm việc cho NASA.

Không: độ tin cậy và khả năng bảo trì vượt trước hiệu suất. Khả năng sử dụng lại cũng tốt.

Trong giới hạn rộng, hiệu suất không quan trọng.

Answer 3

Câu trả lời của sucker dĩ nhiên là "nó phụ thuộc".

Trong trường hợp ứng dụng dòng doanh nghiệp, thời gian phản hồi cho hoạt động có liên quan cần phải tỷ lệ nghịch với tần suất chạy. Nếu đó là một chức năng mà người dùng cần phải truy cập 4 hoặc 5 lần một giờ thì tốt hơn là nên nhanh hơn kéo báo cáo cuối tháng đó.

Tôi nghĩ, ở một mức độ nào đó, bạn đã trả lời câu hỏi của riêng mình và cung cấp một số lý do khá hợp lệ cho nó. Người duy nhất bạn đã bỏ lỡ là Độ tin cậy - và đây là nơi mà NASA tương tự đến. Nếu bạn đang viết mã cho NASA, hoặc cho một tổ chức tài chính, nó có máu tốt hơn sẽ mạnh mẽ và đáng tin cậy ... và Tôi nghĩ đó sẽ là ưu tiên hàng đầu.

Answer 4

họ nghĩ rằng gọi một chức năng hay thói quen phụ hoặc UDF sẽ cản trở hiệu suất

Đó là suy nghĩ sai lầm.

Tôi sẽ đặt hàng: Tính bảo trì, Hiệu suất, Khả năng sử dụng lại.

Đôi khi (thường là IMO) có thể dùng lại là bảo trì: đó là vì bạn tái sử dụng một cái gì đó mà bạn đang "có thể thực hiện thay đổi trong một chỗ dễ dàng xác định và không đuổi theo tất cả những nơi soneone sao chép và dán mã".

Answer 5

I do làm việc tại NASA. Tuy nhiên, tôi không (hiện tại anyway) duy trì hoặc phát triển mã thời gian thực hoặc bất kỳ điều đó là tất cả những hiệu suất quan trọng. Hầu hết các phần mềm được thực hiện tại NASA có lẽ là không. Sau khi nhìn thấy một số mã khủng khiếp trong ngày của tôi, tôi cũng sẽ đi với câu trả lời của Jonathan về độ tin cậy và bảo trì tiếp theo hiệu suất và sau đó reusability cho hầu hết các ứng dụng.

Answer 6

Tôi là nhà thầu của NASA và phát triển và duy trì phần mềm chủ yếu cho các mục đích quản trị như chạy báo cáo và dự án theo dõi.

Tôi đã làm việc ở đó khoảng 1,5 năm và tôi tin rằng mối quan tâm chính của họ là khả năng bảo trì và bạn có thể triển khai tính năng hoặc mô-đun mới được triển khai nhanh như thế nào.

Giống như Guiness đã nêu trong câu hỏi miễn là phần mềm không mất một lượng thời gian đặc biệt, chúng dường như không bận tâm.

Mối quan tâm chính khác mà chúng dường như có khả năng sử dụng. Ứng dụng phải dễ sử dụng và dễ sử dụng.

Kết luận, Tính bảo trì, Tính khả dụng, sau đó Hiệu suất có vẻ như mối quan tâm chính của NASA đối với các công cụ báo cáo và theo dõi nội bộ.

Answer 7

Bạn phải có khả năng sắp xếp lại các ưu tiên này tùy thuộc vào dự án và điều khó có thể thay đổi hành vi nhanh chóng khi bạn chuyển đổi giữa các dự án hoặc thậm chí các phần mã khác nhau. Tôi làm việc trên ba ứng dụng với các cấu hình rất khác nhau.

1. Một là thời gian thực và rất nhiều công việc đi vào đảm bảo hiệu quả của nó là có thể dự đoán, (không nhất thiết phải sáng nhanh) nhưng thay đổi không phải là một vấn đề lớn, nó chỉ thay đổi đáng kể khi thay đổi IETF/lỗi thời RFC và có rất ít dấu hiệu cho thấy điều đó. (Điều đó nói rằng, tôi khá tự hào về mức độ bảo trì của nó).

   • Một ứng dụng khác có lúc mất 16 giờ để xử lý dữ liệu trong 1 ngày. Không cần phải nói rằng hiệu suất tuyệt đối nhanh chóng trở thành ưu tiên hàng đầu.Nhưng ngay cả trong ứng dụng này, nhấn mạnh về hiệu suất thay đổi đáng kể, từ 'không quan trọng' trong mã theo từng đợt thông qua mã mỗi khách hàng, mã cho mỗi tác vụ, mỗi tệp-mã, mỗi bản ghi-mã, mỗi -field-code thành 'cực kỳ quan trọng' trong mã mỗi byte. Ứng dụng cuối cùng có chứa nhiều logic kinh doanh, hiệu suất không bao giờ là vấn đề, tính bảo trì và sự nhanh nhẹn là chìa khóa và ứng dụng này mang lại lợi ích cao nhất từ ​​tất cả các phương pháp thời trang, tuy nhiên, khi tôi đã bỏ ra hàng tuần hoặc vài tháng cho hiệu suất nó rất khó để viết "string1 + string2 + string3 + string4" ngay cả khi đó là dễ đọc nhất và hiệu suất là không thích hợp.

Answer 8

Performance doesnt't đến trước, thậm chí tại NASA! Tại NASA, nếu mã không chính xác và đáng tin cậy, mọi người sẽ chết.

Hơn nữa, theo kinh nghiệm của tôi, ngay cả khi hiệu suất là có giá trị, nó sẽ đến một điểm; thường có một mức hiệu suất có ít hoặc không có giá trị bổ sung nào vượt trội. Ngược lại, có giá trị bổ sung trong việc cải thiện độ chính xác cho dù một đoạn mã có đáng tin cậy như thế nào; một đoạn mã không thể hoạt động như mong đợi quá thường xuyên.

Đối với tôi thứ tự sẽ là:

• Bảo trì: nếu nó không phải dễ dàng để thay đổi, nó sẽ không ở lại đúng trong thời gian dài, ngay cả khi nó là đúng bây giờ.
• Khả năng tái sử dụng: sử dụng lại cải thiện năng suất và ít mã thường đáng tin cậy hơn nhiều mã hơn.
• Hiệu suất: đôi khi các vấn đề về hiệu suất, nhưng bạn sẽ ngạc nhiên khi có bao nhiêu mã không phải là hiệu suất quan trọng, ngay cả trong một ứng dụng quan trọng về hiệu suất. Vấn đề tối ưu hóa hiệu suất chỉ dành cho các nút cổ chai.

Answer 9

Một trong những câu yêu thích của tôi là từ SICP ...

"Chương trình máy tính được thiết kế để được đọc bởi người và Ngẫu nhiên chạy bằng máy tính."

Tôi xếp hạng tất cả các khía cạnh này trong công việc của tôi; nhưng khả năng đọc (một số sử dụng thuật ngữ biểu cảm) của mã của tôi và những người tôi làm việc với các đỉnh của danh sách tầm quan trọng của tôi.

Chỉ 2c của tôi, có một ngày cuối tuần đáng yêu!

Answer 10

Tôi nghĩ bạn đã bỏ lỡ một từ danh sách: độ tin cậy;

nên đơn hàng của tôi là

• đáng tin cậy và chính xác
• Bảo trì
• Có thể dùng lại
• Performance

Nó không quan trọng nhanh như thế nào đang khi nó không phải là đúng , trước tiên mã phải đáng tin cậy.

Hiệu suất ở cuối danh sách. Không bao giờ tối ưu hóa quá sớm và chỉ cải thiện hiệu suất khi hiệu suất là một vấn đề.

Tôi đã làm việc trên các hệ thống thời gian thực bao gồm mô phỏng chuyến bay và thậm chí trong hiệu suất môi trường đó được xem xét nhưng không phải là mối quan tâm chính quan trọng .

Tôi sẽ nói rằng theo kinh nghiệm của mình, tôi chỉ phải tối ưu hóa ít hơn 1% mã mà tôi đã viết.

---

đôi khi một cái gì đó là không đủ nhanh, và dĩ nhiên là hiệu suất được đưa vào xem xét khi thiết kế và mã hóa, nó chỉ là không ở trên cùng của danh sách.

Answer 11

Trong câu trả lời riêng biệt, Hiệu suất sẽ hầu như luôn luôn đến trước.

Chúng tôi không biết bạn sẽ nhấn đoạn mã này hàng triệu lần liên tiếp, vì vậy hiệu suất là mối quan ngại theo mặc định. Chúng tôi không biết liệu đoạn mã quý giá của chúng tôi có trở thành nút cổ chai trong đơn đăng ký của bạn hay không, vì chúng tôi không biết nó tương tác như thế nào. (Điều tương tự cũng xảy ra khi viết mã thư viện: Tôi không biết làm thế nào này đang được sử dụng Một lý do IMO tái sử dụng mã không đơn giản là "chuyển mã tương tự như một thực thể được chia sẻ"..)

Bảo trì thậm chí còn bị ảnh hưởng nhiều hơn bởi cách mã tương tác với mã không xác định đối với chúng tôi. Câu trả lời sẽ giải quyết vấn đề trong phạm vi bạn đã đặt: Bạn có thể yêu cầu hoặc gắn thẻ là SQL hoặc SQL Server hoặc MySQL. Phần còn lại, chúng tôi không biết: Bạn có bao nhiêu đường dẫn mã tương tự? Tần suất đoạn mã này sẽ thay đổi trong suốt vòng đời của dự án? Bạn sẽ dính vào phiên bản máy chủ cơ sở dữ liệu cụ thể đó trong mười năm, hay bạn sẽ cập nhật thường xuyên?

Giải quyết Khả năng bảo trì phần lớn là công việc của bạn: Câu hỏi bạn đặt ra là một thực thể phải được phân lập?

Dễ đọc hầu hết được thực hiện, phần còn lại là công việc của bạn. Khi trả lời chúng tôi thường quan tâm đến việc bạn hiểu câu trả lời, vì vậy nó cần phải được đọc ít nhất cho bạn. Nếu bạn copypaste đoạn mã đó vào mã của bạn và tát một nhận xét // That weird query vào đó, không phải vấn đề của tôi nữa.

Thêm vào thực tế là hiệu suất dễ hiểu hơn: Từ hai câu trả lời tương đương về chức năng, bạn sẽ luôn chọn câu trả lời "như Joes trả lời, nhưng nhanh hơn một chút", trừ khi nó gây ra những sai lầm lớn trong bộ phận M + R .

---

Viết điều này ngay bây giờ có vẻ như có lý do khiến tối ưu hóa sớm là hấp dẫn. Điều này là ưu tiên sai vì một vài lý do.

Các ưu tiên thấp cho việc tối ưu có hai lý do chính, mặc dù:

Answer 12

đúng đắn là quan trọng hơn bảo trì, tái sử dụng, hoặc hiệu suất. Nếu bạn nhắm vào đúng đắn, bạn có khả năng nhận được ba cái còn lại trong món hời.

• Viết mã không cần thiết.
• Tận dụng thư viện chuẩn.
• Ưu tiên sự minh bạch cho sự thông minh.
• Viết các hàm nhỏ, có thể kiểm tra.

Answer 13

Đây là câu hỏi xen kẽ và câu trả lời khá đủ hấp dẫn. Ưu tiên phụ thuộc vào việc thực hiện. Tôi muốn trình bày một trong những ví dụ mà người dùng sẽ không hy sinh hiệu suất cho tính bảo trì hoặc khả năng sử dụng lại. Có một yếu tố đáng tin cậy - sẽ có bất kỳ lỗi/lỗi nào. Vì vậy, khi chúng tôi so sánh khả năng bảo trì, hiệu suất và khả năng sử dụng lại.

Một trong những khách hàng của chúng tôi có trang web giao dịch trực tuyến. Dưới tải trọng cao điểm, một giao dịch trung bình sẽ mất khoảng 14 ms để hoàn thành ở mức trung gian. Một thời gian sau, hiệu suất của ứng dụng bị suy giảm (do một số lý do) và thời gian giao dịch trung bình tăng lên 24 ms. Bây giờ là một nhà phát triển bình thường, chúng tôi sẽ nghĩ rằng 10 ms không phải là rất đáng báo động quan trọng. Nhưng nếu chúng ta nghĩ từ quan điểm kinh doanh thì nó đáng báo động. Làm sao? chúng ta hãy phân tích:

Giả sử rằng dưới tải trọng cao nhất, tài nguyên được sử dụng đầy đủ và với 14ms chúng tôi có thể thực hiện 100 giao dịch. Bây giờ với sự suy giảm hiệu suất, các giao dịch mất thêm 10ms, thêm 71,42% thời gian. Bây giờ điều này có nghĩa là chúng tôi sẽ chỉ có thể phục vụ 28,58 giao dịch thay vì 100 giao dịch. Điều này có nghĩa là mất mát nghiêm trọng đối với kinh doanh.

Infact có rất nhiều tài liệu về tầm quan trọng của hiệu suất ứng dụng. Có một cuốn sách rất hay "Cách tiếp cận định lượng cho kiến ​​trúc máy tính" giải thích cách các yếu tố về hiệu suất, khả năng bảo trì, độ tin cậy, khả năng sẵn có có thể được định lượng theo thuật ngữ kinh doanh/người dùng.

Tôi sẽ không chỉ định thứ tự tầm quan trọng như nhau là bối cảnh cụ thể.

Answer 14

Dưới đây là kết quả dựa trên Tag Count:

• Performance - 952
• Có thể dùng lại (vài thẻ có liên quan) - 43
• Bảo trì - 14

gì này có nghĩa là: Hiệu suất phải quan trọng? Hiệu suất trở nên khó khăn hơn, do đó, có nhiều câu hỏi hơn. Câu hỏi về hiệu suất cụ thể hơn/phù hợp để hỏi trên trang web này?