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? [đóng cửa]

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 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 nhà phát triển của mình trải nghiệm IDE nhanh, đồng thời mang lại 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 của mình cho 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 đã có 1 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

Chắc chắn rồi

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, họ cuối cùng 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ư sân golf trong khi bán say. Ôi chao ...

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

NO .

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ó trình giả lập, máy ảo, máy thực tế với người kiểm tra có thể kiểm tra hiệu năng để xem đó có phải là yếu tố không.

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ể đưa thứ gì đó khó chịu vào cà phê của bạn để gợi ý 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 IDE sẽ làm bất cứ điều gì đang làm hoặc bất cứ lúc nào họ không dành để 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 đề này, 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 sự của họ.

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.

Đâ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. (Hơi OT, nhưng cũng giúp không chặn quyền truy cập của họ vào các trang web có khả năng hữu ích với WebSense và tương tự.) Nếu bạn bị hạn chế bởi việc có người dùng vẫn đang chạy công nghệ Thời đại đồ đá, thì bạn sẽ cần phải có máy kiểm tra 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ệ.

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.

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!

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ọ tiêu tốn 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?

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ã ra 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 đườ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 bán 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 đơn luồng 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.

Đọ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ậ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ễ hiểu 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ỉ trên phần cứng tiên tiến.

Đế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. Có, tôi đã tìm ra cách để lấy lại sự thất vọng từ tất cả sự chờ đợi trước:
máy chủ văn phòng sql (khởi động bảng điều khiển quản lý) arcgis (khởi động và sử dụng) trình đọc acrobat (khởi động) agresso (sử dụng, ít nhất là ứng dụng web) cửa sổ (nhìn chằm chằm và sử dụng, tôi chưa thử 7) trang web .net (đang tải xuống)

và v.v.

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

Chúc mừng
Nicklas

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 tại các góc cắt. 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 lắp ráp của mình 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 nhà phát triển của mình trải nghiệm IDE nhanh, đồng thời mang lại 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. Đó là nơi thử nghiệm nên xảy ra. Đó là thực hành kỹ thuật tốt hơn nhiều để có một môi trường thử nghiệm khác biệt với 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 tốt, họ nên truyền đạt điều này cho bạn (giả sử bạn đã hỏi họ.)

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.

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 tạo 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 hứng thú cho sự kiện, đã có một lập trình viên mù ở đó. Tôi đã rất ấn tượng.

Đâ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.

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.

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 đã có kinh nghiệm đầ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 thực hiện 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ì sự 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.

Đ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 HT.

Đế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 hình ảnh VM thông số kỹ thuật thấp cũng khá tốt khi bị hạn chế. Tôi đã có người dùng ngồi xuống các máy xấu để thỉnh thoảng kiểm tra để họ có thể thấy ý nghĩa của các tính năng mà họ đã yêu cầu.

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ư trình biên dịch 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ố kỹ thuật VM có thể được thu nhỏ lên hoặc xuống khi cần thiết.

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 đang 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 TẠI 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.

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 sự 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.

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ự động tải lại 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 lựa chọn của họ (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.v.

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ị buộc phải 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 sợ hãi 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 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 thích VirtualBox.

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ề 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'.

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.

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 mà họ chọn, nhiều màn hình lớn, 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.

Đâ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.

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 về 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.

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 các quirks IE) 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 đợi. Trong trường hợp này, một máy chậm làm năng suất chậm.

Đố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 một máy kiểm tra cơ sở / VM.

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.

Hỏi các lập trình viên rằng 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 .