Làm thế nào để bạn vượt qua sự thiên vị mã hóa của riêng bạn khi trao mã kế thừa? [đóng cửa]

Là lập trình viên, chúng tôi thường tự hào về kỹ năng của mình và nắm giữ những ý kiến ​​rất mạnh mẽ về mã 'tốt' và mã 'xấu' là gì.

Tại bất kỳ thời điểm nào trong sự nghiệp của chúng tôi, có lẽ chúng tôi đã có một số hệ thống kế thừa rơi vào vòng đua của chúng tôi và nghĩ rằng 'Trời ơi, mã này thật tệ!' bởi vì nó không phù hợp với quan niệm của chúng tôi về mã tốt là gì, mặc dù thực tế là nó có thể có chức năng hoàn hảo, mã có thể bảo trì.

Làm thế nào để bạn chuẩn bị tinh thần khi cố gắng tập trung vào công việc của một lập trình viên khác?

Đối với bất kỳ cơ sở mã kế thừa nào, cách chính xác để chuẩn bị tinh thần cho việc xử lý nó là bắt đầu bằng cách viết các bài kiểm tra đơn vị cho nó .

Cho dù nó có hút hay không, trước tiên bạn cần phải tự tin để có thể thay đổi nó mà không làm hỏng đồ!

Tôi không thể nói với bạn bao nhiêu lần tôi đã nói "Ồ, điều này hoàn toàn sai", viết lại nó, và sau đó tìm ra cách khó khăn tại sao mã đó được viết theo cách đó. Thông thường, đó là một số yêu cầu không rõ ràng / không có giấy tờ rõ ràng. Ít nhất, điều đó đúng trong mã kế thừa mà tôi hiện đang làm việc.

Bạn đợi cho đến khi bạn ở đây đủ lâu để chạy vào mã kế thừa tào lao của riêng bạn. Đó là một kinh nghiệm khiêm tốn và là một phần của quá trình học tập. Tôi khao khát thời gian khi tôi biết tất cả mọi thứ.

Tôi nghĩ Fosco đã có một điểm tuyệt vời để có thể đưa nó vào bối cảnh hạn chế về thời gian và chức năng. Đôi khi bạn bị buộc phải làm một cái gì đó làm việc.

Và cuối cùng, hãy hiểu rằng đây là lý do tại sao bạn có một công việc.

Cười vào nó, cố gắng không đánh giá nó quá nhiều, và chỉ cần vượt qua nó. Thật không tốt khi trở thành một code-nazi thực sự ... Chắc chắn có một thứ như 'đủ tốt' hoặc thậm chí là 'đủ tốt vào thời điểm đó'. Có nhiều lần một cái gì đó được phát triển hoặc băng bó để khắc phục khủng hoảng, sau đó không bao giờ được xem xét lại.

Nếu nó thực sự tồi tệ, hãy xem liệu bạn có thể tạo ra một trường hợp để viết lại nó không .. nếu nó không quan trọng, chỉ cần vào trong và thoát ra.

Chọn trận đấu của bạn. Biết sự khác biệt giữa "Tôi sẽ không viết theo cách này" và "điều này tạo ra một thách thức duy trì hoặc hỗ trợ nghiêm túc"

Thông thường tôi thấy nó hữu ích để có được cảm giác về những gì các nhà phát triển ban đầu nghĩ là tốt.

Tìm kiếm các mẫu và chủ đề cho những gì họ đã làm và rất nhiều lần bạn thấy rằng có những lý do cho một số quyết định kỳ lạ ở nơi đầu tiên.

Đôi khi bạn thấy rằng các nhà phát triển ban đầu thực sự là xấu, nhưng bạn có một ý tưởng về loại xấu mà họ đã bán lại sau đó.

Dù bằng cách nào, sau khi làm điều này, bạn sẽ có một bức tranh tốt hơn về nơi bạn có thể bắt đầu viết lại hoặc cách khắc phục nhanh sẽ như thế nào mà không cần phải cấu trúc lại mọi thứ.

Quan trọng nhất, đừng ngay lập tức cho rằng chỉ vì nó xấu thì nó xấu. Không có gì khiến bạn trông ngu ngốc hơn khi dành thời gian hiện đại hóa một cái gì đó chỉ để tìm ra nó ít khả năng hơn bản gốc.

Nếu tôi có thời gian, tôi sẽ tấn công nó và giết mã được viết kém.

Đó là chiến tranh.

Tôi luôn lý giải rằng mã xấu là mã đã thấy nhiều lỗi, với nhiều sự tinh tế không rõ ràng với việc kiểm tra chữ thảo. Nếu tôi thay thế nó, hoặc thiết kế lại sâu sắc, tôi cần đảm bảo rằng tôi hiểu hoàn toàn mọi khía cạnh của những gì mã làm. Nếu tôi không có thời gian để chạm đáy, tôi phải thực hiện một cách tiếp cận rủi ro tối thiểu, thực hiện thay đổi nhỏ nhất có thể để đạt được mục tiêu của mình.

Thông thường tôi sẽ thực hiện một sửa chữa / thay đổi nhỏ và đề xuất một tính năng cho sự phát triển sau này có thể loại trừ việc đi đến tận cùng của mọi thứ và tái cấu trúc toàn bộ. Sau đó, tôi làm hết sức để bỏ qua mã cho đến khi tính năng kết thúc trên lộ trình.

Khi mã kế thừa hơn một vài năm tuổi, nó có thể đã được viết theo cách đó vì những hạn chế trong ngôn ngữ hoặc hệ điều hành, v.v. tồn tại vào thời điểm mã được viết. Bây giờ nó trông tệ nhưng nó có tệ không? Tôi cố gắng giả định rằng nhà phát triển có lý do cho những gì anh ta hoặc cô ta đã làm. Lý do đó có thể không còn được áp dụng nhưng giả sử có một thay vì chỉ là sự bất tài chung (các lập trình viên trẻ sẽ nghĩ điều tương tự về mã của bạn trong 5 năm thậm chí có thể ít hơn) khiến bạn bớt tức giận về điều đó. Nếu nó hoạt động và không có vấn đề gì liên quan đến nó, hãy trân trọng mã kế thừa đó, dù xấu đến đâu, vì nó sẽ cho phép bạn giải quyết các vấn đề thú vị hơn.

Trước đây khi tôi không có thời gian để chọc tức mã của người khác và đánh nó theo kiểu "của tôi", tôi đã phải dùng đến việc rất có nhiệm vụ:

Tôi đang cố gắng thêm gì vào mã này / sửa chữa / thực hiện công việc?

Là những gì tôi đang làm việc hướng tới mục tiêu đó? Nếu không, hãy dừng việc đó lại và quay lại lần cuối cùng tôi thực hiện các thay đổi theo định hướng nhiệm vụ.

Tôi đã làm xong với nhiệm vụ này chưa? Nếu vậy, hãy ngừng mày mò mã, mặc dù có vẻ như nó được viết bởi khuôn sao Hỏa không có tình cảm.

Trừ khi bạn chuẩn bị sở hữu mã và mọi sửa lỗi cần thiết trong tương lai, đừng chạm vào nó. Bạn sẽ khắc phục xu hướng muốn sửa một cái gì đó khi bạn phá vỡ thứ gì đó bạn không viết bởi vì bạn đã không nghiên cứu nó đủ tốt trước khi bạn tham gia, và bạn phải mất 2 ngày và một mũi khoan lửa để làm cho nó hoạt động trở lại .

Đừng hiểu sai ý tôi ... có những lý do chính đáng để cấu trúc lại mã, nhưng nếu một doanh nghiệp yêu cầu mã đó hoạt động và bạn "sửa" nó mà không biết hậu quả trước khi nhảy vào, bạn đang yêu cầu một thế giới bị tổn thương .

Tái cấu trúc một chút tại một thời điểm có thể hữu ích, nhưng hãy cẩn thận hơn về việc thay đổi bất kỳ khía cạnh nhỏ nào về cách mã thực sự hoạt động trừ khi bạn hiểu tại sao hành vi đó ở đó và những gì nó ảnh hưởng. Thật không may, mã cần nó tệ nhất đôi khi là khó thay đổi nhất mà không chạm vào hành vi, mặc dù bạn thường có thể làm thẳng ra các phần của nó, hoặc ít nhất là nhận xét nó.

Tôi đang làm việc gần như độc quyền về mã kế thừa những ngày này và tôi luôn nghĩ rằng "Oh sh% t, họ đã nghĩ gì?" . Sau đó, tôi bắt đầu viết các bài kiểm tra đơn vị cho mã và đó là điểm mà tôi thực sự phải phân tích luồng điều khiển và các phụ thuộc.

Đôi khi không thể dễ dàng viết bài kiểm tra đơn vị. Nhưng trong khi tôi cố gắng, tôi nhận được thông tin về mã và sẽ hiểu lý do tại sao nó được viết theo cách đó. Đôi khi điều đó sẽ chứng minh rằng mã thực sự là một mớ hỗn độn, đôi khi tôi hiểu được quá trình suy nghĩ của các nhà phát triển ban đầu và có thể thêm tài liệu hữu ích hoặc viết lại một đoạn mã khi tôi muốn thêm chức năng mới.

Đối với tôi, điều đó giúp tôi nghĩ rằng mã của tôi sẽ giống với chính tôi khi tôi quay lại mã đó sau 12 tháng .

Với kinh nghiệm đi kèm phán đoán để biết khi nào mã thực sự xấu, và khi nó chỉ được viết theo một phong cách khác. Nếu nó hoàn hảo về chức năng và có thể bảo trì và có phạm vi kiểm tra tự động tốt , thì nó không tệ và bạn chỉ cần mở mang đầu óc. Bạn có thể sẽ học được điều gì đó. Mã xấu không có chức năng và có thể bảo trì.

Dưới đây là một số đánh dấu của mã thực sự xấu:

• Các khối logic lớn đã được nhân đôi thay vì tái cấu trúc.
• Phụ thuộc tròn giữa các lớp hoặc gói
• Khớp nối cao; độ kết dính thấp
• Các biến không được sử dụng, ghi vào các biến không bao giờ được đọc, mã không thể truy cập.
• Thực hiện lại các chức năng thư viện tiêu chuẩn, ví dụ định dạng ngày.
• Logic phức tạp không cần thiết; tức là 50 dòng mã trong đó 10 sẽ làm tốt.
• Không có ý kiến ​​mô tả mục đích của các lớp học hoặc phương pháp.
• Nhận xét sai lệch.

Việc thiếu các bài kiểm tra tự động không có nghĩa là mã này xấu, nhưng điều đó có nghĩa là dự án rất tệ.

Đây không phải là một vấn đề của hương vị; những thực hành này làm cho bảo trì chương trình đắt hơn nhiều.

Làm thế nào để bạn chuẩn bị cho mình?

Chấp nhận thực tế là phải mất một thời gian để có thể làm việc thành công trên cơ sở mã mới. Nếu nó "hoàn toàn có thể duy trì" và có độ bao phủ thử nghiệm cao, sẽ mất ít thời gian hơn nhưng nó vẫn không xảy ra ngay lập tức. Nếu mã xấu, thì điều đầu tiên tôi làm là cảnh báo các bên liên quan rằng nó ở dạng xấu và tiến độ ban đầu sẽ chậm. Nếu họ nghi ngờ, thì tôi sẽ sao lưu yêu cầu của mình bằng cách chỉ cho họ một mẫu các vấn đề trong mã thực tế và giải thích cách nó thay đổi so với thực tiễn tốt nhất trong ngành.