Mã kế thừa là gì và cách làm việc với nó
Nguồn: Dou Sớm hay muộn, một lập trình viên có thể sẽ phải gặp phải những đoạn code kế thừa. Để giảm bớt hậu quả của việc làm quen này, tôi đã chọn một số mẹo và ví dụ thực tế từ kinh nghiệm của bản thân - đặc biệt là làm việc với hệ thống Java cũ.Tính năng kế thừa
Di sản là mã của người khác, thường khủng khiếp đến mức thường không rõ cách làm việc với nó. Và nếu bạn phải làm việc với một hệ thống cũ, ngoài mã cũ, bạn cũng sẽ gặp phải:- với công nghệ lạc hậu;
- kiến trúc không đồng nhất;
- thiếu hoặc thậm chí thiếu hoàn toàn tài liệu.
-
Chúng ta không thể thiếu tôn trọng một hệ thống kiếm được hàng triệu đô la hoặc được hàng nghìn người truy cập mỗi ngày. Cho dù nó được viết kém đến đâu, đoạn mã kinh tởm này vẫn tồn tại và hoạt động 24/7.
-
Vì hệ thống này mang lại tiền thật nên làm việc với nó đi kèm với trách nhiệm rất lớn. Đây không phải là một công việc khởi nghiệp mà là thứ mà người dùng sẽ làm việc vào ngày mai. Điều này cũng hàm ý chi phí sai sót rất cao và vấn đề ở đây không nằm ở khiếu nại của khách hàng mà nằm ở tình hình thực tế của sự việc.
Kỹ thuật đảo ngược
Để làm việc thành công với mã kế thừa, bạn sẽ phải sử dụng các kỹ thuật thiết kế ngược. Đầu tiên, bạn cần đọc kỹ code để hiểu chính xác cách thức hoạt động của nó. Điều này là bắt buộc vì rất có thể chúng tôi sẽ không có tài liệu. Nếu không hiểu rõ dòng suy nghĩ của tác giả, chúng ta sẽ thay đổi với những hậu quả khó lường. Để bảo vệ bản thân khỏi điều này, bạn cũng cần đi sâu vào mã liền kề. Và đồng thời di chuyển không chỉ theo chiều rộng mà còn theo chiều sâu. Phương thức được gọi có lỗi ở đâu? Mã gọi nó đến từ đâu? Trong một dự án cũ, "phân cấp cuộc gọi" và "phân cấp loại" được sử dụng thường xuyên hơn bất kỳ điều gì khác. Bạn sẽ phải dành nhiều thời gian với trình gỡ lỗi: thứ nhất là tìm lỗi và thứ hai là hiểu cách mọi thứ hoạt động. Về tài liệu, sẽ không phải là một ý tưởng tồi nếu sử dụng khảo cổ học công nghiệp. Sẽ rất hữu ích nếu bạn tìm lại tài liệu cũ ở đâu đó và nói chuyện với những người nhớ cách viết mã mà bạn kế thừa. Sử dụng những kỹ thuật này, sớm hay muộn bạn sẽ bắt đầu hiểu được mã ít nhiều. Nhưng để tránh lãng phí những nỗ lực của mình, bạn phải ghi lại ngay kết quả nghiên cứu của mình. Để làm điều này, tôi khuyên bạn nên vẽ sơ đồ khối hoặc sơ đồ trình tự. Tất nhiên, bạn sẽ lười biếng, nhưng bạn chắc chắn cần phải làm điều này, nếu không, trong sáu tháng không có tài liệu, bạn sẽ tìm hiểu kỹ mã này giống như lần đầu tiên.
Đừng viết lại mã
Điều quan trọng nhất trong quá trình phát triển là cố gắng đúng giờ và không cố gắng viết lại toàn bộ mã từ đầu. Hãy ước tính việc này sẽ cần bao nhiêu năm công. Không chắc rằng khách hàng sẽ muốn chi nhiều tiền như vậy để làm lại một thứ đã hoạt động tốt. Điều này không chỉ áp dụng cho toàn bộ hệ thống mà còn cho bất kỳ phần nào của nó. Tất nhiên, họ có thể cho bạn một tuần để tìm hiểu mọi thứ và một tuần nữa để khắc phục điều gì đó. Nhưng họ khó có thể cho bạn hai tháng để viết lại một phần hệ thống. Thay vào đó, hãy triển khai chức năng mới theo cùng kiểu với phần còn lại của mã. Nói cách khác, nếu mã đã cũ, bạn không nên cố gắng sử dụng các công nghệ mới đẹp đẽ: khi đó mã như vậy sẽ rất khó đọc. Ví dụ: bạn có thể gặp phải tình huống như chúng tôi đã gặp: một phần của hệ thống được viết bằng Spring MVC và một phần được viết bằng các servlet trần. Và nếu trong một phần được viết bằng servlet, cần thêm một thứ gì đó khác, thì chúng ta thêm nó theo cách tương tự - trong servlet.Tôn trọng lợi ích doanh nghiệp
Cần phải nhớ rằng bất kỳ nhiệm vụ nào trước hết đều được xác định theo giá trị đối với doanh nghiệp. Nếu bạn không chứng minh cho khách hàng thấy sự cần thiết của những thay đổi nhất định theo quan điểm kinh doanh thì những thay đổi này sẽ không xảy ra. Và để thuyết phục được khách hàng, bạn phải cố gắng đứng vào vị trí của họ và hiểu được sở thích của họ. Đặc biệt, nếu bạn muốn refactor chỉ vì code khó đọc thì bạn sẽ không được phép làm điều đó và phải sống chung với nó. Nếu thực sự không thể chịu đựng được, bạn có thể sắp xếp lại mã một cách lặng lẽ và từng chút một, dàn trải công việc trên các phiếu công việc. Hoặc thuyết phục khách hàng rằng điều này chẳng hạn sẽ giảm thời gian cần thiết để tìm ra lỗi và do đó cuối cùng sẽ giảm chi phí.Bài kiểm tra
Rõ ràng rằng thử nghiệm là cần thiết trong bất kỳ dự án nào. Nhưng khi làm việc với các hệ thống cũ, cũng phải đặc biệt chú ý đến việc thử nghiệm vì tác động của những thay đổi được thực hiện không phải lúc nào cũng có thể dự đoán được. Bạn sẽ cần ít nhất nhiều người thử nghiệm như nhà phát triển, nếu không thì bạn phải cực kỳ giỏi về tự động hóa. Trong dự án của chúng tôi, thử nghiệm bao gồm các giai đoạn sau:- Xác minh, khi chức năng triển khai của một tính năng được kiểm tra trong một nhánh riêng biệt.
- Ổn định, khi một nhánh phát hành được kiểm tra trong đó tất cả các tính năng được hợp nhất với nhau.
- Chứng nhận, khi điều tương tự được chạy lại trên các trường hợp thử nghiệm hơi khác nhau trong môi trường chứng nhận gần nhất có thể với môi trường sản xuất về đặc điểm và cấu hình phần cứng.
Chính thức hóa DevOps và phát hành
Ví dụ, quy trình phát hành có thể như sau. Khi quá trình phát triển hoàn tất và hai hoặc ba giai đoạn thử nghiệm đã hoàn thành, chúng tôi sẽ viết email cho nhóm DevOps 36 giờ trước thời gian phát hành dự kiến. Sau đó, chúng tôi gọi cho nhóm phát triển và thảo luận về tất cả các thay đổi đối với môi trường (chúng tôi thông báo cho họ về tất cả các thay đổi trong cơ sở dữ liệu và cấu hình). Đối với mỗi thay đổi, chúng tôi có một tài liệu (một vé trong Jira). Sau đó, trong quá trình phát hành, tất cả những người tham gia vào việc này tập hợp lại và mọi người nói những gì họ đang làm: “Chúng tôi đã tải lên cơ sở dữ liệu”, “Chúng tôi đã khởi động lại các máy chủ như vậy”, “Chúng tôi đã chạy thử nghiệm hồi quy trong môi trường sản xuất. ” Nếu có sự cố xảy ra, quy trình khôi phục bản phát hành sẽ được triển khai, được mô tả chính xác trong tài liệu phát hành gốc - nếu không có tài liệu như vậy, chúng tôi chắc chắn sẽ quên điều gì đó hoặc nhầm lẫn.Kiểm soát chất lượng mã
Và cuối cùng, xem xét mã là một phương pháp mà vì lý do nào đó không được sử dụng trong tất cả các dự án. Thật tuyệt nếu mỗi đoạn mã được nhiều người xem xét. Ngay cả trong một nhóm rất mạnh, một số lỗi luôn được phát hiện trong quá trình xem xét mã và nếu nhiều người xem xét nó, số lượng lỗi được xác định sẽ tăng lên. Hơn nữa, đôi khi người đánh giá thứ ba hoặc thứ tư lại phát hiện ra điều tồi tệ nhất.Công cụ giúp viết tài liệu kỹ thuật dễ dàng hơn
Nguồn: Dzone Hầu hết các lập trình viên đều không thích viết tài liệu kỹ thuật. Chuyên gia tâm lý Gerald Weinberg thậm chí còn gọi tài liệu là “dầu thầu dầu của lập trình”: các nhà phát triển thích đọc nó nhưng đơn giản là họ ghét việc tự viết nó.
Việc thiếu hướng dẫn hoặc lộ trình trống sẽ dẫn đến thiếu thông tin về cách thức hoạt động của các phần khác nhau của phần mềm. Điều này cuối cùng làm xấu đi trải nghiệm của người dùng cuối về mã vì nếu không có tài liệu, họ không thể dựa vào tính chính xác và hữu ích của sản phẩm. Để giúp các lập trình viên hình thành thói quen viết tài liệu dễ dàng hơn, tôi khuyên bạn nên chú ý đến bốn công cụ tuyệt vời hiện có sẵn cho hầu hết mọi người.
GO TO FULL VERSION