Làm việc với code của người khác là một kỹ năng cơ bản của developer. Dành thời gian tìm hiểu và code đó thậm chí có thể trở thành của riêng bạn.
Hôm nay tôi sẽ xem xét một số phương pháp tốt nhất để làm việc với code của người khác, đọc code di sản (legacy) một cách hiệu quả. Đây không phải là một chủ đề dễ dàng để viết đầy đủ.
Để làm cho quá trình dễ thở hơn, tôi tập trung vào các mục chính sau:
- Tương tác
- Quan sát
- Chạy Test
- Fix Bugs thiết kế dành cho người mới
- Tìm Tài nguyên sẵn có
- Sử dụng một IDE tốt
- Đọc sách & Blogs
- Đóng góp Tài liệu
- Hãy cẩn trọng
Các lead developer là ai? Họ ở đâu? Có phải họ có mặt trực tiếp trong văn phòng của bạn? Nếu vậy, hãy nói chuyện với họ hoặc gửi email cho họ. Những người này hẳn là có kiến thức tốt nhất về dự án.
Bạn có phải là nhân viên làm việc từ xa (remote) hoặc freelancer? Công ty hoặc dự án có các kênh thông tin liên lạc không? Các developer dùng IRC, Slack, Twitter, email, Trello hay cái gì khác?
Hãy chắc chắn rằng bạn đang cùng nơi với họ. Một chỉ trích thường nhằm vào Zend Framework 2 là không có cộng đồng năng động. Không hẳn vậy, vì kênh IRC của họ đang hoạt động hàng ngày. Hãy đảm bảo bạn đang sinh hoạt cùng chỗ với các developer và các thành viên khác trong team.
Khi bạn lần đầu vào một dự án, đừng quá khắt khe với bản thân. Đừng mong đợi biết được tất cả mọi thứ ngay từ đầu. Tôi từng nghe nói về chuyện mất ba tuần đến ba tháng làm việc hàng ngày với codebase (code nền tảng đã có sẵn) trước khi một developer có thể thực sự làm việc hiệu quả với codebase đó.
Một số người có quan niệm sai lầm rằng bạn có thể, bằng cách nào đó, chỉ cần nhảy vào và ngay lập tức làm việc hiệu quả. Có lẽ họ đã xem quá nhiều phim của Hollywood như Swordfish.
Các codebase mất thời gian để học vì chúng được xây dựng từ những ý tưởng, định kiến, niềm tin và cách tiếp cận của tất cả các developer làm việc trong dự án. Vì bạn là người mới, bạn sẽ không có bất kỳ kiến thức nền nào cả.
Dưới đây là 5 cách hay để bắt đầu:
- Dành thời gian xem lướt qua mọi thứ
- Đặt câu hỏi
- Cài đặt thử
- Thử sử dụng cái vừa cài đặt thử
- Đọc qua các comment trong code và các tài liệu liên quan
Đừng khắt khe với bản thân, hãy cho mình cơ hội để có được một sự khởi đầu tốt. Sau một thời gian, bạn sẽ bắt đầu hiểu rõ hơn về cách ứng dụng được xây dựng.
Tại giai đoạn này, hãy tiến nhanh hơn bằng cách hỏi các developer khác và các senior developer. Bạn hẳn đã có một danh sách các câu hỏi khi bạn lướt qua codebase.
Hãy dành thời gian ra để hỏi các developer khác lời giải thích cho các khúc mắc của bạn. Đừng e ngại, hãy hành động và nhận được câu trả lời mà bạn cần.
Bất kỳ codebase tốt nào đều có các test. Nếu không thì thật không hay. Thực ra có thể là các developer team này chưa bao giờ thực hiện test, nhưng tôi sẽ hơi quan ngại nếu họ không làm điều này.
Nếu có test, hãy chạy thử. Có pass hết không? Tôi đã gặp nhiều codebase có một bộ các test mà không ai có thể chạy qua được. Liệu chúng đã được cập nhật chưa?
Sau khi bạn đã thử chạy chúng, hãy đọc. Nếu chúng được viết tốt, chúng sẽ mô tả cách ứng dụng làm việc, nó sẽ làm gì, và các thành phần kết dính với nhau như thế nào. Sẽ mất thời gian để đi sâu vào những thứ này.
Một cách dễ dàng để bắt đầu là fix các bug dành cho người mới hoặc junior developer trong dự án. Hai ví dụ tốt là Joind.In và ownCloud, trong hình dưới đây là bug tracker của ownCloud:
Bạn có thể thấy các ticket đã được đánh dấu rõ ràng. Hãy đọc qua và tham gia fix chúng. Những bug này không đòi hỏi quá cao về kỹ thuật, nhưng bạn sẽ có thể dễ dàng hòa mình vào dự án, xây dựng sự tự tin và kiến thức.
Thành tựu và kỹ thuật phức tạp thì rất tuyệt vời, nhưng nếu hiện tại không đạt được ngay hoặc sẽ mất rất nhiều thời gian, chúng sẽ không giúp gì cho sự tự tin và nhiệt huyết của bạn. Hãy bắt đầu từ những cái dễ và nhỏ.
Một trong những điều tốt nhất bạn có thể làm khi tiếp quản một codebase, hoặc khi tham gia vào một team hiện có, là tập hợp được nhiều tài nguyên nhất có thể. Không biết cần tìm gì ư? Dưới đây là một số ý tưởng để giúp bạn bắt đầu:
- Bạn có quyền truy cập vào kho lưu trữ mail không?
- Dự án hoặc công ty có wiki không?
- Tài liệu dự án nào đã được biên soạn?
- Bạn đã đọc qua version control history chưa?
- Những người đóng góp có viết các commit message có ý nghĩa và nhất quán không?
IDE tốt thì quý như vàng. Dù bạn là một developer Ruby, Python, Go, Java, PHP hay ngôn ngữ nào khác, hãy tìm một IDE tốt dành riêng hoặc tùy chỉnh cho ngôn ngữ bạn lựa chọn.
Tôi đánh giá cao những người theo chủ nghĩa thuần túy, thích VIM hoặc Emacs, điều đó OK thôi. Nhưng tôi là một người yêu IDE và IDE mà tôi lựa chọn là PhpStorm. Có rất nhiều những lựa chọn khác, chẳng hạn như Eclipse, TextMate, SublimeText, và VisualStudio.
Một khi bạn đã tìm thấy IDE cho mình, hãy bắt đầu sử dụng các tính năng nó cung cấp. Ở đây tôi lấy ví dụ cho PhpStorm, bạn có thể áp dụng những nguyên tắc này cho IDE bạn chọn.
Bắt đầu duyệt qua code và xem nó có theo một chuẩn nào không. Không nhất thiết phải là một chuẩn chính thức như PHP PSRs. Xem thử liệu developer có theo một phong cách nhất quán không hay là lộn xộn. Sử dụng các công cụ như mess detector và cyclomatic complexity tester để đánh giá chất lượng code.
Có tài liệu hướng dẫn nào không? Nếu có thì IDE của bạn sẽ có thể sử dụng chúng khi bạn kiểm tra code. Tiếp theo, sử dụng một trình gỡ lỗi (debugger), chẳng hạn như xhprof, Xdebug hoặc Zend Debugger, rồi chạy ứng dụng xem nó hoạt động như thế nào.
Nó làm gì? Cấu trúc dữ liệu nào nó tạo ra và sử dụng? Nó có lặp lại các khối code không cần thiết không? Có nhiều thứ hơn nữa cần xem xét, nhưng sử dụng các tính năng mà IDE cung cấp sẽ giúp bạn dễ thở hơn nhiều.
Điều này đúng cho cá nhân tôi. Càng học hỏi nhiều, chúng ta càng trở nên khôn lớn và làm được việc. Chúng ta không phải là người đầu tiên trên con đường chúng ta đang đi. Nhiều, rất nhiều những người khác đã đi trước chúng ta và đã mắc những lỗi tương tự như chúng ta.
Hãy tiết kiệm cho mình một chút thời gian khi nghĩ về quá trình học tập khó khăn của những người đi trước và học hỏi từ họ. Nhiều developer giỏi cũng vừa là các tác giả viết sách và các blogger.
Một trong những tác giả yêu thích của tôi là Martin Fowler, người đã xuất bản một cuốn sách tuyệt vời về chủ đề tái cấu trúc (refactoring). Cũng có những cuốn sách khác rất tuyệt vời, chẳng hạn như Design Patterns, và các trang web như SourceMaking.com.
Tự tìm hiểu và tiếp tục học hỏi từ các nguồn tài nguyên như vậy. Nó không hề dễ dàng, nhưng phần thưởng là rất xứng đáng.
Đây là một trong những điều mà tôi không làm đủ. Thật dễ dàng khi ngồi ngoài và chỉ trích một codebase, framework hay dự án phần mềm. Thay vì làm điều đó, hãy bắt tay vào tham gia đóng góp.
Tài liệu không phải là dành cho các lập trình viên thất bại, các nhà thiết kế đồ họa hay những người không am hiểu kỹ thuật. Các dự án phần mềm lớn nhất luôn đề xuất rằng nơi tốt nhất để bắt đầu là tài liệu hướng dẫn.
Một trong những dự án nổi bật nhất mà thực hiện điều này là Linux Kernel. Còn cách nào tốt hơn để học một cái gì đó hơn là tài liệu? Sau tất cả, nếu bạn thực sự biết điều gì đó thì bạn mới có thể làm tài liệu về nó.
Vì vậy, nếu là một dự án mã nguồn mở, hãy nhảy vào, tìm hiểu về nó, đọc qua code, ghi chép lại, và sau đó đóng góp tài liệu. Nếu đó là một ứng dụng nội bộ, hãy là người đầu tiên bắt đầu làm tài liệu; thậm chí nếu không có ai khác ngoài bạn.
Có thể sẽ không có tài liệu; nhưng điều đó thật sự khủng khiếp. Mọi dự án đều phải bắt đầu từ một nơi nào đó. Khi bạn làm việc với code, hãy viết ra những gì bạn biết.
Những developer giỏi nhất mà tôi biết, ví dụ như Lorna Jane, bắt đầu viết blog theo cách này. Cô viết blog để lưu giữ những gì đã học được, mà sau này trở thành một trong những blog PHP phổ biến nhất.
Điểm cuối cùng: Hãy suy nghĩ cẩn trọng đối với các developer mà bạn đang xem và làm việc trên di sản của họ. Bạn không biết về sự nghiệp và trình độ học vấn của họ, và những thứ này đã hạn chế họ như thế nào, khi họ viết ra những dòng code mà bạn đang đọc.
Hơn nữa, level kĩ năng hiện tại của bạn đang ở mức nào? Sẽ là tùy tiện khi chúng ta trẻ hơn, non hơn, và ít kinh nghiệm, lại đi phán xét người khác.
Chúng ta nghĩ rằng chúng ta biết tất cả và những kỳ vọng, những khái niệm và phương pháp tiếp cận của chúng ta là những cách đúng và chính xác. Nhưng có thực sự đúng là như vậy không? Tôi tin rằng, khi chúng ta trưởng thành và lớn hơn một chút, chúng ta cũng trở nên khôn ngoan hơn và chấp nhận vô vàn các phương pháp tiếp cận phát triển phần mềm mà đã từng tồn tại.
Chúng ta có thể không cần phải đồng ý với họ, nhưng họ không hẳn là đã sai. Họ có thể có rất nhiều điều để dạy chúng ta, có thể giúp chúng ta lớn khôn. Vì vậy, hãy luôn cố gắng và suy nghĩ ân cần với những người khác và vị trí của họ. Đừng trở thành một người mới đáng ghét, chỉ ngón tay và đổ lỗi. Hành xử kiểu này sẽ không giúp ích cho bất kì ai, đặc biệt là chính bản thân bạn.
Có rất nhiều việc phải làm để làm việc với code của người khác trở nên dễ dàng hơn. Còn bạn, bạn đã sử dụng các phương pháp, thủ thuật và công cụ nào? Xin mời chia sẻ comment bên dưới!
Bài viết của tác giả Matthew Setter tại địa chỉ https://www.sitepoint.com/work-peoples-code/
