it-swarm-vi.com

Có phải việc cung cấp cho nhà phát triển một máy phát triển chậm hơn dẫn đến mã nhanh hơn / hiệu quả hơn?

Giả sử tôi cung cấp cho các nhà phát triển của tôi một cỗ máy nhanh đang la hét. VS2010 dựa trên WPF tải rất nhanh. Sau đó, nhà phát triển tạo ra một ứng dụng WPF hoặc WPF/e chạy tốt trên hộp của mình, nhưng chậm hơn nhiều trong thế giới thực.

Câu hỏi này có hai phần ...

1) Nếu tôi cung cấp cho nhà phát triển một máy chậm hơn, điều đó có nghĩa là mã kết quả có thể nhanh hơn hoặc hiệu quả hơn?

2) Tôi có thể làm gì để cung cấp cho các nhà phát triển của mình trải nghiệm nhanh IDE, trong khi đưa ra trải nghiệm thời gian chạy 'điển hình'?

Cập nhật :

Đối với hồ sơ, tôi đang chuẩn bị phản hồi bằng tay với quản lý. Đây không phải là ý tưởng của tôi và các bạn đang giúp tôi sửa các yêu cầu sai lầm của khách hàng. Cảm ơn đã cho tôi thêm đạn dược, và tài liệu tham khảo về nơi và thời điểm tiếp cận này. Tôi đã + 1'ed các trường hợp sử dụng hợp lệ, chẳng hạn như:
[.__.] - tối ưu hóa lập trình phía máy chủ cụ thể
[.__.] - phòng thử nghiệm
[.__.] - có thể mua một máy chủ tốt hơn thay vì các card đồ họa hàng đầu

130
goodguys_activate

Hoàn toàn

Cũng đúng là các nhà quản lý nên tiến hành tất cả các cuộc họp bằng tiếng Pig-Latin. Nó cải thiện kỹ năng giao tiếp của họ nói chung để làm cho họ thiệt thòi khi nói những câu đơn giản. Họ sẽ phải phụ thuộc nhiều hơn vào biểu cảm khuôn mặt và ngôn ngữ cơ thể để hiểu ý của họ và tất cả chúng ta đều biết rằng ít nhất 70% trong tất cả các cách giao tiếp.

CFO chỉ nên sử dụng bàn tính và phấn. Mặt khác, cuối cùng họ phụ thuộc quá nhiều vào 'dữ liệu thô' và không đủ cho 'cảm giác ruột' của họ.

Và các Phó Chủ tịch và cao hơn nên được yêu cầu tổ chức tất cả các cuộc họp kinh doanh quan trọng trong các môi trường gây mất tập trung như các sân golf trong khi bán say. Ôi chao ...

234
Jay Beavers

Câu trả lời là (Tôi sẽ in đậm và nói) luôn luôn

KHÔNG .

Phát triển tốt nhất bạn có thể có với ngân sách của mình và thử nghiệm trên phạm vi thiết bị tối thiểu tối đa bạn sẽ triển khai.

Có các trình giả lập, máy ảo, máy thực tế với các trình kiểm tra có thể kiểm tra tất cả hiệu năng để xem đó có phải là một yếu tố không.

376
Steven Evers

1) Rất, rất khó xảy ra.Không, và các nhà phát triển của bạn có thể đặt một cái gì đó khó chịu vào cà phê của bạn để đề xuất nó. Thời gian các nhà phát triển của bạn dành thời gian chờ mã biên dịch hoặc cho IDE để làm bất cứ điều gì đang làm hoặc bất cứ lúc nào họ đang làm không phải chi tiêu làm cho mã tốt hơn. Làm gián đoạn dòng chảy tinh thần của họ, quá. Giữ tâm trí của họ về vấn đề, và họ sẽ giải quyết vấn đề đó hiệu quả hơn nhiều.

2) Cung cấp cho họ mỗi PC thứ hai đại diện cho thông số kỹ thuật thấp nhất mà bạn muốn họ thực sự hỗ trợ, với công tắc KVM để đi giữa máy trạm đó và máy trạm thực của họ.

70
BlairHippo

Tôi thích thời gian biên dịch dài. Nó cho tôi thêm thời gian để làm việc trên sơ yếu lý lịch của tôi.

43
Wonko the Sane

Đây là một ý tưởng khủng khiếp. Bạn muốn các nhà phát triển của mình làm việc hiệu quả nhất có thể, điều đó có nghĩa là cung cấp cho họ máy càng nhanh càng tốt, vì vậy họ không ngồi cả ngày để chờ đợi mọi thứ được biên dịch. . với thông số kỹ thuật tương tự, và hãy chắc chắn kiểm tra sớm và thường xuyên để đảm bảo rằng bạn không đi sai đường về các lựa chọn công nghệ.

33
o. nate

Phát triển nên được thực hiện trong môi trường tốt nhất là khả thi. Kiểm tra nên được thực hiện trong môi trường tồi tệ nhất là khả thi.

32
Yevgeniy Brikman

Nếu tôi được tặng một máy chậm, tôi sẽ dành cả ngày để tối ưu hóa quá trình phát triển và không tối ưu hóa mã được giao. Vì vậy: KHÔNG!

27
user6015

Các lập trình viên hệ thống nhúng luôn luôn chạy vào đây! Và có một giải pháp gồm hai phần:

  1. Yêu cầu của bạn cần chỉ định hiệu suất X trên phần cứng Y.
  2. Kiểm tra phần cứng Y và khi bạn không nhận được hiệu suất X, lỗi tệp.

Sau đó, sẽ không có vấn đề gì về phần cứng mà các nhà phát triển của bạn làm việc trên.

Khi bạn đã hoàn thành việc đó, giả sử thiết bị nhanh hơn có thể giúp các lập trình viên của bạn tiết kiệm được nửa giờ mỗi ngày hoặc 125 giờ trong một năm. Và giả sử họ chi phí 100.000 đô la một năm với các lợi ích và chi phí (thấp đến mức nực cười cho Thung lũng Silicon), hoặc 50 đô la một giờ. Đó là 125 giờ * $ 50/giờ là $ 6250. Vì vậy, nếu bạn chi bất cứ thứ gì dưới $ 6250 một năm cho phần cứng phát triển của rockin cho mỗi lập trình viên, bạn đang tiết kiệm tiền.

Đó là những gì bạn nên nói với quản lý của bạn.

Tim Williscroft đã nói khá nhiều về nửa đầu của điều này trong một bình luận, và trong một thế giới công bằng, anh ta sẽ nhận được một nửa số điểm mà câu trả lời này nhận được.


Đã thêm ngày 24 tháng 10:

Chủ cũ của tôi có lý thuyết đó, và nó đã giúp họ kiếm được khoảng 100 triệu đô la.

Họ là một tập đoàn có trụ sở tại Nhật Bản, được sử dụng để thuê các lập trình viên ở Nhật Bản, Hàn Quốc và Trung Quốc. Mọi người ở đó rất tuyệt với việc sử dụng phần cứng phát triển tào lao, 13 ngày làm việc, ngủ tại bàn làm việc và không có một cuộc sống. Vì vậy, họ đã tìm ra khi họ mua một công ty nổi tiếng ở Thung lũng Silicon để làm một hệ điều hành điện thoại di động dựa trên Linux, những người California ngớ ngẩn muốn có thiết bị hiện đại chỉ là prima-donnas và thực sự không có lý do chính đáng cho nó (như năng suất).

Bốn năm sau, HĐH hoạt động như tào lao, tất cả các lịch trình đều bị thổi bay, và khách hàng đã tức giận và chấm dứt hợp đồng phải và trái. Cuối cùng, dự án HĐH đã bị hủy bỏ, và một tỷ lệ lớn lực lượng lao động toàn cầu của tập đoàn đã bị sa thải trong năm ngoái. Và thành thật mà nói, tôi không muốn trở thành một trong những giám đốc điều hành phải giải thích với các cổ đông nơi tất cả số tiền và công sức đó đã đi.

Nó không chỉ là những cỗ máy phát triển chậm gây ra thất bại này. Có rất nhiều sai lầm chiến lược và chiến thuật khác - nhưng chúng cũng là một thứ mà những người làm việc trong chiến hào có thể nhìn thấy xác tàu hỏa đến, và tự hỏi tại sao những người ra quyết định không thể.

Và thiết bị chậm chắc chắn là một yếu tố. Rốt cuộc, nếu bạn ở dưới súng để giao hàng đúng giờ, đó có thực sự là một điều thông minh khi cố tình làm chậm công việc không?

26
Bob Murphy

Trong lập trình, có một câu nói cũ rằng " tối ưu hóa sớm là gốc rễ của mọi tội lỗi ". Tôi nghĩ rằng bạn đã quản lý để tạo thành công một "gốc" (hoặc ít nhất là nhánh đầu tiên) của tất cả các tội ác. Từ bây giờ, chúng ta có thể nói "sự phát triển sớm của nhà phát triển sớm là gốc rễ của mọi tội lỗi".

Nói tóm lại, câu trả lời là điều này sẽ chỉ làm chậm thời gian phát triển của bạn và khiến việc bảo trì thêm khó khăn hơn. Thời gian biên dịch sẽ mất nhiều thời gian hơn, việc tìm kiếm mã trên đĩa sẽ chậm hơn, việc tìm câu trả lời trực tuyến sẽ mất nhiều thời gian hơn và quan trọng nhất là các nhà phát triển sẽ bắt đầu sử dụng tối ưu hóa mã của mình để thậm chí có thể kiểm tra chức năng cần thiết.

Điểm cuối cùng đó là vấn đề quan trọng nhất và không được đưa ra trong nhiều câu trả lời khác. Bạn có thể có phiên bản đầu tiên của mình ổn, nhưng sau đó khi bạn muốn cập nhật mã trong tương lai, bạn sẽ thấy rằng việc tối ưu hóa sớm của nhà phát triển đã lấy trọng tâm của mã của bạn khỏi thiết kế tốt và đẩy nó gần hơn để "làm điều này tại làm việc ít nhất để giữ công việc của tôi "kiểu mã. Việc thêm các tính năng bổ sung sẽ trở nên khó khăn hơn vì các tối ưu hóa được chọn tại thời điểm đó có thể không cần thiết và khóa mã của bạn vào một đường dẫn của các bản hack được tối ưu hóa bán trên các bản hack được tối ưu hóa khác.

Ví dụ về điều này, hãy tưởng tượng rằng yêu cầu hệ thống tối thiểu của phiên bản hiện tại của bạn là một bộ xử lý duy nhất có tốc độ hơi chậm. Bạn đặt các nhà phát triển vào hộp này và họ đưa ra một giải pháp luồng đơn phức tạp dựa trên rất nhiều hack vì họ muốn phát triển sản phẩm nhanh chóng. Bây giờ 5 năm sau, bạn có một phiên bản mới của sản phẩm có yêu cầu tối thiểu là máy xử lý kép. Bạn muốn có thể tách biệt một cách sạch sẽ các phần của chương trình mà bạn có thể chạy song song nhưng quyết định bạn đưa ra 5 năm trước đã buộc các nhà phát triển của bạn tạo ra một phần mềm hack bây giờ ngăn bạn sử dụng toàn bộ yêu cầu tối thiểu mới của bạn .

Những gì bạn nên làm là thêm một giai đoạn vào cuối chu kỳ phát triển của bạn, nơi bạn thực hiện kiểm tra chấp nhận trên các hộp ràng buộc thấp hơn. Chắc chắn một số mã sẽ quá chậm vì máy phát triển nhanh hơn nhưng bạn có thể tách phần đó và tối ưu hóa nó ở đó. Phần còn lại của mã của bạn vẫn sạch sẽ và có thể bảo trì.

Tôi thấy câu hỏi của bạn khi nói: "Tôi có thể buộc các nhà phát triển của mình tối ưu hóa sớm bằng cách cung cấp cho họ các máy phát triển kém mà vẫn nhận được mã tốt không?" Và câu trả lời là không.

20
EntropyFails

Đọc thú vị, tất cả những câu trả lời.

Nhưng tôi nghĩ rằng hầu hết mọi người trả lời ở đây đang thiếu điểm. Câu hỏi, như tôi đã đọc không phải (ít nhất là) về việc thực sự mang đến cho các nhà phát triển một P1 để tạo mã nhanh hơn.

Vấn đề là rất nhiều phần mềm ngày nay chỉ chậm hoặc thậm chí chậm hơn so với phần mềm seft mà chúng ta đã sử dụng trong thiên niên kỷ trước mặc dù có rất nhiều máy tính mạnh hơn. Đánh giá từ các câu trả lời ở đây, hầu hết các nhà phát triển không nhận được gợi ý đó. Điều này là rất rõ ràng trong các ứng dụng web. Trang web này là một ngoại lệ rất tốt, nhưng nhiều trang web đang có một trang đầu trong 1 mb. Tôi nhận được gì khi chờ đợi tải xuống? Tôi không biết. Tôi nghĩ rằng nó dường như là về một sự thiếu hiểu biết từ nhà phát triển không tôn trọng thời gian người dùng cần chi tiêu cho nó, hoặc thậm chí tệ hơn trả tiền nếu bạn trả cho mỗi mb. Có điều là tất cả các trang web đó thậm chí không chứa hình ảnh độ phân giải cao. Thường thì nó chỉ là một số mã tào lao được phân phối từ một số môi trường phát triển. Chà, tất nhiên đó không phải là mã tào lao tôi đoán, nhưng nó không mang lại lợi ích gì cho tôi với tư cách là người dùng.

Nói chung, nó không chỉ là về việc tối ưu hóa mã, mà còn nhiều về việc chọn không bao gồm những thứ làm chậm hơn so với nó mang lại.

Vài tuần trước tôi đã khởi động một máy tính xách tay từ năm 1995. Windows 3.x đã hoạt động và chạy ngay lập tức. Cơ sở dữ liệu tôi sẽ nhận được một số dữ liệu từ khi bắt đầu trước khi khóa enter được phát hành đầy đủ (gần như ít nhất).

Tôi biết rằng chúng tôi nhận được nhiều hơn từ phần mềm của chúng tôi ngày hôm nay, nhưng chúng tôi cũng có máy tính nhanh hơn nhiều lần. Tại sao ngành công nghiệp phát triển quyết định giữ tốc độ phần mềm từ năm 1995 và khiến mọi người mua phần cứng mới vì họ muốn chức năng mới. Ngày nay, nó giống như các chương trình và trang web hàng ngày buộc mọi người phải mua phần cứng mới để làm chính xác những gì họ đã làm trước đó. Nhưng tất nhiên theo một cách dễ thương hơn.

Tôi phải nói rằng tôi nghĩ rằng sự phát triển Linux dường như xử lý việc này tốt hơn. Các bản phân phối Linux trong nhiều năm đã vượt xa các cửa sổ ngay cả trong sự huyền ảo với nhiều thứ hấp dẫn như cửa sổ hoạt hình. Vấn đề là họ đã làm việc trên các máy tính của ngày hôm nay và thậm chí cả ngày hôm qua. Không chỉ cắt phần cứng Edge.

Đến bây giờ tôi đoán nhiều nhà phát triển có mức adrenalin không lành mạnh. Vâng, tôi tìm thấy một cách để trả lại một số thất vọng từ tất cả chờ đợi ở phía trước:
[.___] chưa) .net các trang web (đang tải xuống)

và như thế

Tôi cảm thấy tốt :-)

Chúc mừng
[.__.] Nicklas

15
Nicklas Avén

1) Nếu tôi cung cấp cho nhà phát triển một máy chậm hơn, điều đó có nghĩa là mã kết quả có thể nhanh hơn hoặc hiệu quả hơn?

Chúng tôi đã xây dựng phần mềm trong 6 thập kỷ qua và chúng tôi vẫn nhận được câu hỏi như thế này? Có vẻ giống như một nỗ lực khác trong việc cắt góc. Không xúc phạm, nhưng bạn ơi, bạn có nghĩ rằng câu hỏi thậm chí hợp lý không? Hãy suy nghĩ về nó trong các điều khoản này (nếu bạn có thể): bạn muốn chế tạo một chiếc xe 4x4 có thể hoạt động trong điều kiện khắc nghiệt, mưa, bùn, bất cứ điều gì. Bạn sẽ đặt các kỹ sư và dây chuyền của bạn dưới các yếu tố chỉ để đảm bảo chiếc xe kết quả có thể hoạt động trên chúng?

Ý tôi là, Chúa ơi! Có sự phát triển và có thử nghiệm. Thử nghiệm được thực hiện trong một môi trường khác, khắc nghiệt hơn hoặc nhà phát triển biết cách lắp ráp giường thử nghiệm trong môi trường dev của chính mình theo cách phù hợp để thử nghiệm căng thẳng. Nếu anh ta không thể, thay thế anh ta bằng một nhà phát triển tốt hơn.

2) Tôi có thể làm gì để cung cấp cho các nhà phát triển của mình trải nghiệm nhanh IDE, trong khi đưa ra trải nghiệm thời gian chạy 'điển hình'?

Bạn nên yêu cầu điều đó cho các nhà phát triển của bạn. Và nếu họ không thể cung cấp cho bạn câu trả lời khách quan và hợp lệ, bạn cần thay thế họ bằng các nhà phát triển thực tế.

Nhưng để giải trí cho câu hỏi, hãy cung cấp cho các nhà phát triển của bạn (giả sử bạn có nhà phát triển tốt), công cụ tốt và phần cứng tốt, tốt nhất bạn có thể chi trả. Sau đó thiết lập môi trường cơ bản chung thấp nhất trong đó phần mềm của bạn phải hoạt động. Đó nơi thử nghiệm sẽ xảy ra. Thực hành kỹ thuật tốt hơn là có một môi trường thử nghiệm khác biệt từ môi trường phát triển (tốt nhất là môi trường cho phép bạn làm để kiểm tra căng thẳng.)

Nếu các nhà phát triển của bạn là tốt, họ nên truyền đạt điều này cho bạn (giả sử bạn đã hỏi họ.)

10
luis.espinal

Nó dẫn đến một loạt các nhà phát triển chó cái. Công cụ này là đủ khó, vì vậy, đừng làm cho trải nghiệm tồi tệ hơn.

Tôi sẽ khuyến khích bạn có phần cứng tương tự với người dùng của bạn trong môi trường Kiểm tra hoặc QA để loại bỏ bất kỳ vấn đề nào về hiệu suất. Đó là một ý kiến ​​hay.

6
bigtang

Tôi sẽ bỏ định mức và nói đồng ý NẾU VÀ CHỈ nếu họ đang viết phần mềm máy chủ. Cười tất cả những gì bạn muốn, nhưng nhóm hiệu quả nhất tôi từng thấy là một nhóm những người Perl có thiết bị đầu cuối Wyse. Đây là vào cuối những năm 1990, là một cửa hàng đại học, và họ đang viết phần mềm chia lưới không gian (về cơ bản chỉ là tính toán). Tuy nhiên, họ đã nói chuyện với một số RS/6000 kiểu mẫu tương đối mạnh mẽ.

Chỉ để thêm sự quan tâm đến sự kiện, đã có một lập trình viên mù ở đó. Tôi đã rất ấn tượng.

alt text

6
Jé Queue

Đây không phải là một ý tưởng tồi - nhưng bạn muốn các nhà phát triển của mình có một môi trường lập trình nhanh chóng.

Bạn có thể thực hiện điều này bằng cách cung cấp cho các lập trình viên của bạn hai máy - hộp phát triển nhanh và hộp hàng hóa chậm hơn (có thể là ảo) để thử nghiệm.

Một số điều chỉnh của quá trình xây dựng VS có thể làm cho việc triển khai vào hộp kiểm tra trở thành chuẩn, với việc gỡ lỗi từ xa.

Có nhiều cách khác để xem xét việc buộc các lập trình viên của bạn phát triển mã hiệu quả hơn - ví dụ, bạn có thể bao gồm các mục tiêu hiệu suất và sử dụng bộ nhớ trong các bài kiểm tra đơn vị của mình. Đặt ngân sách cho việc sử dụng bộ nhớ cũng là một mục tiêu xuất sắc. Đồng thời thiết lập ngân sách trọng lượng trang cho mã html.

5
damien

Vấn đề không phải là nhà phát triển xây dựng mã không hiệu quả trên một máy nhanh, vấn đề là bạn chưa xác định được số liệu hiệu suất phải đo.

Cần phải được xác định, như là một phần của yêu cầu sản phẩm, một mục tiêu cụ thể có thể được đo lường trên tất cả các máy tính dựa trên trải nghiệm khách hàng yêu cầu. Có nhiều trang web (Kiểm tra SpecInt) cho phép bạn liên kết máy tính của mình với các loại máy tính khác.

Điều này là tốt cho nhiều lý do. Nó cho phép bạn xác định phần cứng được hỗ trợ tối thiểu dễ dàng hơn để bạn có thể hạn chế số lượng khách hàng phàn nàn - tất cả chúng ta đều biết hầu hết phần mềm chạy trên hầu hết các máy tính, đó chỉ là vấn đề về hiệu suất - nếu chúng ta đặt thông số kỹ thuật của mình để mọi người trong phạm vi yêu cầu tối thiểu có hiệu suất hợp lý chấp nhận được, bạn hạn chế khiếu nại của khách hàng - và sau đó khi khách hàng gọi đến, bạn có thể sử dụng điểm chuẩn để xác định xem có thực sự có vấn đề hay không, nếu khách hàng không hài lòng với cách sản phẩm hoạt động.

5
Mike Glasspool

Tôi tin rằng việc có máy tính chậm hơn để phát triển dẫn đến mã nhanh hơn, nhưng điều này có giá. Lý do là tôi đã trải nghiệm lần đầu tiên này: có thời gian đi làm dài, tôi đã mua một chiếc netbook để làm việc trên tàu, netbook chậm hơn bất kỳ máy tính nào tôi đã mua trong 5 năm qua. Bởi vì mọi thứ rất chậm, tôi thấy rất nhanh khi có thứ gì đó chậm đến mức không thể chịu đựng được trên chiếc netbook này và tôi nhận thấy các điểm chậm nhanh hơn nhiều (không cần phải điểm chuẩn mọi lúc). Làm việc trên một chiếc netbook thực sự đã thay đổi cách tôi phát triển.

Điều đó đang được nói, tôi không ủng hộ việc này, đặc biệt là trong một môi trường chuyên nghiệp. Đầu tiên, đó là làm mất tinh thần. Thực tế là hầu hết mọi người nói rằng ý tưởng thậm chí không có ý nghĩa cho thấy các lập trình viên phản ứng xấu với ý tưởng.

Thứ hai, có mọi thứ chậm hơn có nghĩa là những điều bạn có thể muốn làm trên máy nhanh (mất 1 phút) không thực sự có thể thực hiện được nữa trên máy chậm, vì lười biếng, v.v ... Đó là một câu hỏi khuyến khích.

Cuối cùng: mã được sản xuất có thể nhanh hơn, nhưng gần như chắc chắn sẽ mất nhiều thời gian hơn để sản xuất.

5
David Cournapeau

Điểm 1, KHÔNG! Studio có nghĩa là được chạy trên các máy tốt và yêu cầu đó chỉ trở nên mạnh mẽ hơn với mỗi phiên bản. Bạn thực sự có thể khóa một số phiên bản của studio nếu bạn bật intellisense và sử dụng hộp không lõi đơn.

Đến điểm # 2, có một số tính năng trong các dự án thử nghiệm cho phép bạn điều tiết một số tài nguyên. Họ không hoàn hảo, nhưng họ ở đó. VPC hoặc spec thấp VM hình ảnh cũng bị hạn chế khá tốt. Tôi đã có người dùng ngồi xuống máy xấu để kiểm tra đôi khi để họ có thể thấy ý nghĩa của các tính năng mà họ đã yêu cầu.

4
Bill

Không - thực tế nó sẽ dẫn đến nhiều lỗi hơn vì họ sẽ không thực hiện nhiều thử nghiệm và họ sẽ không sử dụng các công cụ bổ sung như profiler nhiều như vậy. Cung cấp cho họ những máy tốt nhất bạn có thể đủ khả năng (bao gồm cả phần cứng tăng tốc đồ họa nếu bạn là cửa hàng phát triển trò chơi hoặc đồ họa) và kiểm tra chúng bên trong máy ảo. Thông số VM có thể được tăng hoặc giảm khi cần.

4
JohnL

Tôi nghĩ rằng đây là một câu hỏi thú vị và tôi sẽ không nhanh chóng trả lời "không". Ý kiến ​​của tôi là: nó phụ thuộc vào loại nhóm phát triển mà chúng ta đang nói đến. Ví dụ: nếu bạn đang lãnh đạo một nhóm tham gia cuộc thi lập trình ICFP hàng năm, có thể có kết quả tốt sau một khoảng thời gian nhỏ phát triển trên cụm HPC không nhất thiết có nghĩa là giải pháp bạn tìm thấy là tốt. Điều tương tự cũng có thể nói nếu bạn đang viết một số thuật toán khoa học hoặc số: trên AMD Duron 600 MHz cũ của bạn với 64 MB bộ nhớ, bạn buộc phải cẩn thận về cách bạn hoàn thành công việc và điều này có thể ảnh hưởng đến cả một số thiết kế lựa chọn.

Mặt khác, một lập trình viên/nhà khoa học thông minh/bất cứ điều gì được cho là dù sao cũng phải cẩn thận. Nhưng tôi thấy mình đã viết ra một số mã tốt nhất của mình khi tôi KHÔNG có máy tính AT TẤT CẢ và phải ghi chú trên giấy. Điều này có thể không áp dụng cho các dự án lớn liên quan đến các khung lớn, khi một IDE thực sự cần thiết.

Một điều chắc chắn: máy móc nhanh và kết quả tốt ngay lập tức làm cho các lập trình viên (xấu) hư hỏng và có thể là một trong những lý do cho một số crap chúng ta tìm thấy trên máy tính.

4
Lorenzo Stella

Tôi làm việc trên một gói mất khoảng một giờ để xây dựng trên máy 8 lõi 8G của tôi (bản dựng hoàn toàn sạch). Tôi cũng có một máy tính xách tay tương đối thấp tôi thử nghiệm. Máy tính xách tay cấp thấp không quản lý hai bản dựng đầy đủ trong một ngày làm việc.

Tôi có năng suất cao hơn trên máy nhanh với một số thử nghiệm có chủ ý được thực hiện trên máy tính xách tay hay tôi nên thực hiện tất cả các bản dựng của mình trên máy tính xách tay?

Hãy ghi nhớ những số này không tạo thành số.

Đây là một bản demo được dựng sẵn ở chỗ tôi thường không cần phải xây dựng sạch mỗi ngày (tôi có thể thực hiện nhiều thử nghiệm trên các mô-đun đơn), nhưng ngay cả các bản dựng một phần cũng cho thấy mức độ chênh lệch lớn về thời gian biên dịch/liên kết .

Vì vậy, vấn đề thực sự nằm ở chiếc máy chậm chạp của tôi, một bản dựng thông thường đủ dài để tôi đi lấy một tách cà phê, trong khi trên chiếc máy nhanh hơn của tôi, tôi chỉ có thể nhâm nhi một ít cà phê.

Từ quan điểm hoàn thành công việc, tôi thích phát triển trên một máy nhanh. Tôi có thể đáng tin cậy hơn nhiều thời hạn. Mặt khác, tôi tưởng tượng nếu quản lý khiến tôi phát triển trên máy tính chậm của mình, tôi sẽ thực hiện nhiều thao tác duyệt web hơn, hoặc ít nhất là đọc sách.

4
Stripes

Thật thú vị, tôi đã làm việc tại một công ty khởi nghiệp nơi chúng tôi đã kết thúc việc này. Tôi nghĩ rằng nó thực sự hoạt động khá tốt, nhưng chỉ vì tình huống cụ thể mà chúng tôi gặp phải. Đó là một cửa hàng mod_Perl nơi tải lại tự động lớp thực sự hoạt động chính xác. Tất cả các nhà phát triển đã sử dụng vim làm IDE của sự lựa chọn (hoặc sử dụng một số phần mềm chỉnh sửa từ xa). Kết quả cuối cùng là rất ít (nếu có) mất thời gian chờ mã để biên dịch/tải lại/Vân vân.

Về cơ bản, tôi thích ý tưởng này IFF có tác động không đáng kể đến chu kỳ phát triển cho tất cả các nhà phát triển và nó chỉ ảnh hưởng đến hoạt động thời gian chạy của mã của bạn. Nếu mã của bạn được biên dịch, xử lý trước, v.v., thì bạn đang thêm thời gian để "sửa lỗi, kiểm tra; tiếp theo" mà các nhà phát triển đang làm việc.

Từ phía giữa các cá nhân, mọi người không bao giờ bắt buộc để sử dụng các máy chủ chậm, nhưng nếu bạn sử dụng các máy chủ chậm, bạn sẽ không phải thực hiện bất kỳ bảo trì hoặc thiết lập nào của riêng mình. Ngoài ra, thiết lập này đã tồn tại ngay từ đầu, tôi không thể tưởng tượng được việc cố gắng bán nó cho một nhóm phát triển được thành lập.

Sau khi đọc lại câu hỏi ban đầu của bạn, tôi nhận ra rằng một điều khiến tôi luôn khiếp sợ là môi trường phát triển khác với môi trường sản xuất. Tại sao không sử dụng a VM để thực thi mã mà bạn có thể làm tê liệt thời gian chạy mà không ảnh hưởng đến máy trạm dev? Gần đây, tôi đã sử dụng/yêu VirtualBox.

3
user6041

Tôi cũng sẽ nắm bắt xu hướng ở đây.

Giai thoại: Tôi đã làm việc cho một công ty phát triển phần mềm của Hà Lan đã nâng cấp 286 máy tính lên 486-es (vâng, tôi đã già rồi). Trong vài tuần, hiệu suất của tất cả các thư viện nội bộ của chúng tôi đã giảm 50% và lỗi tăng lên ... Một nghiên cứu nhỏ cho thấy mọi người không còn nghĩ về chính mã trong quá trình gỡ lỗi, mà dùng đến mã 'nhanh' liên tiếp -> biên dịch -> kiểm tra -> sửa (mã) vv chu kỳ.

Liên quan: khi tôi thành lập một công ty con cho cùng một công ty ở Mỹ, cuối cùng tôi đã thuê các lập trình viên người Nga vì họ đã quen với các PC có ít tính năng/ít năng lượng hơn và là các lập trình viên hiệu quả hơn nhiều.

Tôi nhận ra đây là những thời điểm khác nhau và tài nguyên khan hiếm hơn nhiều so với ngày nay, nhưng nó không bao giờ làm tôi ngạc nhiên về cách thức, với tất cả những tiến bộ đã đạt được trên mặt trận phần cứng, kết quả ròng dường như là mỗi bước tiến bị phủ nhận bởi lập trình sloppier yêu cầu thông số kỹ thuật tối thiểu cao hơn ...

Do đó ... tôi cảm thấy các lập trình viên nên bị buộc phải kiểm tra các ứng dụng của họ trên các máy không vượt quá sức mạnh tính toán và thông số phần cứng của 'Average Joe'.

3
John SMythe

Phần cứng ít tốn kém hơn thời gian phát triển.

Hầu hết các nút cổ chai nằm trong cơ sở dữ liệu không phải trong PC khách, nhưng điều đó không tha cho việc kiểm tra trên các máy chậm hơn so với nhà phát triển. Sử dụng các công cụ kiểm tra để kiểm tra tối ưu hóa.

3
Brian

Tuyệt đối không. Cung cấp cho các lập trình viên của bạn số tiền máy tính xách tay tốt nhất có thể mua, bàn phím họ chọn, nhiều màn hình lớn tuyệt vời, văn phòng riêng, không điện thoại, nước ngọt miễn phí, tất cả những cuốn sách họ muốn (có liên quan), các chuyến đi hàng năm đến các hội nghị công nghệ quan trọng và bạn sẽ nhận được kết quả tuyệt vời. Sau đó kiểm tra các kết hợp phần cứng/phần mềm/trình duyệt/băng thông ranh giới trên và dưới.

3
addictedtoswdev

Đối với nhiều ứng dụng, vấn đề là khiến các nhà phát triển thử nghiệm với các bộ dữ liệu trong thế giới thực trước khi chúng được "hoàn thành". Đối với các ứng dụng tương tác, sẽ cần có máy kiểm tra cơ sở/VM.

2
user6043

Tôi làm việc trên một máy Windows95 chậm và nó cho phép tôi viết trí tuệ nhân tạo MindForth một cách hiệu quả bằng Forth và bằng JavaScript.

2
Mentifex

Đây là một suy nghĩ thú vị (cung cấp cho các nhà phát triển một máy chậm có thể khiến họ tối ưu hóa nhiều hơn).

Tuy nhiên, giải pháp được đóng khung theo cách tốt hơn - đặt thời gian đáp ứng trong các yêu cầu cho các chương trình và có sẵn một máy cấp thấp để thử nghiệm.

Ngoài ra, nếu bạn có một trình biên dịch/ngôn ngữ thực sự rít, nó có thể tạo ra các cách khác nhau để tạo mã và chọn ngôn ngữ tốt nhất. Điều đó sẽ chỉ được giúp đỡ bởi một máy tính nhanh hơn.

2
Paul Nathan

Những người khác đã trả lời rằng nhìn chung bạn muốn các nhà phát triển có máy móc nhanh. Tôi đồng ý. Đừng bỏ qua RAM - bạn muốn có nhiều bộ nhớ nhất có thể - một số quy trình xây dựng rất nặng đối với việc sử dụng đĩa.

Điều bạn có thể muốn xem xét loại bỏ là chống vi-rút trên các ổ đĩa xây dựng! Điều đó chỉ làm chậm lại và có thể là một yếu tố làm chậm cực kỳ mạnh mẽ.

Bạn có thể muốn để cho các nhà phát triển phát triển trên Linux nếu có thể. Các công cụ ở đó tốt hơn nhiều cho tất cả các loại tác vụ bổ sung (chỉ grep cho một cái gì đó trong một tệp, v.v.). Điều này cũng được loại bỏ chống vi-rút.

2
user1249

Hỏi các lập trình viên liệu các lập trình viên có nên có phần cứng tốt hay không cũng giống như hỏi một người đàn ông béo xem anh ta có thích đồ ăn không. Tôi biết đây là sự trao đổi chủ quan, nhưng vẫn ... là câu hỏi đáng để chúng ta hỏi? : P

Điều đó nói rằng tôi tất nhiên đồng ý với đa số: KHÔNG .

2
Matthew Read

Tôi muốn nói "Không" một cách phân loại, nhưng hãy để tôi chia sẻ kinh nghiệm gần đây: Ai đó trong dự án của chúng tôi đang làm việc với một số mã để nhập dữ liệu vào cơ sở dữ liệu. Vào thời điểm anh ấy có PC lâu đời nhất trong nhóm của chúng tôi, thậm chí có thể là toàn bộ tổ chức. Nó hoạt động tốt với VS 2008, nhưng tất nhiên một cỗ máy nhanh hơn sẽ giúp trải nghiệm tốt hơn. Dù sao, tại một thời điểm, quá trình anh ta đã viết bị đánh bom trong khi thử nghiệm (và đó là trước khi nó có đầy đủ tính năng). Anh hết trí nhớ. Quá trình cũng mất vài giờ để thực hiện trước khi nó bị đánh bom. Hãy ghi nhớ, theo như chúng tôi biết, đây là những gì người dùng sẽ phải sử dụng.

Anh ta yêu cầu thêm RAM. Họ đã từ chối, vì anh ta đã nhận được một máy mới hơn trong 3-4 tuần và máy cũ sẽ bị loại bỏ.

Hãy nhớ rằng triết lý tối ưu hóa của anh chàng này là: "Chúng tôi có các máy nhanh với nhiều RAM" (dù sao và một số máy bị loại trừ), vậy tại sao lại lãng phí thời gian của lập trình viên có giá trị? Nhưng tình huống buộc anh phải thay đổi thuật toán để có hiệu quả bộ nhớ cao hơn để nó chạy trên máy 2Gb của anh (chạy XP.) Một tác dụng phụ của việc viết lại là quá trình này cũng chạy nhanh hơn nhiều so với trước đây . Ngoài ra, phiên bản gốc cuối cùng sẽ bị đánh bom ngay cả với 4Gb khi có nhiều dữ liệu được nhập vào - đó là một bộ nhớ, đơn giản và đơn giản.

Soooo ... Mặc dù nói chung tôi sẽ nói "Không", đây là trường hợp nhà phát triển có một máy kém mạnh hơn dẫn đến mô-đun được tối ưu hóa tốt hơn và kết quả là người dùng sẽ được hưởng lợi (vì đó không phải là quá trình cần phải được chạy rất thường xuyên, ban đầu anh ta không có ý định tối ưu hóa nó, vì vậy họ sẽ bị kẹt với phiên bản gốc nếu máy có đủ RAM để chạy một vài thử nghiệm lớn .. .) Tôi có thể thấy quan điểm của anh ấy, nhưng cá nhân tôi không thích ý tưởng người dùng phải đợi 8 giờ để quá trình hoàn tất, khi nó có thể chạy trong một phần nhỏ thời gian đó.

Như đã nói, như một quy tắc chung, các lập trình viên nên có những cỗ máy mạnh mẽ vì phần lớn sự phát triển khá chuyên sâu. Tuy nhiên, cần hết sức cẩn thận để đảm bảo rằng việc kiểm tra được thực hiện trên các máy "mẫu số chung thấp nhất" để đảm bảo rằng quy trình không đánh bom và người dùng sẽ không xem Paint khô cả ngày. Nhưng điều này đã được nói rồi. :)

2
MetalMikester

Khi đọc câu hỏi và câu trả lời, tôi choáng váng vì sự kịch liệt của vụ án KHÔNG.

Tôi đã làm việc trong lĩnh vực phát triển phần mềm được 25 năm và tôi có thể nói mà không ngần ngại rằng các lập trình viên cần rất nhiều thứ để phát triển mã tốt:

  • Một môi trường phát triển HỢP LÝ. Không phải khủng long. Nó cũng không cần phải bị chảy máu Edge. Đủ tốt để không nản lòng.

  • Một đặc điểm kỹ thuật tốt (bao nhiêu được thực hiện với NO đặc tả bằng văn bản?)

  • Quản lý tốt và hỗ trợ.

  • Một lịch trình phát triển hợp lý.

  • Một sự hiểu biết tốt về người dùng VÀ MÔI TRƯỜNG người dùng sẽ có.

Hơn nữa, về điểm cuối cùng này, các nhà phát triển cần phải suy nghĩ về những gì người dùng sẽ sử dụng. Nếu người dùng có siêu máy tính và đang thực hiện mô phỏng phân tách nguyên tử hoặc một cái gì đó mà hiệu suất tốn rất nhiều tiền và các tính toán chạy trong nhiều giờ, thì hãy nghĩ rằng hiệu suất sẽ được tính.

Nếu người dùng có 286 máy tính xách tay chạy bằng Steam thì việc phát triển và yêu cầu các nhà phát triển thực hiện thử nghiệm phát triển của họ trên Core i9000 47 GHz mới nhất sẽ dẫn đến một số vấn đề.

Những người nói "cung cấp cho các nhà phát triển những điều tốt nhất và KIỂM TRA nó" là một phần đúng nhưng điều này có một vấn đề MENTAL lớn cho các nhà phát triển. Họ không đánh giá cao trải nghiệm người dùng cho đến khi quá muộn - khi thử nghiệm thất bại.

Khi thử nghiệm thất bại - các kiến ​​trúc đã được cam kết, ban quản lý đã có những lời hứa, rất nhiều tiền đã được sử dụng, và sau đó nó biến thành một thảm họa.

Các nhà phát triển cần suy nghĩ thích, hiểu và ở trong khu vực trải nghiệm người dùng từ ngày 1.

Những người khóc "ồ không, nó không hoạt động như vậy" đang nói lên điều gì đó. Tôi đã thấy điều này xảy ra, nhiều lần. Phản hồi thông thường của các nhà phát triển là một trong những câu "nói rõ với KHÁCH HÀNG để mua một máy tính tốt hơn", điều này có hiệu quả đổ lỗi cho khách hàng. Không đủ tốt.

Vì vậy, điều này có nghĩa là bạn có một số vấn đề:

  • Giữ cho các nhà phát triển hạnh phúc và đi tiểu của quản lý, tăng cơ hội dự án thất bại.

  • Sử dụng các máy chậm hơn để phát triển, với nguy cơ làm đảo lộn các nhà phát triển, nhưng giữ cho họ tập trung vào những gì thực sự quan trọng.

  • Đặt 2 máy trên bàn của nhà phát triển VÀ LỜI NÓI ĐỂ KIỂM TRA TRÊN CLUNKER (điều mà họ sẽ không làm vì nó nằm dưới sự khinh miệt .... nhưng ít nhất là rất rõ ràng nếu có vấn đề về hiệu năng trong thử nghiệm).

Ghi nhớ hệ thống hàng loạt và thẻ đục lỗ? Mọi người chờ đợi một giờ hoặc một ngày để quay vòng. Công cụ đã được thực hiện.

Ghi nhớ các hệ thống unix cũ với bộ xử lý 5 MHz? Mọi thứ đã được thực hiện.

Techo-geek thích đuổi theo Edge chảy máu. Điều này khuyến khích mày mò, không suy nghĩ. Một cái gì đó tôi đã tranh luận với nhiều nhà phát triển juniour hơn trong những năm qua .... khi tôi thúc giục họ rời khỏi bàn phím và dành nhiều thời gian hơn để đọc mã và suy nghĩ.

Trong phát triển mã, không có thay thế cho suy nghĩ.

Trong trường hợp này, cảm giác của tôi là - tìm ra NHỮNG VẤN ĐỀ THỰC SỰ. Thành công của dự án? Đây có phải là một công ty thực hiện/giết chết tập thể dục? Nếu có, bạn không thể để thất bại. Bạn không đủ khả năng để thổi tiền vào những thứ thất bại trong thử nghiệm. Bởi vì thử nghiệm là quá muộn trong chu kỳ phát triển, tác động của sự thất bại được tìm thấy quá muộn.

[Một lỗi được tìm thấy trong thử nghiệm tốn khoảng 10 lần sửa chữa như một lỗi được tìm thấy bởi một nhà phát triển trong quá trình phát triển.

Và một lỗi được tìm thấy trong thử nghiệm tốn khoảng 100 lần sửa chữa vì lỗi đó được thiết kế trong giai đoạn thiết kế kiến ​​trúc.]

Nếu đây không phải là một công cụ thỏa thuận và bạn có thời gian và tiền bạc để đốt cháy, thì hãy sử dụng môi trường phát triển Edge đang chảy máu và chịu đựng những thất bại trong thử nghiệm. Nếu không, tìm cách khác. Đầu dưới h/w, hoặc 2 máy trên mỗi bàn.

2
quickly_now

Macbook Pro của tôi tại nơi làm việc là một vài năm tuổi. Giữa Linux và Windows (để kiểm tra IE quirks) vms cũng như một vài trình duyệt web và thiết bị đầu cuối mở, bánh xe quay OSX xuất hiện rất nhiều. Đoán xem tôi làm gì khi nó quay, tôi ngồi và chờ đợi. Trong trường hợp này, một máy chậm làm năng suất chậm.

2
Thierry Lam

Tôi nói các nhà phát triển cần hệ thống phát triển tốt nhất hiện có - nhưng điều đó không nhất thiết có nghĩa là nhanh nhất. Nó cũng có thể có nghĩa là một hệ thống hiện đại nhưng tương đối chậm với làm mát hoàn toàn thụ động, để giảm tiếng ồn đến mức tối thiểu, ví dụ.

Một điều - một hệ thống phát triển phải mới hợp lý và nên hoàn toàn có nhiều lõi.

Một PC cũ nghe có vẻ hấp dẫn theo kiểu trình diễn sớm về vấn đề hiệu năng, nhưng Pentium 4, chẳng hạn, có thể thực sự nhanh hơn (trên mỗi lõi) so với một số chip hiện tại. Điều đó có nghĩa là bằng cách giới hạn nhà phát triển sử dụng hệ thống P4 (thực ra là những gì tôi đang sử dụng bây giờ - mặc dù đó là vấn đề ngân sách cá nhân của tôi) ...

  1. Bạn khuyến khích phát triển phần mềm không đồng thời sẽ không được hưởng lợi từ các hệ thống đa lõi chính hiện tại.
  2. Ngay cả khi phần mềm đa luồng được phát triển, các lỗi có thể không được chú ý (hoặc ít nhất là không được chú ý sớm) vì các vấn đề liên quan đến đồng thời có thể không xuất hiện trong thử nghiệm trên hệ thống đơn lõi.
  3. Phần mềm đa luồng có thể gây ra các vấn đề hiệu năng nghiêm trọng có thể trở nên tồi tệ hơn nhiều với bộ xử lý đa lõi. Người ta sẽ gây ra sự cố đập đầu đĩa (có thể dẫn đến việc truy cập dữ liệu chậm hơn hàng nghìn lần) trong đó các luồng riêng lẻ đang thực hiện truy cập tuần tự, nhưng mỗi luồng đến một phần khác nhau của đĩa. Điều này thậm chí có thể biến mất trên các PC cũ chậm hơn, ví dụ: có hai ổ 160 GB cũ thay vì một ổ 1TB, các luồng đó có thể không còn chiến đấu với nhau để truy cập vào cùng một đĩa.

Cũng có những vấn đề với PC quá hạn chế để hỗ trợ tốt cho máy ảo - ví dụ: để thử nghiệm trong nhiều nền tảng.

1
Steve314

Câu trả lời nằm ở giữa.

Có một hộp nhanh để chạy môi trường dev (ví dụ: Eclipse)

Và một hộp chậm khác để kiểm tra đầu ra. Điều này đặc biệt quan trọng đối với các ứng dụng web.

Màn hình cạnh nhau, một cho mỗi hộp.

Nếu mã được chấp nhận trên hộp đầu ra, nó sẽ được chấp nhận nhiều hơn cho hầu hết người dùng.

Hộp dev nhanh làm cho lập trình viên lười biếng. Ví dụ: tìm kiếm một phần tử trong DOM mỗi khi cần. Tìm nó một lần và lưu trữ kết quả.

Bạn sẽ thực sự nhận thấy sự khác biệt trên một hộp chạy chậm IE 6 ....

1
David Semeria

Giả thuyết này đơn giản và lỗi thời. Đó là sự thật trở lại trong những ngày.

Tôi nhớ rằng đã dành nhiều thời gian hơn để tối ưu hóa công cụ Turbo Pascal của mình trên máy tính trước Pentium. Nó chỉ có ý nghĩa trước Y2K, ít hơn bao giờ hết. Ngày nay bạn không tối ưu hóa cho phần cứng 10 năm tuổi. Nó đủ để kiểm tra phần mềm để tìm ra tắc nghẽn. Nhưng như mọi người ở đây lo lắng, điều này không có nghĩa là nhà phát triển (và do đó tối ưu hóa) tương quan với việc cung cấp cho họ phần cứng lỗi thời để phát triển.

1
mario

1) Nếu tôi cung cấp cho nhà phát triển một máy chậm hơn, điều đó có nghĩa là mã kết quả có thể nhanh hơn hoặc hiệu quả hơn?

Số nhà phát triển giỏi được chiều chuộng. Nếu họ thấy họ nhận được các công cụ xấu tại công ty của bạn, họ sẽ đi làm việc ở một nơi khác. (Các nhà phát triển giỏi thường có lựa chọn đi đâu đó khác)

1
Sean Patrick Floyd

Không phải câu trả lời cho câu hỏi này là "KHÔNG" độc lập với bất cứ ai bạn hỏi?

Hỏi nghệ sĩ đồ họa của bạn nếu họ nên được cung cấp một máy chậm hơn.

Hỏi các nhà văn của bạn nếu họ sẽ chọn một máy chậm hơn một máy nhanh hơn.

Hỏi trợ lý hành chính của bạn xem họ thích máy chậm hơn hay nhanh hơn.

Tất cả trong số họ sẽ nói rằng họ sẽ làm việc hiệu quả hơn với một máy nhanh hơn.

1
Barry Brown

Tôi chỉ có thể tưởng tượng trải nghiệm hồ sơ trong khi sử dụng một máy chậm. Rất tiếc.

Nói ngắn gọn. Trời ơi không.

Ngoài ra có ít nhất 4gb ram để bạn có thể có 2gb trên máy chính của mình, 1 cho a VM và 1 cho bộ nhớ thêm, VM cần và cho bạn có bộ nhớ chậm.

Ngoài ra, hai bộ xử lý là bắt buộc vì vậy nếu một ứng dụng khóa/ăn CPU, nhà phát triển không cần phải đau đớn để ctrl-alt-del một cái gì đó.

0
user2528

Hãy đi ngược lại dòng chảy ở đây: CÓ. Hoặc ít nhất đó là sự khôn ngoan chung trong ngành trong nhiều thập kỷ (tất nhiên trừ các nhà phát triển, những người luôn tức giận khi họ không được đối xử như hoàng gia và có được các thiết bị và máy tính mới nhất).

Tất nhiên, có một điểm trong đó việc giảm máy của nhà phát triển sẽ gây bất lợi cho hiệu suất công việc của anh ta, vì nó trở nên quá chậm để chạy các ứng dụng anh ta cần chạy để hoàn thành công việc. Nhưng điểm đó là một chặng đường dài từ một máy tính $ 10000 + với RAM 6GB, 2 băng video 4GB, soundcard cao cấp, 4 màn hình, v.v.

Tôi đang làm việc chưa bao giờ có máy cao cấp và nó không bao giờ làm tôi chậm đi đáng kể miễn là nó ổn (và một vài máy dưới tiêu chuẩn thực sự đã nhanh chóng được thay thế khi tôi chỉ ra cách chúng làm tôi chậm lại).

0
jwenting

Tốc độ thời gian chạy trên máy của nhà phát triển là không liên quan, trừ khi bạn muốn trả thù hoặc trừng phạt nhà phát triển của mình vì đã viết mã chậm và không biết gì về môi trường triển khai mục tiêu.

Là người quản lý, bạn nên đảm bảo các nhà phát triển biết mục tiêu của dự án và luôn đảm bảo họ đang đi đúng hướng. Về vấn đề máy mục tiêu mà chúng ta đang thảo luận, nó có thể được ngăn chặn bằng cách kiểm tra sớm và thường xuyên trên máy chậm, chứ không phải bằng cách cho chúng sử dụng máy chậm để chịu đựng.

Tốc độ thời gian chạy chậm cũng làm chậm sự phát triển, vì hầu hết các lập trình viên đang sử dụng phương pháp mã và kiểm tra. Nếu thời gian chạy chậm, nhiệm vụ của họ cũng sẽ chậm.

0
tia