Làm thế nào các nhóm dev có thể ngăn chặn hiệu suất chậm trong các ứng dụng tiêu dùng?

Khi trước đây tôi đã hỏi những gì chịu trách nhiệm cho phần mềm chậm, một vài câu trả lời tôi nhận được cho rằng đó là vấn đề xã hội và quản lý:

Đây không phải là vấn đề kỹ thuật, đó là vấn đề về tiếp thị và quản lý .... Thực tế, người quản lý sản phẩm có trách nhiệm viết thông số kỹ thuật cho những gì người dùng phải có. Rất nhiều điều có thể sai: Người quản lý sản phẩm không đặt phản hồi nút trong thông số kỹ thuật ... Những người QA làm một công việc tầm thường để kiểm tra thông số kỹ thuật ... nếu quản lý sản phẩm và nhân viên QA đều ngủ quên tại bánh xe, chúng tôi lập trình viên không thể bù đắp cho điều đó. - Bob Murphy

Mọi người làm việc trên các ứng dụng kích thước tốt. Khi chúng hoạt động, các vấn đề về hiệu suất leo vào, giống như lỗi. Sự khác biệt là - lỗi là "xấu" - họ kêu lên "tìm tôi và sửa tôi". Vấn đề hiệu suất chỉ cần ngồi ở đó và trở nên tồi tệ hơn. Các lập trình viên thường nghĩ "Chà, mã của tôi sẽ không có vấn đề về hiệu năng. Thay vào đó, ban quản lý cần mua cho tôi một máy mới hơn / lớn hơn / nhanh hơn." Thực tế là, nếu các nhà phát triển định kỳ chỉ săn lùng các vấn đề về hiệu năng ( điều này thực sự rất dễ dàng ) thì họ có thể chỉ cần làm sạch chúng. - Mike Dunlavey

Vì vậy, nếu đây là một vấn đề xã hội, tổ chức có thể đưa ra những cơ chế xã hội nào để tránh vận chuyển phần mềm chậm cho khách hàng của mình?

Với các yêu cầu được viết chính xác và đầy đủ, không có sự phân biệt giữa các lỗi và hiệu suất kém . Vì bạn chỉ định hiệu suất là một yêu cầu phi chức năng, hiệu suất kém sẽ trở thành một lỗi giống như bất kỳ lỗi nào khác và sẽ được QA bắt và giải quyết bởi các nhà phát triển trước khi phát hành.

Có một vấn đề xã hội? Tôi không nghĩ vậy. Vấn đề chính là yêu cầu không đầy đủ. Làm việc nhiều năm với tư cách là freelancer, tôi chưa bao giờ thấy một yêu cầu phi chức năng nào nói rằng một nhiệm vụ cụ thể phải thực hiện trung bình tối đa N giây. Nếu người quản lý / khách hàng / các bên liên quan hoặc bất cứ điều gì không bận tâm về tài sản hiệu suất, tại sao tôi, với tư cách là nhà phát triển, sẽ bận tâm về nó, vì những người phải quan tâm đến nó không quan tâm gì cả?

Có một yếu tố khác ảnh hưởng đến hiệu suất kém: thực tế là các nhà phát triển làm việc trên các PC đắt tiền hoạt động tốt . Khi bạn làm việc nhiều năm trên PC lõi tứ với 8 GB RAM, SSD cao cấp, HĐH mới nhất, v.v., thật khó để tưởng tượng ứng dụng của bạn sẽ chạy trên Windows XP trên PC lõi kép như thế nào với 512 Mo RAM và một ổ cứng cũ chứa đầy 90% và không bị phân mảnh trong nhiều năm. Thật không may, ở một số quốc gia, trường hợp cuối cùng là trường hợp chúng ta thấy đối với hầu hết người tiêu dùng ứng dụng. Khoảng cách giữa PC nhà phát triển và PC tiêu dùng càng lớn, nhà phát triển phải chăm sóc hiệu năng cho ứng dụng của mình càng phức tạp.

Vấn đề(?):

• Khách hàng (hoặc người dùng cuối) không phàn nàn về điều đó (đủ)
• Do đó, người quản lý dự án (/ sản phẩm) không coi đó là một yêu cầu
• Do đó, nhà phát triển không có thời gian để sửa nó.

Bạn phải bắt đầu từ đầu, giáo dục khách hàng. Nhưng nếu họ mua iPhone thay vì điện thoại nhanh hơn, kém sáng bóng hơn, các nhà phát triển có quyền dành thời gian cho ngoại hình thay vì hiệu năng. Tổ chức không phải là vấn đề.

Tất nhiên, một số điều có thể giúp đỡ nào. Chờ đợi kiểm tra tự động rất khó chịu, vì vậy nếu bạn có kiểm tra tự động, các nhà phát triển có phản hồi liên tục về các vấn đề về hiệu suất và họ sẽ có nhiều khả năng giải quyết nó hơn (như là một vấn đề kỹ thuật, không phải là một tính năng).

Nhưng bạn không thể làm mọi thứ. Đó là tối ưu hóa hoặc thêm các tính năng và những người chi tiền quyết định.

Nhưng một số tin tốt: Tôi đã nhận thấy rằng các ứng dụng SaaS / Cloud / Buzzword giúp ích rất nhiều ở đây. Khi mọi người chọn giữa một vài ứng dụng web tương tự và thử nghiệm trực tiếp thay vì lần đầu tiên tạo danh sách nhân tạo các tính năng 'bắt buộc', chúng sẽ bị ảnh hưởng nhanh hơn bởi khả năng phản hồi và do đó hiệu suất sẽ được chú ý nhiều hơn.

Đáng buồn thay, tôi thấy vấn đề lớn nhất là bạn không thể làm mọi thứ. Bạn có một ngày giao hàng và bạn biết rằng nó chậm, nhưng bạn CẦN đưa các tính năng X, Y, Z ra thị trường.

Trong tâm trí của bạn, chậm bạn có thể sửa chữa sau đó, nhưng ứng dụng ít nhất hoạt động.

Vì vậy, bạn lo lắng về chức năng và thẩm mỹ (vì người dùng thường tập trung vào tính thẩm mỹ). Bản phát hành tiếp theo bạn sẽ sửa hiệu suất.

Nhưng PM chỉ cung cấp cho bạn một danh sách các Tính năng và không có thời gian để sửa hiệu suất.

Và vòng luẩn quẩn tiếp tục.

Tôi đồng ý với những người khác, rằng chúng ta nên tìm cách khiến các nhà phát triển quan tâm hơn đến vấn đề, như khiến họ thử nghiệm trên phần cứng chậm hơn và có mục tiêu hiệu suất. Điều đó tốt, nhưng thực sự, khi nói đến điều chỉnh hiệu suất -

Mọi người phải biết cách - Và họ không

Họ có thể nghĩ rằng họ làm, nhưng chỉ cần xem qua tất cả các câu hỏi và câu trả lời liên quan đến hiệu suất trên StackOverFlow và trên diễn đàn này. Thật đau đớn khi nhiều người thể hiện rất ít ý nghĩa thông thường về hiệu suất.

Đó không phải là thứ để nói, mọi người cần học bằng cách thực hiện nó. Lần duy nhất họ ở trong chế độ đó là khi họ đang tham gia một lớp học, hoặc học những điều mới từ một cuốn sách hoặc blog.

Vì vậy, cách duy nhất tôi có thể nghĩ ra để giải quyết vấn đề này là nắm bắt những người dạy lập trình và dạy họ cách làm.

Có trời mới biết, tôi đã thử trên các diễn đàn này, như trong -

• Phương pháp siêu đơn giản cơ bản
• Tăng tốc 43x - làm điều đó với trình hồ sơ của bạn
• Những lý do tại sao, trong chi tiết buồn nôn

Bất cứ ai cũng có thể làm điều đó. Họ chỉ cần thực sự làm điều đó.

Làm cho hiệu suất là một yêu cầu.

Viết mã trình diễn là khó. Nó đòi hỏi phải nắm vững các khái niệm như phân luồng, xử lý sự kiện không đồng bộ, bộ đệm và độ phức tạp tiệm cận. Đánh giá bởi các nhóm lập trình viên mà tôi đã làm việc cùng, khoảng 20-40% trong số các nhóm nhất định không hiểu rõ các khái niệm đó đủ để kết hợp các cân nhắc về hiệu suất như một vấn đề tất nhiên vào công việc hàng ngày của họ.

Tuy nhiên, những lập trình viên đó rõ ràng vẫn hữu ích cho công ty, nhưng họ được giao cho các nhiệm vụ không được coi là hiệu suất quan trọng, vì vậy bạn kết thúc với một trình phát blu ray có thể phát các luồng Netflix hoàn hảo mà không làm rơi bất kỳ khung hình nào, nhưng phải mất 30-60 giây để mở mục menu hiển thị hàng đợi của bạn.

Trừ khi bạn là một công ty phần mềm hotshot có thể đủ khả năng sa thải 20% nhân viên của bạn và thay thế họ bằng các nhà phát triển có kinh nghiệm hơn (và đắt tiền hơn), cách duy nhất để khắc phục là đào tạo nhà phát triển và báo cáo lỗi. Tôi không biết nó như thế nào tại các công ty khác, nhưng ở đây nếu các nhà phát triển của chúng tôi thấy vấn đề về hiệu suất mà chúng tôi không có thời gian hoặc ưu tiên kinh doanh để khắc phục, chúng tôi hoàn toàn có quyền nộp báo cáo lỗi của riêng mình về vấn đề đó. Nó có thể mất một vài bản phát hành để đi đến đỉnh của tồn đọng, nhưng cuối cùng chúng thường được giải quyết.

Nếu hiệu suất là một yêu cầu, kiểm tra cho nó.

Nếu không, Wally có thể viết một vòng lặp vô hạn và rời đi sớm "Mất một lúc." Anh ta có thể yêu cầu.

Kiểm tra chấp nhận phần mềm của bạn nên có một kiểm tra chấp nhận chi tiết cho các đặc tính hiệu suất hoạt động khác nhau.

Nếu bạn không làm điều này, bạn sẽ không tạo ra bất kỳ hiệu suất nào cho sản phẩm.

Hiệu suất (như mức tiêu thụ tài nguyên) sẽ được ngân sách cho các hệ thống phụ. Sau đó, các thử nghiệm chấp nhận hệ thống phụ có thể kiểm tra chúng.

Sau đó, bạn có thể kiểm tra sớm và thường xuyên cho hiệu suất. Ngay cả các bài kiểm tra đơn vị sau đó có thể kiểm tra nó.

Vì vậy, bây giờ các nhà phát triển có nó như là một tiêu chí chấp nhận và có thể tổ chức cách tiếp cận của họ cho phù hợp với nó.

Hiện tại tôi đang làm việc, bài kiểm tra căng thẳng hiệu suất lớn hơn gấp đôi so với bất kỳ tập dữ liệu khách hàng nào chúng tôi biết. Nó thường xuyên phá vỡ một phiên bản mới của sản phẩm. Kiểm tra tốt.

Tôi nhớ một lần vào giữa những năm 90 và tôi đã dành một chút thời gian để cố gắng tối ưu hóa một cái gì đó và một đồng nghiệp đã nói với tôi, "Cái này chạy trên pentium, ai quan tâm chứ?" .... đó là một cái mở mắt. Đáng buồn thay, đó chỉ là phần nổi của tảng băng trôi, tôi đã nghe thấy thái độ đó trong suốt sự nghiệp của mình - mặc dù phần "pentium" đã thay đổi theo thời gian.

Cách duy nhất để khiến nhà phát triển trung bình quan tâm là thiếu hiệu năng để được xem là một lỗi của khách hàng. Tùy thuộc vào ứng dụng và đối tượng, đây có thể là một nhiệm vụ dễ hoặc khó (tôi đã thấy cả hai). Nếu khán giả không quan tâm đến hiệu suất kém, các nhà phát triển sẽ không bao giờ (nhanh, tốt, nhanh - chọn hai).

Nhưng không nên lấy thư từ QA để lập trình viên nhận ra rằng độ trễ 3 giây giữa phím bấm và phản hồi là không thể chấp nhận được

Đồng ý là không nên. Cần nhiều hơn thế: một bằng chứng cho thấy độ trễ thu được có liên quan đến người dùng cuối .

Vì bạn không cung cấp ngữ cảnh, có vẻ như độ trễ trong môi trường dev / QA là do các vấn đề cục bộ của việc truy cập đĩa / bộ nhớ / mạng chậm. Nếu đó là trường hợp, QA và nhà phát triển của bạn sẽ chỉ lãng phí nỗ lực của họ để sửa chữa những thứ không quan trọng đối với người dùng cuối.

Dựa vào các nhà phát triển trong thử nghiệm hiệu năng cũng có hiệu quả như việc gieo xúc xắc để chọn một phần chức năng để tăng tốc. Ồ và nó đáng tin cậy như thế - "các nhà phát triển thường có trực giác khủng khiếp về vấn đề hiệu năng trong ứng dụng sẽ thực sự xảy ra ở đâu" ( Brian Goetz ).

• Tôi đã từng tham gia một dự án nơi quản lý khập khiễng quyết định những người tiếp thị thông minh và lập trình viên thông minh của họ đủ tốt để xử lý các mối quan tâm về hiệu suất của khách hàng. Thật là một bài học tuyệt vời Bị từ chối phát hành, nửa năm nỗ lực đổ vào thùng rác và công ty gần như mất đi một đối tác chiến lược. Cuối cùng, họ đã mời các chuyên gia (chuyên gia về điểm chuẩn, thống kê, UX, tối ưu hóa ở mức độ thấp, những thứ tương tự) và các chuyên gia đã sửa chữa mớ hỗn độn đó.

tất cả các lập trình viên có nên làm QA của riêng họ để họ thấy những vấn đề như vậy ngay lập tức không?

Thực tế là nó không thể thực hiện được có nghĩa là đó là cách để đi. Hoàn toàn ngược lại - theo kinh nghiệm của tôi, đây là một trong những cách đáng tin cậy nhất để giảm năng suất của các lập trình viên . Gần như là tốt như cuộc họp bất tận và thậm chí tốt hơn so với phỏng vấn các ứng cử viên.

• Là một người thử nghiệm trước đây, tôi từng nghĩ rằng không nên kết hợp các hoạt động phát triển và QA. Có vẻ như sự khác biệt giữa kiểm tra dev thường xuyên và QA có hệ thống sẽ không còn quan trọng nữa. Tôi nghĩ rằng tách dev / QA chỉ là một truyền thống trong ngành công nghiệp phần mềm. Học theo cách khá khó mà không phải như vậy. Sự tách biệt hóa ra là một vấn đề trọng tâm và năng suất, và khá nghiêm trọng.

Nếu có vấn đề về hiệu suất, chỉ cần cho tôi điểm chuẩn và đặt hiệu suất mục tiêu và tôi sẽ cố gắng hết sức để đạt được nó. Tôi không giỏi kiểm tra hiệu năng nhưng biết một chút hoặc hai về tối ưu hóa.

Tôi nghĩ rằng bạn sẽ thấy rằng 99% vấn đề là phạm vi creep. Với các dv chẳng hạn. Bạn sẽ nghĩ rằng điều này là dễ dàng nhưng sau đó TIVO hoặc một đối thủ cạnh tranh giới thiệu một tính năng mới được đón nhận. Điều tiếp theo bạn biết một tính năng mới là trên đĩa. Nó có thể hoặc không thể tương thích với sản phẩm hiện tại và chúng tôi sẽ không làm lại sản phẩm hiện tại sẽ mất nhiều thời gian. Vì vậy, tính năng bị kẹt trong và nó hút hiệu suất. Chắc chắn dữ liệu ở đó để có được thông tin nhưng nếu không nghĩ sẽ có được thông tin đó thì rất có thể nó sẽ không dễ dàng có được. Vì vậy, bây giờ nó có một quy trình phức tạp để xây dựng thông tin đó mỗi khi bạn đến gần danh sách chương trình.

Bỏ qua các nhà phát triển dường như không quan tâm ...

Tôi nghĩ rằng thường thì các nhà phát triển làm việc trên mã không có các công cụ để đo lường hiệu suất một cách liên tục.

vd thực hiện (hoặc vượt quá ngưỡng xác định)?

Trong nhiều trường hợp - nhiều nhà phát triển không nhận được thông tin này từ các triển khai "thế giới thực" và kết quả là rất dễ bỏ qua thông tin mà bạn không thấy.

Tuy nhiên, nếu mỗi ngày / vài giờ bạn nhận được một email chỉ ra rằng màn hình "x" mất 13 giây để tải và nó đang chạy truy vấn SQL sau, SELECT TOP 1.... JOIN... OUTER JOIN... OUTER JOIN... CROSS JOIN...bạn tin rằng nhà phát triển có thể (và hy vọng rằng) sẽ khắc phục được tất cả nó

Do đó, mặc dù tôi muốn tin rằng tất cả các lập trình viên đều thực hiện nghiêm túc hiệu suất, tôi nghĩ rằng việc thiếu tầm nhìn đối với (các) vấn đề thường là thủ phạm.

Lưu ý: Tôi nghĩ rằng đây là điều mà cả nhà phát triển nên yêu cầu quyền truy cập (hoặc thậm chí phát triển tính năng như vậy) và ban quản lý nên cung cấp / cấp vốn cho các công cụ đó.

Bạn có thể đưa ra những ví dụ tốt hơn để chúng ta thực sự có thể đổ lỗi cho các lập trình viên không? Ngoài Eclipse và một nhà bình luận đã chỉ ra rằng đó là các plugin làm điều đó (bản cài đặt đầu tiên của tôi cho mỗi phiên bản Eclipse mới chạy như làm sáng, nhưng khi tôi thêm các công cụ khác thì nó bắt đầu chậm lại), các ví dụ của bạn có thể không phải là lập trình viên và mã liên quan nhưng môi trường liên quan.

Những ngày chạy một chương trình trên máy tính một cách cô lập và xác định xem nó là 'nhanh' hay 'chậm'. Các ví dụ khác mà bạn đưa ra phụ thuộc vào môi trường của họ - tắc nghẽn mạng hiện tại, cho dù các máy chủ đầu cuối bị quá tải, card mạng được cấu hình kém, cáp bị lỗi, số lượng người khác sử dụng nó trong vùng lân cận của bạn hoặc hàng trăm biến khác. ví dụ. nhà cung cấp dịch vụ lưu trữ của chúng tôi đã tính phí thêm cho các kết nối gigabit của máy chủ nhưng cuối cùng chúng tôi đã xác định tất cả đã đi qua một thiết bị tường lửa cổ xưa với các cổng 10Mb. Những vấn đề này thay đổi xung quanh và rất khó tìm.

Đồng ý, có rất nhiều điều mà các lập trình viên có thể làm (giảm thiểu băng thông, các thủ thuật UI cải thiện khả năng phản hồi và hiển thị tiến trình để tạo ấn tượng nhanh chóng). Nhưng khi bạn bước ra thế giới thực, có tất cả các loại tình huống mà bạn chỉ học hỏi bằng kinh nghiệm (và bạn xem các giả định của mình sụp đổ trước mặt bạn).

Bạn sẵn sàng trả bao nhiêu cho phần mềm tốt hơn? Bao nhiêu thị trường sẽ chờ đợi phần mềm tốt hơn? Làm thế nào ít cruft sẽ muốn thêm vào bản phát hành tiếp theo?

Đó là một thị trường cắt cổ ngoài kia, nơi có nhiều thỏa hiệp được thực hiện. Nếu nó thực sự tào lao thì thị trường sẽ (hoặc nên) thất bại sản phẩm. Có lẽ có đủ khách hàng có thể sống với hiện trạng?

Tôi nghĩ rằng câu trả lời chung nhất cho vấn đề này cũng khó quản lý nhất, đó là mọi lập trình viên nên chú ý đến hiệu suất với bất cứ điều gì họ làm. Tôi cũng nhận ra rằng đó là một chút của một cảnh sát.

Tùy thuộc vào quy mô của dự án và nhóm tương ứng, tôi tin rằng có thể có nhiều giá trị trong việc có các lập trình viên hiệu suất chuyên dụng.

Ví dụ, tôi đã làm việc trong một nhóm trong đó nhóm dự án (bao gồm khoảng 30 nhà phát triển) có ít nhất 2 người dành riêng cho tối ưu hóa hiệu suất. Ứng dụng đặc biệt này cũng khá dễ gặp phải các vấn đề về hiệu năng vì có vô số thành phần tương tác, không chỉ trên các dịch vụ web mà còn về các lớp kế thừa với các thành phần ánh xạ dữ liệu và bộ điều hợp khác nhau.

Kinh nghiệm đầu tay là quan trọng. Cung cấp cho các nhà phát triển một máy tính nhanh để biên dịch và xây dựng, nhưng một máy tính quá tải thực sự chậm (vì một số phần trăm người dùng thực sự có thể có) để chạy (các) ứng dụng của họ. (Điều này có thể được thực hiện trong môi trường phát triển dựa trên đám mây / máy chủ bằng cách phân vùng máy ảo hoặc máy chủ theo chức năng.) Cung cấp cho họ điện thoại di động với một nửa pin chết và yêu cầu họ chỉ sử dụng nó cho những ngày thử nghiệm ứng dụng di động ban đầu.

Nếu các nhà phát triển đồng cảm với khách hàng về hiệu suất và thời lượng pin, thì họ sẽ không coi hiệu suất là một số thông số quản lý bán giả để đặt ở cuối danh sách ưu tiên. (Như trong: "này, tôi nghĩ rằng đó là tối ưu hóa sớm" cho đến khi quá muộn.)

Ngừng mua những thứ đó, và, nhận xét về hiệu suất kém trên bất kỳ đánh giá trực tuyến nào bạn gặp.

Nếu các thiết bị vẫn bán thì phần mềm "đủ tốt" để không đầu tư thêm thời gian và tiền bạc. Nếu đánh giá xấu về hiệu suất làm giảm đáng kể doanh số thì phần mềm "không đủ tốt" và cần sửa chữa.

Các số liệu duy nhất quan tâm đến một nhà sản xuất hàng tiêu dùng là doanh số và lợi nhuận trên mỗi đơn vị.

Tôi đồng ý rằng các lập trình viên nên được dạy tốt hơn về tối đa hóa hiệu suất, v.v.

Nhưng tôi nghĩ giải pháp này không mang lại cho các lập trình viên một phần cứng sắp chết để sử dụng hàng ngày. Sẽ căng thẳng đến mức nào nếu phòng thu hình ảnh của bạn gặp sự cố hai lần một ngày, phải mất x giây để xây dựng công cụ, y giây để mở giải pháp, z giây để thay đổi cửa sổ. Tôi không nghĩ rằng nó rất hiệu quả cho công ty vì phần cứng là rẻ và thời gian lập trình viên là đắt.

Vì tay tiếp theo sẽ xử lý mã là nhóm QA (thử nghiệm), sẽ tốt hơn nếu dạy họ về tầm quan trọng của hiệu suất, có một tiêu chuẩn về tiêu chuẩn hiệu suất chấp nhận được, v.v. như một tiêu chuẩn doanh nghiệp (tốt, trong thế giới hoàn hảo , tiêu chuẩn hiệu suất nên có trong spec nhưng điều đó không xảy ra rất thường xuyên)? (tức là trang / tab thay đổi ee doanh nghiệp thông thường sẽ xảy ra ngay lập tức, "lưu cập nhật sẽ xảy ra trong x giây", nếu đó là một ứng dụng quan trọng thì ...). Máy tính mà các nhóm QA chạy phải là máy tính người dùng thông thường. (chúng tôi không muốn làm phiền họ bằng cách cho họ một chiếc 386, nhưng không cung cấp cho họ lõi tứ với 8GB ram chẳng hạn). Họ sẽ không trút giận lên các lập trình viên nếu họ bực mình đủ với màn trình diễn chứ?

Tôi nghĩ rằng khách hàng / người quản lý dự án nên buộc lập trình viên / nhóm qa / nhà phát triển / đại diện của nhóm công ty thực hiện phần trình bày của họ trên phần cứng điển hình thấp nhất mà họ có. (máy tính yếu nhất trong công ty chẳng hạn). Nếu nó được viết lại, họ sẽ cần thu thập dữ liệu về tốc độ xử lý x của phần mềm cũ và so sánh với tốc độ của nó trên phần mềm mới (có thể chậm hơn, vì phần mềm mới có thể liên quan đến quá trình kinh doanh thêm nhưng nên có một cửa sổ chấp nhận được).

Tôi đã nói điều đó trước đây, nhưng tôi sẽ nói lại lần nữa: Tôi nghĩ một trong những cách tốt nhất để xử lý việc này là chỉ đơn giản là để các nhà phát triển của bạn làm việc trên phần cứng (tương đối).

Đối với lập trình viên điển hình của bạn, hầu hết các cân nhắc về hiệu suất chính thức chỉ là thứ yếu: "có khó chịu khi tôi cố chạy nó không?" Nếu họ thấy phiền phức, họ sẽ (ít nhất là cố gắng) sửa nó. Nếu họ hài lòng với cách nó chạy, điều tốt nhất bạn sẽ nhận được là một nỗ lực nửa vời trong việc sửa chữa. Điều này cũng giúp tìm ra vấn đề sớm, trước khi chúng trở nên đắt hơn nhiều để khắc phục.

Nếu đến lúc QA phải thực thi các quy tắc thì các nhà phát triển thực sự không tin vì họ cho rằng hiệu suất là đủ, rất có thể là hầu hết các "cách khắc phục" bạn nhận được sẽ có những cách sáng tạo để vượt qua các quy tắc, không phải là bản sửa lỗi thực sự cải thiện cuộc sống cho người dùng cuối.

Đồng thời, tôi nên nói thêm rằng tôi hiếm khi thấy đây là một vấn đề. Nếu bất cứ điều gì, tôi đã thấy các nhà phát triển dành quá nhiều thời gian để cố gắng cải thiện hiệu suất mà tôi thực sự không đủ quan tâm để làm phiền (một tội lỗi mà tôi cũng thường xuyên phạm tội).