Quay lại với chủ đề Cách để cải thiện khả năng của bạn, ở phần một, mình đã giới thiệu qua một vài cách mà bạn có thể chủ động thực hiện, nếu vẫn chưa tìm thấy cách thức nào phù hợp với mình, hãy thử thêm một vài cách được trình bày sau đây xem như thế nào:

À mà khoan, để mình nhắc lại cho các bạn một trong những định nghĩa cốt lõi của việc làm phần mềm, cụ thể hơn ở đây là việc viết code:

Phần mềm (hoặc code) được viết ra là để giải quyết vấn đề

Các bạn thấy không, viết code là để giải quyết những vấn đề mà người dùng gặp phải, để đáp ứng được những mong muốn của người dùng. Suy rộng ra, cải thiện khả năng viết code đòi hỏi phần lớn vào cách thức mà bạn nhìn nhận vấn đề, và cách tiếp cận để giải quyết vấn đề đó. Ngôn ngữ lập trình chỉ là một công cụ giúp mình triển khai ý tưởng mà thôi.

Để cải thiện khoản giải quyết vấn đề, không có gì tốt hơn là bạn có được nhiều góc nhìn, nhiều cách tiếp cận hơn tới cùng một vấn đề. Bạn đã từng nghe qua khái niệm “review code” chưa nhỉ? Nếu chưa, thì để mình giải thích sơ qua tại sao việc này lại có lợi như vậy.

Review code – hãy để việc này là yêu cầu bắt buộc

Review code có nghĩa là: khi một developer được giao nhiệm vụ thực hiện tính năng A, người đó sẽ dành thời gian để suy nghĩ giải pháp và triển khai code, sau khi làm xong, source code của tính năng đó sẽ được một người khác kiểm tra lại trước khi quyết định xem có merge nó vào production hay không.

Với lý tưởng này, bất kể bạn là new bie hay đã có nhiều kinh nghiệm, source code của bạn làm vẫn luôn được kiểm tra lại một lần nữa trước khi merge vào production. Điều này đảm bảo source code không chỉ giải quyết được bài toán đặt ra, mà còn phải đạt được tiêu chí “giải pháp đưa ra chính là giải pháp phù hợp nhất“.

Bạn là new bie, được kiểm tra lại source code bởi một người khác có kinh nghiệm hơn chắc chắn là có lợi rồi, họ sẽ chỉ cho bạn những điều còn thiếu hoặc những cách làm chưa tốt. Ngược lại, nếu có cơ hội review source code cho người khác, ắt hẳn bạn sẽ được thấy nhiều cách thức mới để giải quyết vấn đề – và rất có thể những cách thức này khác với ý tưởng ban đầu của bạn. Kĩ năng của bạn từ đó mà được cải thiện.

Đọc code của người khác để tìm kiếm những giải pháp tốt

Đây là một trong những lợi ích lớn nếu bạn làm việc cho một công ty product so với công ty outsource. Tất nhiên là cũng phải kèm theo điều kiện là bạn phải truy cập được vào code-base của sản phẩm. Việc được tiếp cận với một code-base lớn có thể coi như bạn được khai thác một “mỏ giải pháp” lớn, nó miễn phí, vậy tại sao không “đào” lên dùng nhỉ.

Với những product được phát triển từ lâu, rất nhiều người đã góp sức để tạo nên code-base lớn, có thể đâu đó nó sẽ có những lời giải cho bài toán của bạn. Nếu bạn không có cơ hội làm trong product lớn, bạn có thể tận dụng kho thư viện open-source khổng lồ trên internet. Một ví dụ điển hình mà mình gặp như sau:

Mình cần viết một đoạn code để kiểm tra xem URL đang truy cập có thuộc danh sách black-list hay không, đoạn code của mình xử lí như sau: hàm checkPathInBlackList() nhận vào tham số path_name và sẽ kiểm tra xem giá trị này có nằm trong black-list hay không

function checkPathInBlackList( path_name ) {
    var split_url = path_name.split('/');
    var screen = split_url[split_url.length - 1];

    var supported = [
            'add_product.php',
            'add_product',
            'modify_product.php',
            'modify_product'
    ];

    return jQuery.inArray(screen, supported) !== -1;
}

Với URL là http://abc.com/product/add_product hoặc http://abc.com/product/add_product.php, chương trình phải phát hiện được nó nằm trong black-list. Đoạn code trên đã được kiểm chứng là hoạt động đúng. Dẫu vậy, mình cũng không hài lòng lắm khi code bị lặp lại: phải liệt kê lại mỗi path_name 2 lần (vd: add_product và add_product.php).

Sau một thời gian, mình tìm thấy một lời giải mới trong code-base mà mình làm việc, đại loại là function trên có thể viết lại như sau:

function checkPathInBlackList( path_name ) {
    var screen = 'banner_add';
    var supported_screens = [
        /add(\.csp)*$/,
        /banner_add(\.csp)*$/,
    ];

    var isSupported = supported_screens.some( regex => screen.match(regex) );
    return isSupported;
}

Vậy là mình học thêm được một cách mới để giải quyết bài toán ban đầu, chính nhờ đọc source code của những người khác đã viết. Vấn đề trùng lặp code đã được giải quyết. Code trông cũng “xịn xò” hơn nhiều.

Tóm lại

Ông bà ta vẫn nói: “chín người mười ý”, với ý nghĩa là nhiều người tham gia bàn luận quá dễ dẫn tới xung đột. Nhưng tin mình đi, với số lượng người trong team vừa phải, code theo nhóm hoặc có reviewer luôn đem đến nhiều ý tưởng giải quyết rất đột phá và sáng tạo.

Bên cạnh đó, việc tham gia vào dự án nhiều người cũng giúp ích rất nhiều cho sự tiến bộ của bạn, tất nhiên là bạn cần phải chủ động để tìm kiếm kiến thức, chủ động học hỏi từ người khác để luôn tiến bộ.