Làm thế nào để bạn đối phó với việc hiểu trừu tượng trong mã?

Khi nhìn vào một cơ sở mã mới, tôi muốn bắt đầu từ cách tiếp cận từ dưới lên.
Nơi tôi hiểu một tập tin và sau đó chuyển sang phần trừu tượng tiếp theo.
Nhưng nhiều khi tôi thấy mình quên mất những gì trừu tượng cấp thấp hơn đang làm.

Vì vậy, tôi sẽ ở thời điểm này, nơi tôi thấy mình trong một vòng lặp gần như vô tận để quay trở lại các tệp mà trước đây tôi đã hiểu đầy đủ, và sau đó cố gắng tìm hiểu lại chúng; trong khi cố gắng tung hứng nhiều thứ trừu tượng khác kết nối với nhau trong đầu tôi.

Có một chiến lược tốt hơn để đối phó với tình huống này?

Tôi có nên quên đi những chi tiết cấp thấp hơn và coi chúng là một thứ nhất định không? Nhưng ngay cả khi đó, nhiều lần một sự hiểu biết trước đây về sự trừu tượng ở mức độ thấp hơn là cần thiết để hiểu sự trừu tượng hiện tại đang làm gì.

Lập trình cụ thể là sự thúc đẩy để kéo các chi tiết về phía bạn để bạn có thể đóng đinh tất cả chúng ở một nơi. Tất cả chúng ta đều bắt đầu theo cách này và thật khó để từ bỏ.

Lập trình một cách trừu tượng chắc chắn là "quên về các chi tiết cấp thấp hơn". Đôi khi thậm chí chi tiết cấp cao. Bạn đẩy chi tiết đi và để một cái gì đó khác đối phó với chúng. Điều lén lút là bạn đã làm điều này suốt. Bạn có thực sự hiểu những gì tất cả xảy ra giữa print "Hello world"và nó hiển thị trên màn hình của bạn?

Điều số một để yêu cầu khi bạn đấu tranh để từ bỏ những chi tiết này là tên tốt. Một cái tên hay đảm bảo bạn sẽ không ngạc nhiên khi nhìn vào bên trong. Đây là lý do tại sao bạn không ngạc nhiên khi printđặt một cái gì đó lên màn hình của bạn và không thực sự quan tâm làm thế nào. foo "Hello world"sẽ là một câu chuyện khác nhau.

Ngoài ra, mức độ trừu tượng nên nhất quán. Nếu bạn ở cấp độ tính toán số pi, bạn cũng không nên lo lắng về cách hiển thị số pi. Chi tiết đó đã bị rò rỉ thành một sự trừu tượng nơi nó không thuộc về.

Thấp hơn, cao hơn hoặc đi ngang, các chi tiết, không phải là về một điều tôi đang nghĩ về ở nơi này, có thể biến mất hoàn toàn hoặc ít nhất là ẩn đằng sau một cái tên hay.

Vì vậy, nếu bạn thực sự gặp khó khăn khi chuyển từ tập tin này sang tập tin khác, tôi sẽ đặt ra một số người mắc kẹt với tên xấu hoặc trừu tượng bị rò rỉ.

Tôi sửa nó bằng cách đọc bằng ngón tay. Khi tôi có những bài kiểm tra tốt xung quanh mớ hỗn độn này, tôi trêu chọc các trách nhiệm, đặt cho chúng những cái tên rõ ràng để tránh những điều bất ngờ và đưa nó cho người khác để chắc chắn rằng tôi không sống trong một thế giới giả tưởng.

Rõ ràng tôi không đơn độc khi làm việc theo cách này:

Bất cứ khi nào tôi làm việc với mã không quen thuộc, tôi bắt đầu trích xuất các phương thức. Khi tôi làm điều này, tôi tìm các đoạn mã mà tôi có thể đặt tên - sau đó tôi trích xuất. Ngay cả khi tôi kết thúc nội tuyến các phương pháp tôi đã trích xuất sau này, ít nhất tôi cũng có cách ẩn chi tiết tạm thời để tôi có thể thấy cấu trúc tổng thể.

Michael Feathers - Mã cam

Ở phía dưới, có một số cập nhật về cách điều này đối với tôi mỗi quý một năm hoặc lâu hơn, tôi nghĩ chúng có giá trị.

Đặt tên tốt. Hoặc, nếu đó là mã của người khác, cố gắng gán các tên / trách nhiệm tốt dựa trên các tên thậm chí xấu trên các lớp / hàm của hệ thống đó để nó có ý nghĩa trong đầu tôi. Một khi nó được thực hiện, việc thực hiện cấp thấp trở nên dễ nhớ hơn.

Đó là tất cả những gì tôi có. Có rất nhiều người theo chủ nghĩa thuần túy trên trang web này, những người sẽ thề - bởi chúa - biết những kiểu hoặc đối tượng thuộc loại nào, nhưng việc đặt tên tốt sẽ giúp bạn tiến xa. Tôi đã tự mình làm tốt hơn bằng cách tạo ra mã được tách rời tối thiểu / được đặt tên tốt / được tách riêng và nó không bao giờ quay lại cắn tôi, ngay cả khi mã của tôi được sử dụng ở nhiều nơi, bởi nhiều người, nhưng một điều tôi đã làm đúng là lãng phí rất nhiều thời gian vào việc đặt tên tốt, bình luận tốt và sơ đồ giải thích dòng mã của tôi. Việc triển khai ở mức độ thấp là cần thiết để hiểu nếu bạn muốn mở rộng mã của tôi một cách sâu sắc. Mã được viết tốt có thể được mở rộng theo những cách hợp lý, vì vậy, sẽ ổn nếu ai đó hoặc bạn không hiểu / không nhớ các triển khai cấp thấp.

Nếu bạn quan tâm đến một chút tranh cãi rằng những người trong lĩnh vực ban đầu của tôi cũng như tôi biết là sự thật, nhưng, nếu bạn lắng nghe những gì được viết ra ở đây, bạn sẽ học cách đồng ý và không đồng ý với câu trả lời này , đọc tiếp:

Nhưng có một vấn đề khác trong tầm tay - những người theo chủ nghĩa thuần túy. Bạn sẽ nghe những câu trả lời và ý thức hệ tốt, hợp lý và hoàn toàn hợp lý, trên thực tế, không có gì sai với chúng. Nhưng bạn không cần phải theo dõi họ, thực tế, họ có thể đang chơi vào nhược điểm của bạn.

Bạn bè của tôi đã làm việc với các hệ thống lớn và họ chỉ cười nhạo những người quan tâm quá nhiều đến các quy ước và mô hình và vì lý do chính đáng, tôi cũng làm điều đó - Tôi có thể tìm thấy lý do của mình cho việc này từ lĩnh vực phân tích dữ liệu chính của tôi, vì tôi không phải là một nhà phát triển có kinh nghiệm: Hầu hết những điều bạn nghĩ là quan trọng, không quan trọng và có một mối tương quan mạnh mẽ với cái tôi của bạn theo nghĩa này.Thông thường, một cá nhân, do bản ngã của anh ta, sẽ có được kiến ​​thức mà anh ta rất có thể bị hiểu lầm do những thành kiến ​​của anh ta hiện đang được tái thẩm quyền bởi một cơ quan mà anh ta nghĩ chỉ nói "điều tương tự tôi đã làm". Đây là một cái bẫy rất nổi tiếng mà bạn không bao giờ nên rơi vào. Điều này không có nghĩa là anh ta không sử dụng nó đúng cách hoặc vì lợi ích lớn hơn, nhưng thường thì những gì những người này sẽ làm là hứa rằng bất cứ điều gì họ nói là giải thưởng vàng.

vậy, bạn có thể làm gì?

Giải thích mã của bạn cho đồng nghiệp và hỏi họ nếu nó có ý nghĩa từ quan điểm cấp cao.

Đó là tất cả những gì quan trọng. Tất nhiên bất cứ ai đang đọc mã của người khác sẽ luôn có một fiesta tab alt để xem triển khai một số thứ nhất định, nhưng điều đó không quan trọng, nếu bất cứ ai đọc mã của bạn đều hiểu hệ thống của bạn và hiểu "tại sao mọi việc xảy ra "(Một lần nữa, mà không nhất thiết phải biết, đầy đủ" cách chúng xảy ra "), thì bạn là vàng.

Đây không phải là tôi nói hãy tiếp tục và viết mã tào lao không phải là biểu diễn hoặc không tôn trọng bất cứ điều gì, nhưng điều tôi đang nói là:

1) Không sao để quên. Trong thời gian, bạn sẽ trở nên tốt hơn trong việc đọc mã bạn đang làm việc. Nếu mã bạn đang đọc yêu cầu bạn biết các triển khai cấp thấp ở mức tốt, thì mã đó được viết sai và nó đóng vai trò như những gì tôi đã nói trước đây: đồng nghiệp có hiểu bạn không?

2) Thế giới đầy rẫy những người rất thông minh, những người không thông minh lắm. Họ cũng thường rất tình cảm và họ có xu hướng thiên vị - củng cố từ các lực lượng bên ngoài. Họ rất giỏi trong những gì họ làm, nhưng những gì họ, khi các tác nhân truyền bá thông tin quên là: ý tưởng / thông tin, ngay cả khi được hỗ trợ bởi "logic" có bối cảnh của người gửi chúng, điều rất quan trọng trong việc hiểu liệu điều đó có hay không thông tin cũng hữu ích cho bạn Điều gì có ý nghĩa đối với bạn có thể có ý nghĩa đối với người khác và họ sẽ thích nó nhưng thông tin không nên được coi là tuyệt đối và một lần nữa, nên xem xét, hoặc ít nhất là cố gắng tìm ra bối cảnh nơi nó đến và kiểm tra lại bối cảnh riêng để xem nếu nó phù hợp. Nó thực sự giống như các tỷ phú cho chúng ta những "kiến thức để đi trước"

Tóm lại: viết mã đó là điều dễ hiểu và nhận ra rằng nó vẫn còn gây tranh cãi khi chúng ta cần nhiều mẫu / lớp và nhà máy lọc dầu như một số người nói. Có những người rất thông minh ở cả hai phía của cuộc tranh luận và điều đó chỉ nên củng cố ý tưởng làm bất cứ việc gì cho nhóm của bạn một cách hợp lý - đừng bị mắc kẹt vào những chi tiết nhỏ không quan trọng, bạn sẽ hiểu họ sau này, hãy nhớ rằng, bạn sống trong một thế giới cực kỳ cạnh tranh trong đó thời gian là điều quan trọng nhất:

Thời gian trong khởi nghiệp thành công.

Phân bổ thời gian và tài nguyên của bạn một cách có ý nghĩa, tham lam.

Đây là bản chỉnh sửa, 6 tháng sau:

Đó là một hành trình điên rồ. Tôi chưa bao giờ nghĩ rằng chỉ cần tách / đặt tên và tài liệu tốt về cơ bản có thể cho phép bạn cắm bất cứ thứ gì vào và ra khỏi cơ sở mã của bạn. Tôi đã phải viết lại rất nhiều mã để tăng tốc độ với những thay đổi mới và tôi đã thực hiện một đoạn tốt trong 2-3 ngày. Tôi có thể nói một cách an toàn rằng tôi đã không theo dõi RẮN ở mọi nơi do thiếu kiến ​​thức, cũng không phải thực hành tốt nhất và tôi có thể nói rằng họ đang mắc nợ kỹ thuật, nhưng không nhiều. Riêng biệt, tên và tài liệu, nó sẽ cho phép bạn thay đổi mã ngay lập tức khi cuối cùng bạn nhận ra bạn đã câm như thế nào.

Đừng hiểu lầm tôi: nếu bạn viết mã của mình được ghép chặt chẽ, bạn sẽ gặp rất nhiều đau đớn, cho dù bạn có ghét RẮN hay không, thậm chí hiểu và áp dụng nó ở cấp độ cơ sở cho phép tách rời một cách trung thực, điều đó, thật lòng, là điều duy nhất mà OOP thực sự giúp với. OOP được cho là cũng sử dụng lại mã và trong khi điều đó xảy ra ở đây và ở đó, bạn không thực sự sử dụng lại nhiều đối tượng bạn tạo, vì vậy, hãy tập trung vào việc đảm bảo hệ thống của bạn được phân tách tốt. Khi bạn đạt đến độ chín muồi và giả sử chú Bob đến và dẫn dắt dự án của bạn, anh ấy sẽ nói "Ok, điều này thật ngu ngốc nhưng ít nhất mọi thứ đều tách biệt, được đặt tên và ghi lại để ít nhất tôi biết tất cả những điều này là gì " (Tôi hi vọng). Đối với tôi, nó hoạt động. LỘC của tôi liên tục thay đổi, nhưng tại thời điểm viết, đó là 110k dòng mã, 110k dòng mã thực hiện hoạt động hài hòa cho một người là rất nhiều.

Đây là bản chỉnh sửa, 3 tháng sau, với mã 8 tháng tôi đang tái cấu trúc:

Tất cả đều có lý. Bây giờ tôi có thể lấy những gì tôi đã viết lại sau đó, về mặt khái niệm và giới thiệu lại mã, với những ý tưởng mới bởi vì tôi hoàn toàn hiểu những gì đang diễn ra và tại sao nó hoạt động vì sơ đồ / đặt tên và nhận xét tốt. Tôi đã viết một số mã từ lâu rằng tôi không quan tâm đến việc đặt tên tốt và như vậy và đó là nỗi đau phải trải qua. Bây giờ tôi đang nghĩ bước tiếp theo để giải thích mã của tôi có thể là gì.