Hotline

5 việc đơn giản có thể khiến bạn ngay lập tức trở thành một lập trình viên giỏi (Phần 2)

Tiếp nối theo Phần 1 của tuần trước, chúng ta lại nghiên cứu những phương pháp kỳ diệu giúp bạn lạnh lùng đứng lên phất áo đi về mỗi khi kim đồng hồ điểm số 6. lập trình viên giỏi

Để trở thành lập trình viên giỏi, bạn cần...

lập trình viên giỏi

3. Luôn copy tên riêng thay vì viết tay

Điểm này rất dễ, có chung lý do với việc vì sao ta cần theo coding convention: để giảm thiểu những lỗi vặt như typo. Giả sử bạn viết HTML có một cái <div class="foobar"></div>. Vậy khi viết style cho nó, hãy copy chữ foobar sang CSS thay vì điền tay. Tương tự với tên biến, tên hàm, bất kỳ một loại tên riêng nào do bạn đặt ra mà không thuộc bộ tên chuẩn của ngôn ngữ bạn đang viết. Vì sao? Trong các loại lỗi typo thì lỗi do viết sai tên riêng là thường xuyên xảy ra nhất. Có ai viết sai public static void main bao giờ? Cái người ta viết sai quanh đi quẩn lại chỉ có là cartShopListController với listCartShopControllernhầm với nhau thôi. Với những tên tương đối dài như tên Class hoặc tên Function thì việc copy tên thực tế là nhanh hơn tự viết bằng tay rất nhiều. Việc copy tên phối hợp với đặt tên theo naming convention sẽ đem lại hiệu quả không tưởng tượng được cho hiệu suất làm việc của bạn.

4. Comment code khi cần, nhưng cố gắng viết code sao cho việc comment là không cần thiết

Trong khi code, lâu lâu có 1 lần bạn sẽ phải viết những đoạn code tương đối phức tạp, mà với trình độ hiện thời của mình thì cần 1 khoảng thời gian để phân tích. Những lúc như vậy nên dành 1 chút thời gian, viết một đoạn comment ngắn nói ra những kiến giải của bạn vào đó. Việc này có 2 lợi ích:
  1. Giúp bạn lặp lại 1 lần những kiến giải của mình, đảm bảo được nó có cơ sở vững chắc và logic.
  2. 1 tuần sau khi bạn quay lại chỗ code đó, bạn không phải ngồi phân tích code lại từ đầu.
Comment ngoài việc giải thích code, còn có thể dùng để đánh dấu phân vùng ý nghĩa của từng mảng code lớn:
public class ParallaxLayerController : MonoBehaviour
{
  #region Variables

  public int parallaxLayerIndex;
  private float zOffset;
  ...

  #endregion

  #region Framework Overrides

  ...

  #endregion

  #region Getters/Setters

  ...

  #endregion
}
Cũng có thể chỉ là 1 đoạn comment TODO để đánh dấu những chỗ sau này cần bổ sung thêm mà giờ chưa phải là lúc để làm (ví dụ như khi requirement của phần đó chưa làm xong):
$('body').on('click', '.nav_btn_search', function(){
  // TODO add form validation when requirement doc is finished
  $('#products_form').submit();
});
Tại sao tôi liên tục thay đổi ngôn ngữ trong các ví dụ từ đầu bài viết đến giờ? Bởi vì tôi muốn các bạn thấy khi một đoạn code được format 1 cách rõ ràng, thì dù là người không biết gì về ngôn ngữ đó cũng có thể dễ dàng hiểu được đoạn code đó có ý nghĩa gì. Comment code có ý nghĩa như vậy, nhưng tại sao trong tiêu đề tôi lại nói cố gắng code sao cho việc comment là không cần thiết? Các bạn đã bao giờ thấy một đoạn code được comment kiểu như này chưa:
/**
 * function printClassName
 * params obj
 */
void printClassName(Object obj) {
  System.out.println("The class of " + obj + " is " + obj.getClass().getName());
}
Đây là một đoạn code vẫn thường gặp nếu bạn dùng IDE Eclipse. Các bạn có thấy cái đống comment dài hơn cả bản thân function đấy nó có ý nghĩa thiết thực gì không ạ? Nó có cho người đọc thêm thông tin gì mà phần khai báo function chưa có không? Không có. Đây là comment thừa thãi, tốt nhất là nên xoá nó đi, trừ khi khách hàng của bạn thừa cơm rảnh rỗi bắt bạn phải viết. Mục tiêu khi code là cố gắng làm sao để hầu hết các comment đều trở thành “thừa thãi” như vậy. Máy tính thời nay rất mạnh. Mạnh vô cùng. Cho dù là cái điện thoại trên tay bạn cũng có khả năng tính hàng tỷ phép tính mỗi giây. Điều đó có nghĩa là gì? Nghĩa là giá trị của thuật toán và performance bị giảm đi so với giá trị của code-dễ-đọc. Các bạn xuất thân từ dân chuyên toán sang lập trình thường khá cố chấp với thuật toán. Luôn cố gắng đạt được thuật toán tối ưu với hy vọng trở thành lập trình viên giỏi. Quả thật hiệu quả của thuật toàn là không cần bàn cãi. Nó giúp giảm thời gian function của bạn chạy từ 7 millisecond xuống còn 4 millisecond. Nhưng thực tế thì sao? Thực tế là những thứ chạy dưới 100 millisecond đối với con người chả khác mẹ gì nhau, nó đều là ngay-lập-tức hết. Trừ khi bạn đang thiết kế nên Adobe Aftereffect, hay đang chế tạo tên lửa cho NASA. Chứ trong những phần mềm dân dụng bình thường, thời gian thuật toán chạy chẳng là cái gì khi so với thời gian VGA render hiển thị, so với latency kết nối internet, so với thời gian mà người dùng ngồi nhìn animation slide qua slide lại các view trên điện thoại. i++ hay i+=1 hay i=i+1 cái nào hơn? Đọc thì cũng vui đấy, nhưng trong 99.99% trường hợp, 3 cái đấy chả khác gì nhau cả. Nhưng có 1 việc bạn có thể làm với code của mình mà đem lại hiệu quả thiết thực: đó là viết những dòng code đơn giản, dễ hiểu. Hãy hạn chế viết những đoạn code rối rắm tối nghĩa, code xong tự hào đem khoe khắp nơi ta là lập trình viên giỏi, là dân pro. Code đấy nhìn thì có vẻ dữ dội đấy, nhưng 1 tuần sau, 1 tháng sau khi bạn quay lại, việc đầu tiên bạn làm sẽ là chửi cái thằng quá khứ của mình. Tập trung viết code đơn giản, nhìn basic như code trong sách tutorial. Những đứa dốt sẽ nghĩ bạn ngu; nhưng đồng nghiệp của bạn sẽ cảm ơn bạn, và cái đứa tương lai của bạn khi sau này đọc code đó cũng sẽ cảm ơn bạn rằng ồ, thằng này là một trình viên giỏi quá, cẩn thận quá. Cố gắng viết nên những dòng code đẹp như thơ, người đọc nhìn vào trào dâng cảm giác tươi mới thông tuệ. Mỗi dòng code của bạn phải như lời chúa Jesus, dẫn vào đầu người đọc 1 cách tự nhiên như thể nó dĩ nhiên là phải như vậy. lập trình viên giỏi

5. Nghĩ trước, làm sau

Đây là vấn đề thường gặp ở những bạn mới đi làm. Trong khi học lập trình, ta thường hay có thói quen làm theo tutorial, đọc đến đâu vọc ngay đến đấy, có vấn đề gì thì mới ngồi xem thử tại sao. Sửa xong lại ngồi chép tiếp sửa tiếp. Trong khi học, phương pháp thông thường nhất là “Cứ chép cái đã, rồi từ từ hiểu sau”. Đây là cách học rất tốt, nhưng không phải là cách làm việc. Người ta thuê bạn đến làm việc chứ không thuê bạn đến đọc tutorial. Khi làm việc, mỗi khi nhận task mới. Việc đầu tiên cần làm đó là nhìn mô tả của task đó, nghĩ xem mình sẽ làm nó như thế nào. Phần nào chưa nghĩ ra cách làm, google ngay xem giải quyết ra sao. Phải đảm bảo bạn chắc chắn có đủ khả năng hoàn thành việc đó trước khi chính thức bắt tay vào làm. Tại sao? Có 2 lý do:
  1. Suy nghĩ kỹ một cách toàn diện trước khi làm sẽ giúp bạn tính trước và bố cục kết cấu code của mình, tránh tình trạng code rồi sửa, đập đi làm lại liên tục.
  2. Sớm phát hiện những vấn đề trong công việc. Nên nhớ, công việc không bao giờ là của một người. Ngoài bạn ra còn có khách hàng, quản lý, thiết kế đồ hoạ, thiết kế hệ thống, kiểm thử chất lượng… Việc phát hiện vấn đề sớm giúp bạn có thể thông tin cho những bên liên quan ngay lập tức, sau đó làm những phần không bị ảnh hưởng trong thời gian chờ đợi. Nếu bạn làm tới đâu nghĩ tới đấy, thì khi gặp vấn đề cần sự hỗ trợ của người khác bạn chỉ có thể ngồi đực mặt ra gõ bàn lướt facebook trong lúc chờ người đó có thời gian rảnh. Và tất nhiên, tối đó “Ở lại làm nốt đi nhé em”.

Đến đây là kết thúc 5 điều đơn giản có thể cải tiến hiệu suất về đúng giờ của bạn một cách rõ ràng. Ta điểm qua lại 5 điều này 1 lần nữa:
  1. Luôn luôn tuân theo coding convention
  2. Không copy paste code của người khác
  3. Luôn copy tên riêng thay vì viết tay
  4. Comment code khi cần, nhưng cố gắng viết code sao cho việc comment là không cần thiết
  5. Nghĩ trước, làm sau
Có thể các bạn đồng ý hoặc không, nhưng hãy thử làm theo, tôi chắc chắn các bạn sẽ thấy sự thay đổi, mà trên con đường trở thành lập trình viên giỏi thì đây là điểu bắt buộc. Không phải là thay đổi sau 1 tháng 1 năm như đi tập tạ đâu ạ, nó là thay đổi ngay-lập-tức. Sáng áp dụng, chiều thấy kết quả luôn. Chúc các bạn thành công! lập trình viên giỏi Trở thành lập trình viên giỏi

Tôn Hồng Đức

Giảng viên khóa Web và Game Techkids