Khi nào, làm thế nào và tại sao một khung nâng cấp (Java)?

Tóm tắt ngắn gọn như giới thiệu:

Chúng tôi là một nhóm phát triển web Java nhỏ, tạo các ứng dụng sử dụng các khung và thư viện khác nhau như JSF, Hibernate, Seam, tất cả cùng được triển khai trong JBoss AS.

Ban đầu, ứng dụng được kết hợp với nhau và một số tính năng được thêm vào để tạo thành một chương trình giới thiệu để hiển thị cho khách hàng tiềm năng. Một số đánh bóng đã diễn ra, ứng dụng đã được phát hành, nó đã được chấp nhận và hoạt động và khi thời gian trôi qua, các tính năng bổ sung đã được thêm vào, lỗi đã được sửa, lỗi mới xảy ra, như mọi khi.

Do các yếu tố xe buýt cao và đua xe khởi nghiệp, sự phát triển đã vượt quá tầm kiểm soát - ngày càng có nhiều tính năng được thêm vào, chưa hiểu đầy đủ kiến ​​trúc cốt lõi của hệ thống. Nó vẫn hoạt động, nhưng luôn có những cạm bẫy vì hệ thống phát triển từ nơi nó bắt nguồn từ một thứ khác và ban đầu, nhiều phím tắt đã được thực hiện để tăng tốc độ phát triển - bây giờ tất cả điều này quay trở lại và phát triển chậm lại, vì cách giải quyết được sử dụng và nó khá khó để giới thiệu các nhà phát triển mới vào dự án.

Bây giờ, tôi đang trong quá trình dọn dẹp và sắp xếp mọi thứ - cài đặt hệ thống theo dõi lỗi, xây dựng văn hóa kiểm tra / chất lượng, nghĩ cách làm kiểm thử tự động, đánh giá mã (tất cả những thứ chuyên nghiệp ưa thích mà chúng tôi đang thiếu bắt đầu) và thực hiện tái cấu trúc chung như tổ chức các hệ thống phân cấp và chức năng của lớp để giúp sử dụng công cụ dễ dàng hơn. Điều đó làm cho mọi thứ tốt hơn một chút, nhưng vẫn còn rất nhiều việc phải làm. Vì tôi không phải là người ban đầu xây dựng hệ thống (cựu lập trình viên chính còn lại) và không có kinh nghiệm (phát triển được 2,5 năm nay, nhưng đó là kinh nghiệm 'thế giới mở' duy nhất của tôi cho đến nay), tôi không chắc chắn phải làm gì làm

Đây là vấn đề của tôi:

Tái cấu trúc luôn là một cái gì đó tốt và tôi liên tục làm nó để làm cho mọi thứ dễ dàng hơn, nhưng điều khiến tôi bối rối là khi nào, làm thế nào và tại sao tôi nên nâng cấp kiến ​​trúc cơ bản (có nghĩa là, các thư viện mà hệ thống dựa vào, máy chủ ứng dụng, cơ sở dữ liệu, v.v.)

Ví dụ:

• Chúng tôi hiện đang sử dụng JBoss 4.2.2 - Tôi đã đọc ở đâu đó về JBoss 7.1, tôi có nên dùng nó không? Làm thế nào người ta có thể đánh giá điều này?

• Chúng tôi sử dụng Seam 2.2, thứ dường như là một trình chặn lớn (không hoạt động trên các phiên bản JBoss cao hơn, không hỗ trợ JSF2). Ngoài ra, tôi thấy các nguồn bảo tôi sử dụng các tính năng JEE thay vì Seam.

Về cơ bản, tôi quan tâm đến bất kỳ cách tiếp cận chung nào cho vấn đề này, không chỉ những cách tôi đã đề cập trong các ví dụ trên - vì tôi có thể vấp phải vấn đề này cho một thư viện khác trên một hệ thống khác vào một thời điểm khác (hoặc ai đó có thể gặp phải vấn đề tương tự) .

Vì vậy, vấn đề là gì? Tôi sẽ được cập nhật và chỉ sử dụng các thư viện tiên tiến hay tôi nên ở lại với những gì tôi có? Làm thế nào để tôi nhận ra, công nghệ tôi đang sử dụng đúng là một con ngựa chết và nhảy xuống? Bao lâu thì nên nâng cấp công nghệ như vậy?

Và, một câu hỏi khác bên cạnh chung 'làm thế nào để nâng cấp' - công cụ. Làm cách nào để tôi nhận ra phần mềm của mình có thể được gọi là một phần mềm 'được chế tạo bởi các chuyên gia'?. Có một bài kiểm tra Joel cho phần mềm được thực hiện tốt bên cạnh ý nghĩa của các lập trình viên thông thường không?

Câu trả lời ngắn gọn là bạn chuyển đổi khi nỗ lực không chuyển đổi vượt quá nỗ lực chuyển đổi hoặc khi bạn có thể thấy trước rằng nó sẽ sớm trở thành như vậy. Đó là một đánh giá rất chủ quan đòi hỏi kinh nghiệm, nhưng tương đối dễ thấy các trường hợp cực đoan.

Ví dụ: giả sử bạn ước tính một tháng để chuyển đổi, nhưng không chuyển đổi nghĩa là bạn không thể sử dụng mô-đun chỉ có sẵn trong phiên bản nâng cấp, vì vậy bạn sẽ phải mất hai tháng để thực hiện một lần nữa. Sự lựa chọn là dễ dàng.

Một ví dụ khác, nếu bạn dành toàn bộ thời gian để khắc phục các lỗ hổng bảo mật trong phần mềm không còn được nhà cung cấp hỗ trợ, thì đây là thời điểm tốt để chuyển đổi.

Nếu bạn không bao giờ có cuộc họp mà ai đó nói, "Điều này sẽ tốt hơn / dễ dàng hơn với phiên bản mới", thì có lẽ bạn không cần phải chuyển đổi.

Các trường hợp ở giữa khó nhận biết hơn, nhưng nó thường có cảm giác như áp lực xây dựng, khi gắn bó với phiên bản cũ cảm thấy ngày càng hạn chế hơn.

Theo như kiểm tra phần mềm được thực hiện tốt của bạn, trình theo dõi lỗi của bạn cung cấp một quy tắc tốt về điều đó. Khi bạn không có khuyết điểm nghiêm trọng nào và danh sách các khuyết tật không nghiêm trọng của bạn ở mức hợp lý và thu hẹp dần, bạn có thể gọi nó là 'xong'. Bạn có thể hiểu được chất lượng kiến ​​trúc phần mềm của mình trước thời gian quay vòng để thêm các tính năng mới hoặc sửa lỗi. Không có điểm giới hạn nào nói rằng "điều này là chuyên nghiệp", nhưng càng thấp càng tốt.

Có một số lý do tại sao bạn có thể muốn nâng cấp cơ sở hạ tầng cơ bản của mình và bạn nên đánh giá từng cơ sở đó theo kinh nghiệm nhất có thể. Ví dụ: bạn có thể nâng cấp vì:

1. Nhà cung cấp không còn hỗ trợ phiên bản bạn đang sử dụng
2. Có một lỗi nghiêm trọng hoặc sửa lỗi bảo mật
3. Có một tính năng mới mà bạn muốn tận dụng
4. Nó sẽ tăng vận tốc của bạn
5. Có giảm chi phí capex trực tiếp trong việc nâng cấp (giấy phép hỗ trợ rẻ hơn hoặc tương tự)

Những lý do này cần phải được cân nhắc lại với chi phí nâng cấp, phần lớn được dành cho thử nghiệm. Đây là lúc TDD / BDD thực sự trở nên nổi bật, đặc biệt là khi kết hợp với thiết lập CI tốt.

Nó có nghĩa là bạn có thể "Tái cấu trúc nhanh chóng mà không sợ hãi"

Nếu bạn không có bộ kiểm tra toàn diện phù hợp, điều đó có nghĩa là bạn đang kiểm tra thủ công, việc này rất tốn thời gian và rất dễ bị lỗi, làm tăng chi phí nâng cấp.

Các công nghệ mà bạn đã liệt kê được sử dụng rộng rãi, thật dễ dàng để tìm tài liệu cho họ và những người thành thạo với chúng, vì vậy tôi nghĩ không có lý do thực sự để thay đổi chúng. Mặt khác, tôi khuyên bạn nên nâng cấp các khung công tác của mình lên các phiên bản mới nhất được phát hành. Tôi nghĩ rằng dù sao bạn cũng sẽ cần phải làm điều đó, sớm hay muộn (nếu không có các tính năng mới và khả năng tương thích với các thư viện mới hơn, sau đó là các lỗi đã được sửa trong các bản phát hành mới), và bạn càng thực hiện sớm thì nhiệm vụ này sẽ càng ít tẻ nhạt hơn.