Trong nghề của chúng tôi, việc làm việc trên một cơ sở mã không quen thuộc là điều bình thường. Nó xảy ra mỗi khi một người tham gia một dự án mới hoặc thậm chí cần phải làm việc trên một phần chưa được xử lý trước đó trong những dự án lớn.  Sự cố này không chỉ giới hạn ở việc nhà phát triển phải sửa lỗi; đó có thể là một kiến trúc sư giải pháp phải thiết kế một tính năng mới hoặc một cộng tác viên OpenSource đang giải quyết vấn đề GitHub trong thời gian rảnh của họ. Do đó, tôi muốn mô tả cách tôi tiếp cận tình huống để nó có thể mang lại lợi ích cho người khác.  Một vấn đề ví dụ  Để minh họa quan điểm của mình, tôi sẽ sử dụng một vấn đề phổ biến của GitHub yêu cầu một tính năng mới trên một dự án Nguồn mở.  Khi làm việc cho Hazelcast, tôi thường xuyên xem qua cái gọi là "các vấn đề đầu tiên tốt" để giải quyết tại hackathons. Tôi chưa bao giờ có thể chạy một cuộc thi hackathon như vậy, nhưng điều đó không quan trọng. Ý tưởng của tôi là giúp những người quan tâm đến việc đóng góp cho Nguồn mở bắt đầu làm quen với cơ sở mã.  Vào thời điểm đó, tôi thấy vấn đề thú vị này:  Thêm hỗ trợ cho thao tác getQuiet   ? http://ehcache.org/apidocs/net/sf/ehcache/Cache.html#getQuiet(java.lang.Object)  Ý tưởng là có thể lấy một mục mà không cần chạm vào nó, nghĩa là nó sẽ không cập nhật dấu thời gian truy cập cuối cùng.  Trường hợp sử dụng đằng sau nó là có thể giám sát sự tồn tại của một khóa mà không thay đổi việc loại bỏ khóa đó.  --  Bản đồ phân tán: Thêm hỗ trợ cho thao tác getQuiet  Với tư cách là người đóng góp cho OpenSource, tôi sẽ tiếp cận công việc như thế nào?  Sơ đồ là chìa khóa  Lập tài liệu là bước đầu tiên để bắt tay vào một dự án mới. Trong một dự án thông thường, tài liệu có thể bị thiếu, không đầy đủ hoặc một phần (nếu không muốn nói là hoàn toàn) gây hiểu lầm; tại một cuộc thi hackathon, thời gian có thể quá ngắn để đọc nó một cách chi tiết.  Các dự án Nguồn mở thành công nói chung có tài liệu tốt. Tuy nhiên, tài liệu chủ yếu hướng tới người dùng, hiếm khi hướng tới nhà phát triển. Ngay cả khi đúng như vậy, khả năng tài liệu giải quyết được vấn đề là rất thấp.  Vì lý do này, mục nhập của tôi là vẽ một sơ đồ. Lưu ý rằng mặc dù một số công cụ có thể đảo ngược mã kỹ sư và vẽ sơ đồ tự động, nhưng tôi không cố ý sử dụng chúng. Vẽ sơ đồ theo cách thủ công có nhiều lợi ích hơn so với sơ đồ được tạo tự động:  Nó tập trung vào các khu vực của mã có liên quan đến vấn đề hiện tại.  Nó buộc người ký phát phải đọc và hiểu mã, đó là nguồn sự thật duy nhất.  Nó xây dựng mô hình mã tinh thần của chúng tôi.  Nó ghi lại những phát hiện của chúng tôi để có thể truy cập sau này. Tuy nhiên, lưu ý rằng giá trị tài liệu giảm dần theo thời gian khi mã cơ bản phát triển và cả hai phần.  Hãy tạo một sơ đồ cho mã cho vấn đề này. Đầu tiên, chúng tôi sẽ sao chép cục bộ repo để mở nó trong IDE yêu thích của chúng tôi; tính năng bắt buộc duy nhất là khi một lần nhấp vào lệnh gọi phương thức, người ta sẽ được chuyển hướng đến phương thức đó.  Đối với bản thân sơ đồ, hãy gọi tôi là lỗi thời, nhưng tôi vẫn thích   vì hai lý do: sơ đồ tuần tự UML  Tôi có một số kinh nghiệm với họ.  Ngữ nghĩa không phải là   nhưng được chia sẻ giữa những người biết UML, ở một mức độ nào đó. đặc biệt  Không có gì khó chịu, đây là:   Sau khi vẽ sơ đồ, chúng ta có thể xác định khá nhanh vấn đề nằm ở đâu:   public abstract class AbstractCacheRecordStore<R extends CacheRecord, CRM extends SampleableCacheRecordMap<Data, R>> implements ICacheRecordStore, EvictionListener<Data, R> { protected long onRecordAccess(Data key, R record, ExpiryPolicy expiryPolicy, long now) { record.setAccessTime(now); // 1 record.incrementAccessHit(); return updateAccessDuration(key, record, expiryPolicy, now); } //... }    đọc   , điều này sẽ kích hoạt cập nhật lần truy cập cuối cùng. DefaultRecordStore Record  Khắc phục sự cố nằm ngoài phạm vi của bài đăng này. Nó liên quan đến việc nói chuyện với những người quen thuộc hơn với thiết kế tổng thể để phát triển giải pháp tốt nhất. Một cách tiếp cận tốt trong hackathon trước tiên là đưa ra ít nhất hai lựa chọn thay thế và ghi lại sự đánh đổi tương ứng của chúng.  Đối với công cụ, có rất nhiều lựa chọn thay thế. Tùy chọn của tôi đi đến   : PlantUML  Nó cung cấp một   và một  ứng dụng web Docker container  Nó tạo ra hình ảnh SVG hoặc PNG  Nó có thể lột da  Đó là mã nguồn mở và miễn phí  Nó được duy trì thường xuyên  Phần kết luận  Hiểu một cơ sở mã hiện có là một kỹ năng quan trọng bất kể vai trò kỹ thuật chính xác của một người. Việc tạo sơ đồ sẽ giúp bạn đạt được mục tiêu này trong một chặng đường dài, với lợi ích bổ sung của tài liệu.  Tôi thích sơ đồ UML vì tôi quen thuộc với chúng và chúng cung cấp ngữ nghĩa được chia sẻ.  Do đó, nếu bạn muốn hiểu rõ hơn về cơ sở mã, bạn cần nhiều hơn là chỉ đọc mã của nó; bạn cần vẽ sơ đồ.   Được xuất bản lần đầu tại   vào ngày 14 tháng 5 năm 2023 A Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Nghe bài viết này bằng Tiếng Anh, đọc bởi robot thông minh của HackerNoon

dài quá đọc không nổi

Make resilience your competitive advantage

Cách làm việc trên một Codebase không quen thuộc

About Author

BÌNH LUẬN

chuyên mục

BÀI VIẾT NÀY CŨNG CÓ MẶT TẠI

Related Stories

72 Stories To Learn About Adam Smith

85 Stories To Learn About Travel

85 Stories To Learn About Productivity Hacks

178 Stories To Learn About Essay

72 Stories To Learn About Adam Smith

85 Stories To Learn About Travel

85 Stories To Learn About Productivity Hacks

178 Stories To Learn About Essay

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps