Làm thế nào tôi có thể trở nên tốt hơn trong việc giải thích mã cho các nhà phát triển khác? [đóng cửa]

Trong khi bản thân câu hỏi nghe có vẻ ngớ ngẩn, câu trả lời khá quan trọng đối với tôi, vì tôi cảm thấy vấn đề đó ảnh hưởng tiêu cực đến hiệu suất công việc của tôi.

Một chút nền tảng ở đây: Tôi là một nhà phát triển phần mềm cao cấp dày dạn trong một bộ phận phần mềm cỡ trung bình của công ty phi phần mềm. Mặc dù ở trên mức trung bình về mặt kỹ thuật của mọi thứ, tôi lại kém hơn nhiều trong việc giao tiếp và giải thích mọi thứ. Ngay cả khi giải thích một cái gì đó cho các nhà phát triển khác.

Những khó khăn nhất xảy ra khi tôi giải thích cách một đoạn mã nhỏ cụ thể hoạt động.

Điều buồn cười là, việc giải thích và cung cấp các ví dụ về cách một thứ gì đó hoạt động ở mức cao hơn nhiều, ví dụ như sự tương tác giữa các mô-đun và hệ thống con riêng biệt, đối với tôi dễ dàng hơn nhiều.

Để làm cho nó rõ ràng hơn, cái mà tôi gọi là "kỹ năng giải thích mã nguồn" là một

a) khả năng giải thích rõ ràng luồng thực thi của mã - ví dụ: "điều này gọi điều đó là điều đó, trả về đối tượng đó, sau này gọi phương thức A, chuyển đối tượng B đến ..."

a) khả năng giải thích rõ ràng các vấn đề với thiết kế hiện tại, hoặc, điều quan trọng hơn, hàm ý của mã nguồn thay đổi như trong "nếu, vì lý do hiệu năng, chúng ta bắt đầu lưu trữ đối tượng như một trường của lớp, chúng ta sẽ có để sửa đổi ở mười nơi khác nhau để đảm bảo rằng bộ đệm luôn ở trạng thái cập nhật ", v.v.

Tôi đã cố gắng phân tích lý do tại sao tôi lại tệ trong việc giải thích mọi thứ và không tìm thấy bất kỳ lời giải thích nào ngoại trừ có thể tôi giải thích mọi thứ theo cách gạch đầu dòng, điều mà một số người có thể thấy quá cứng nhắc. Ngoài ra khi tôi giải thích những điều có lẽ tôi tập trung quá nhiều vào những gì tôi nói và bỏ lỡ những câu hỏi, những gì mọi người hỏi, nhưng một lần nữa với tôi cảm giác như những câu hỏi này thường không liên quan và chỉ đơn giản là kéo cuộc trò chuyện đi.

Những gì bạn có thể đề xuất (ngoại trừ "thực tiễn làm cho nó hoàn hảo", thứ mà tôi không thực sự mua, vì tôi nghĩ rằng tôi có thể sẽ thực hành nhiều lỗi tương tự hết lần này đến lần khác) để tôi có thể cải thiện nguồn kỹ năng giải thích mã.

Một trong những vấn đề là những đoạn mã nhỏ không phải lúc nào cũng giải thích được bức tranh lớn hơn. Ví dụ, khi tôi nhìn vào mã nguồn lạ trong một ngôn ngữ lập trình quen thuộc, tôi thường hiểu hầu hết các câu lệnh riêng lẻ. Đồng thời, tôi có thể đấu tranh để hiểu thuật toán lạ mà chúng đóng góp, thuật toán đó đóng vai trò gì trong giải pháp hoàn chỉnh và tại sao thuật toán đó được chọn hơn các giải pháp thay thế khác. Theo một nghĩa nào đó, mặc dù tôi hiểu những tuyên bố đó, tôi thực sự không hiểu chúng chút nào.

Một ví dụ về điều này là chức năng Fast Inverse Square Root cổ điển .

Một số điều tôi thấy hữu ích trong việc xử lý việc này:

• Giải thích mã theo cùng ngôn ngữ mà người dùng sử dụng.
• Giải thích mã bằng các thuật ngữ lập trình viên tiêu chuẩn, ví dụ: Các thuật ngữ như "bộ đệm", "danh sách", "singleton" quen thuộc với hầu hết chúng ta, như các thuật ngữ toán học phổ biến.
• Giải thích những gì bạn đang làm về mặt đầu vào và đầu ra.
• Phát minh từ cho các khái niệm bạn không có từ cho. Đôi khi tôi sử dụng các từ như "điều chỉnh", "chuỗi" hoặc "wrangler" như một cách viết tắt cho một số khái niệm rất nút. Rốt cuộc, đó là cách mà các thuật ngữ nổi tiếng đã được phát minh ở nơi đầu tiên.
• Nhận ra rằng, mặc dù bản thân một vài dòng mã có vẻ đơn giản, vai trò của chúng trong cơ sở mã lớn hơn có thể khá phức tạp. Bạn không thể luôn giải thích chúng mà không cung cấp nhiều thông tin cơ bản. Nếu đó là trường hợp, cung cấp nó.
• Cho ví dụ cụ thể.
• Vẽ sơ đồ .

Lý do rất đơn giản. Bạn nghĩ như một lập trình viên.

Có thể giải thích các khái niệm ở cấp độ cao là những gì chúng ta làm cả đời khi chúng ta muốn truyền đạt ý tưởng. Tuy nhiên, khi chúng tôi lập trình, chúng tôi đặt mình vào suy nghĩ rằng chúng tôi phải hiểu cách thực hiện các nhiệm vụ theo nhiều bước nhỏ và chi tiết. Giải thích điều đó có nghĩa là bạn phải chuyển đổi "các bước nhỏ và chi tiết" thành điều mà bất cứ ai cũng có thể hiểu, đó là một đơn đặt hàng không nhỏ. Nếu những thứ đó dễ nắm bắt, mọi người đều có thể lập trình. Đó là những gì làm cho chúng tôi lập trình viên.

Tuy nhiên, như bạn có thể đoán, đó là một điều để hiểu cách thực hiện các nhiệm vụ theo nhiều bước nhỏ và chi tiết và đó là một cách khác để giải thích chúng tốt.

Tôi cũng vậy, đã gặp một số khó khăn trong nỗ lực này nhưng tôi nhận thấy rằng một số thủ thuật đã giúp tôi. Giả sử bạn có một phương pháp mà bạn đã viết và bạn phải giải thích cách thức hoạt động của nó:

• Trước khi bạn bắt đầu với dòng đầu tiên, hãy đọc phương thức của bạn và nhớ phạm vi là gì, mục đích của nó là gì, khi nào nó được gọi và tại sao đây là cách bạn quyết định làm điều đó. Tóm lại, biết những gì nó làm. Theo cách này, bạn có thể trả lời các câu hỏi một cách kỹ lưỡng và theo cách bao hàm ý nghĩa của phương pháp (nghĩa là khi họ nói "Tôi không hiểu ý của dòng này", bạn có thể trả lời: "Đây là những gì bắt đầu kết nối đến cơ sở dữ liệu được sử dụng trong suốt chương trình "chứ không phải" Điều đó gọi JDBC sử dụng chuỗi kết nối để thiết lập kết nối "để trả lời câu hỏi nhưng có lẽ không phải là điều làm cho nó rõ ràng).
• Giải thích từng dòng trong phương thức về những gì mỗi dòng đóng góp vào mục đích chung của phương thức. Tại sao bạn đặt dòng đó ở đó? Ồ đúng rồi, dòng này gọi lớp chịu trách nhiệm quản lý đầu vào để kiểm tra xem tôi có cần ủy thác các hành động trong vòng lặp kết xuất của mình không.
• Hãy thừa nhận khi mã của bạn có thể không rõ ràng hoặc có thể được cải thiện. Nếu bạn tìm thấy mã có thể không rõ ràng, hãy viết lại để làm cho nó rõ ràng hơn. Nó không giúp truyền thông làm nản lòng lập trình viên đồng nghiệp của bạn nghĩ rằng anh ta nên hiểu những gì anh ta đang nhìn thấy.

Nói chung, tập trung vào lý do tại sao bạn đặt mã đó ở đó thay vì những gì nó làm và bạn sẽ thấy rằng những lời giải thích của bạn sẽ dễ dàng hơn và chúng sẽ dễ hiểu hơn.

Tôi cũng đã thấy mình ở một vị trí tương tự đôi khi phải vật lộn với lời giải thích về dòng thực thi mã ở mức thấp. Điều giúp tôi là chọn hướng dẫn ngôn ngữ lập trình trong câu hỏi (Bjarne Stroustrups Lập trình trong C ++) để làm mới bản thân về thuật ngữ đã bị phai mờ trong những năm qua. Cộng với việc đọc các bài báo / blog liên quan đến ngôn ngữ mới để cập nhật các kỹ thuật / thuật ngữ hiện tại.

Về các vấn đề / ý nghĩa thiết kế phức tạp: Bạn có thể nói 'Tôi không thể đưa ra câu trả lời cho bạn mà không cần phân tích thêm' mà không đưa ra câu trả lời ngay lập tức. Phần mềm có thể trở nên rất phức tạp và ngay cả những nhà phát triển thông minh nhất cũng không thể giữ tất cả các tương tác trong đầu mọi lúc - cộng với tất cả chúng ta đều là con người và hiểu sai hoặc bỏ lỡ mọi thứ.

Dành thời gian để đi và phân tích mã để bạn có thể chắc chắn hơn về câu trả lời của mình. Nó chắc chắn sẽ tốt hơn là đưa ra một câu trả lời ngay lập tức, có thể sai và sai. Từ một vị trí nhà phát triển cao cấp, nó sẽ được coi là khôn ngoan và có lợi cho bạn thay vì trông có vẻ nhạy bén nhưng có khả năng ngu ngốc!