2010-06-18 27 views
12

Nhiều máy tính mà chúng tôi có trong nhóm phát triển đã lỗi thời và chạy rất chậm với Visual Studio 2008. Chúng nên được thay thế bằng các máy mới hơn. Nhưng có một sự miễn cưỡng chung về quản lý/công ty để mua máy mới.Làm thế nào để đo lường mất năng suất từ ​​các máy tính chạy chậm chạy Visual Studio?

Làm thế nào để chúng tôi đưa ra các con số và điểm chuẩn để cho thấy rằng các PC chậm này đang gây ra mất năng suất?

Rõ ràng chúng tôi không thể gọi cho họ để ngồi xuống với chúng tôi khi chúng tôi xây dựng các giải pháp và/hoặc mở các tệp khác nhau.

Có cách nào khách quan để tìm ra một số con số đáng tin cậy mà những người không phải kỹ thuật có thể hiểu được?

Thật tuyệt khi có cách đo lường điều này trên toàn bộ tổ chức trên nhiều PC khác nhau chạy Visual Studio. Tôi đang tìm một câu trả lời tốt hơn là sử dụng đồng hồ bấm giờ. :)

Trả lời

17

Sửa đổi các giải pháp của bạn để các sự kiện dựng sẵn và sau xây dựng ghi thời gian hiện tại vào cơ sở dữ liệu tập trung. Bao gồm tên máy và tên của dự án.

Sau đó, bạn có thể hiển thị thông tin này làm biểu đồ hiển thị thời gian cho máy xây dựng và máy.

Điều này sẽ hiển thị mối tương quan giữa thời gian xây dựng và độ tuổi của máy, hy vọng hiển thị các máy cũ hơn sẽ chậm hơn. Bạn thậm chí có thể chuyển đổi thời gian thành giá trị $ (hoặc £ hoặc €) để hiển thị số lượng các máy cũ này đang tốn kém bao nhiêu. Tổng hợp điều này theo thời gian sẽ đưa ra một giá trị cho hoàn vốn đầu tư vào các máy mới.

Bằng cách sửa đổi các giải pháp, bạn có thể nhận nhật ký này được triển khai trên tất cả các máy phát triển bằng cách đơn giản khiến mọi người thực hiện "mới nhất" từ điều khiển nguồn.

+1

+1 Tôi thực sự thích câu trả lời này. Một số máy mới hơn, nhiều máy cũ hơn nhiều, nhưng với điều này tôi có thể nắm bắt tất cả chúng và so sánh cũ so với mới. – spong

+3

Trừ khi xây dựng của bạn là rất lớn, chi phí của một máy chậm là nhiều hơn trong tập trung bị mất trong các nhiệm vụ bình thường. Bất kỳ nhiệm vụ chặn máy nào chiếm hơn 300ms là đáng chú ý (và gây phiền nhiễu), và trên 10 giây gây rối. Cái chết-by-nghìn-cắt giảm này có tác động đến hiệu suất tồi tệ hơn nhiều so với một vài phút thêm mỗi tuần trong thời gian xây dựng. – dbkk

0

Nhiều tính năng của PHB hiểu về dòng mã (IMO rất sai).

Bạn có thể ghi lại số lượng mã được tạo ra mỗi ngày trên máy chậm và máy không chạy chậm không?

+6

Có ai vẫn sử dụng các dòng mã làm thước đo năng suất không ?! Nếu điều này vẫn đang diễn ra trong tổ chức của bạn, bạn có thể có vấn đề lớn hơn nhiều so với máy chậm. – AndreiM

+0

Tôi chắc chắn có rất nhiều loại quản lý thực hiện, đặc biệt là khi mã hóa được thực hiện trong phòng CNTT của một công ty không phải là công ty CNTT. – Pete

+0

nếu không LOC, #of lỗi đã được sửa. Nhiều nơi sử dụng số liệu _some_, bất kể giá trị –

0

Máy chậm là lệnh cấm phát triển, IMHO, đặc biệt là vì bất kỳ sự chậm trễ nào khiến các nhà phát triển không tập trung và có thể dẫn đến chuyển đổi tốn kém nhiều hơn cho những thứ như trình duyệt web. Có thể có các hiệu ứng lạ khác như tăng độ trễ của cửa sổ bật lên Javadoc hoặc C# tương đương) khi xuất hiện khi bạn di chuột lên phương thức và cơ hội ai đó sẽ tham khảo tài liệu.

Nếu hợp pháp trong công ty của bạn (ít nhất là để tự sử dụng), hãy ghi lại khoảng nửa giờ làm việc với công cụ chụp ảnh màn hình như Camtasia. Sau đó, sử dụng trình chỉnh sửa nhanh để phát hiện thời gian máy bị treo (dễ dàng nếu bạn có thay đổi con trỏ, thanh tiến trình, v.v.) và đếm thời gian và số lượng phiên bản. Tôi đã làm điều đó trong hàng giờ băng - không mất nhiều thời gian. Sử dụng những con số này để tranh luận về vụ án, mặc dù bạn cũng cần phải tranh luận rằng nó dẫn đến các chi phí gián tiếp như một công tắc ngữ cảnh. Ngoài ra, theo kinh nghiệm của tôi, ổ đĩa cứng thường là nguyên nhân chính làm chậm lại, không phải CPU hoặc RAM, và tiếc là hầu hết các tổ chức đều chạy trên ổ đĩa cứng hoặc SSD và có những quy tắc rất nghiêm ngặt về việc thay thế chúng.

3

Tôi sẽ cố gắng giải thích cho họ rằng các lập trình viên tốn chi phí nhiều hơn nhiều hơn máy. Nếu bạn dành 30 phút một ngày chờ đợi, hãy làm toán và tính ra phần trăm tiền lương của bạn bị lãng phí do máy bị lag.Trình bày những con số này cho họ, và so sánh nó với giá của một máy tính mới, và giải thích làm thế nào họ có thể tiết kiệm tiền trong thời gian dài bằng cách nâng cấp.

Nếu họ chọn tiếp tục chi tiêu số tiền lớn, bạn chỉ cần ngồi đó và xem một con trỏ quay, chỉ cười vì trò đùa trên chúng.

+4

Không, trò đùa là về bạn nếu bạn phải làm việc muộn để bù đắp cho nó. Nếu bạn được trả lương, họ sẽ trả cho bạn một cách tương tự. –

+0

@Mark Điểm tốt. Tôi để lại cùng một lúc mỗi ngày, vì vậy thật dễ dàng để tôi bỏ qua cảnh báo đó! –

0

Đừng quên tính đến chi phí trong thời gian tìm ra số lượng máy tính chậm mà bạn phải trả (bài viết này nói cách khác)!

4

Điều này không thực sự trả lời câu hỏi của bạn, nhưng có thể giúp đạt được kết quả cần thiết. Hãy nói với các ông chủ của bạn rằng The Programmer's Bill of Rights là điều cần được xem xét nghiêm túc.

+1

+1 Rất đẹp, đã lâu rồi tôi mới đọc bài đăng của Jeff Atwood về điều đó. Đáng buồn thay, những người phi kĩ thuật sẽ không hiểu điều đó. – spong

Các vấn đề liên quan