2009-02-26 17 views
5

Tôi đã tò mò về mức độ thường xuyên các nhà phát triển phần mềm khác đánh giá lại môi trường và công cụ phát triển của họ. Tôi từng làm việc tại một tập đoàn lớn với các bộ công cụ cứng nhắc mà mọi người ghét, nhưng không thể làm gì cả. Vì vậy, không ai thực sự cập nhật môi trường phát triển của họ bởi vì chúng tôi không thể ở trong môi trường đó.Bạn đánh giá lại thường xuyên và nâng cấp môi trường phát triển và dev của bạn như thế nào. công cụ?

Bây giờ tôi tự khởi động, tôi thấy tôi có thể dành thời gian vô tận để đánh giá các công cụ và môi trường phát triển mới, nhưng tôi thực sự không nên và không thể chi trả. Tôi đã cam kết chi tiêu 1 ngày một tháng để xem xét các công cụ phát triển mới và thử chúng để xem liệu nó có đáng để chuyển đổi hay không.

Bạn có thường xuyên thử IDE, trình chỉnh sửa, công cụ sửa lỗi, trình gỡ rối mới của IDE không? Hoặc cập nhật lên phiên bản mới hơn của riêng bạn?

+0

Heck là một chủ đề về IDE không liên quan đến lập trình? –

Trả lời

1

Tôi chỉ cập nhật trừ khi tôi thực sự bỏ lỡ một chức năng nhất định hoặc nhận ra rằng KHÔNG sử dụng một công cụ thay vì một công cụ khác dẫn đến nhiều tác vụ mất nhiều thời gian hơn/ít hiệu quả hơn.

+0

Tôi muốn nói đó là sự kết hợp giữa các phương pháp của tsilb và Jekke. Tôi chú ý đến các bản phát hành mới, nhưng như tôi đã nói, chỉ nâng cấp nếu tôi thực sự cần công cụ mới (hoặc tìm, sau khi thử nghiệm, rằng các tính năng mới thật tuyệt vời và việc nâng cấp sẽ không ảnh hưởng đến các mong đợi khác của sản phẩm). –

4

Đó là một quá trình liên tục, nhưng tôi không thực hiện các thay đổi lớn thường xuyên hơn hai năm một lần. Một thay đổi lớn liên quan đến quá nhiều thời gian, và sự cân bằng thường không đáng giá. Những thay đổi lớn có thể được định nghĩa là thay đổi toàn bộ đích hoặc kiến ​​trúc trình biên dịch và chuỗi công cụ cho một dự án hiện có.

Lưu ý rằng những thay đổi lớn có thể xảy ra giữa các dự án - một dự án mới có thể giải quyết trên một kiến ​​trúc và chuỗi công cụ hoàn toàn khác với chi phí không đáng kể. Nhưng hãy cẩn thận không nên đi quá cạnh chảy máu ở đây. Một quá trình đánh giá là cần thiết để ngăn chặn việc lựa chọn một thiết lập sẽ không hỗ trợ dự án sau này khi dự án phát triển phức tạp.

Nhưng đối với những thay đổi nhỏ, tôi chỉ cần nâng cấp các công cụ và môi trường của mình khi tôi tìm thấy cơ hội và lý do để làm như vậy.

-Adam

3

Đối với tôi, bản nâng cấp được định hướng theo sự kiện chứ không phải định thời gian. Tôi giữ cho tai của tôi để mặt đất cho các công cụ mới (thư viện, IDE, công cụ CASE, vv) và đánh giá chúng khi chúng hiển thị trên radar của tôi.

Làm việc với các công nghệ của Microsoft, tôi chuyển sang phiên bản mới nhất nếu không có lý do thuyết phục nào giữ tôi quay lại. Với PMNM, tôi sử dụng những gì tôi biết trừ khi có điều gì đó hấp dẫn thúc đẩy tôi tiến lên.

2

Khi làm việc, chúng tôi nâng cấp một công cụ khi phiên bản của chúng tôi kết thúc thời gian hỗ trợ. Chúng tôi nâng cấp lên phiên bản cũ hơn.

Ở nhà, tôi nâng cấp ngay khi tôi có thể tìm bản sao của nội dung mới miễn phí (nghĩa là một số giao dịch tham dự 3 webcast sẽ gửi cho bạn một bản sao của ấn bản vs2008, nhóm người dùng, v.v.).

3

IDE là. Tôi có xu hướng gắn bó với cái tôi biết sẽ phát triển và hỗ trợ ngôn ngữ của tôi. Trong môi trường dev của tôi, nó là vim. Nó được tích cực phát triển, và có rất nhiều kịch bản (kinda như plugins) cũng như tài liệu cho DIY. Việc sử dụng IDE cũng cần thời gian, và trở nên tốt hơn, sử dụng nó một cách hiệu quả cần nhiều thời gian hơn.

Điều khiển sửa đổi. Tôi cố gắng ở ngay dưới rìa chảy máu. Lợi ích của các tính năng mới rất quan trọng. Ví dụ: Subversion 1.4, chỉ hỗ trợ hợp nhất thô sơ. Subversion 1.5 đã sửa chữa hệ thống hợp nhất của họ và thêm new features.

Quản lý công việc và dự án. Tôi có xu hướng làm điều đó chỉ vài năm một lần, và chỉ khi có một lợi ích nhận thức tốt. Nếu không, tôi sẽ tiếp tục nâng cấp hệ thống hiện tại của mình lên bản phát hành ổn định hiện tại vài tháng một lần.

Thư viện. Họ là một quăng lên. Vì hầu hết mọi thứ tôi làm không kết thúc trong một sản phẩm được vận chuyển. Tôi cảm thấy tự do hơn để nâng cấp thường xuyên, nhưng chúng tôi có xu hướng nhút nhát khi nâng cấp khi khả năng tương thích ngược bị hỏng.

Hy vọng 0,02 đô la của tôi hữu ích.

1

IDE - Điều này có thể phức tạp nhưng tôi đã trải qua một vài tiến triển khác nhau trong những năm qua. Đôi khi, trên một dự án hoặc một tính năng cụ thể có thể kích hoạt nâng cấp. Ví dụ, ai đó đã triển khai một tính năng sử dụng LINQ vì vậy dự án ASP.Net 2.0 đã trở thành một dự án 3,5 qua đêm là gì. Lần khác, nó chỉ là những gì hiện đang được sử dụng. Một điểm ở đây là một sự thay đổi có thể ảnh hưởng đến toàn bộ một nhóm vì vậy nó không phải là một sự thay đổi được thực hiện một cách nhẹ nhàng.

Công cụ theo dõi lỗi - Đây cũng là vùng đất của những thứ tập trung cần được quản lý cẩn thận. Vì đây là công cụ QA, tôi hy vọng họ có chính sách riêng về mức độ thường xuyên tìm kiếm các bản cập nhật và thời điểm cài đặt chúng như đôi khi các tính năng mới có thể trở nên thú vị. Tương đương với nhóm dev sẽ là khi cập nhật wiki.

Điều khiển phiên bản - Đây là những điều khiển được quản lý riêng vì hầu hết chúng ta sử dụng Tortoise SVN để mỗi chúng tôi có bản sao máy khách cục bộ. Vì vậy, các cập nhật được thực hiện khi ai đó muốn làm điều đó. Tôi muốn ở lại đến ngày càng nhiều càng tốt, cá nhân.

OS - Trong khi một phần của điều này có thể được kiểm soát trên cơ sở bộ phận, có đủ các phần khác nhau để cập nhật đôi khi tôi sẽ tự chạy bản cập nhật. Tôi không chắc khi nào chúng tôi sẽ chuyển sang Windows 7 như tôi biết chúng tôi sẽ không đi đến Vista và tôi nghĩ rằng có lúc chúng tôi sẽ thoát khỏi XP vì tôi đã ở trên XP trong khoảng 5 năm trước đó tôi đã ở trên Windows 2000 Professional trong một vài năm và NT 4.0 trước đó.

PC - Có chính sách 3 năm một lần chúng tôi nhận được máy mới mà tôi tin. Khi tôi bắt đầu từ bây giờ, tôi đã ở trên một hộp P4, vì vậy việc nâng cấp lên một hộp lõi kép rất tốt đẹp cũng như tăng RAM tốt từ 2 GB lên 4 GB.

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