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 1)

“Rồi rồi biết rồi”? “Cái này em vẫn làm theo sẵn rồi anh ei”? Các bạn có chắc chắn không? Tôi gặp 10 lập trình viên mới vào nghề hỏi họ “Có làm theo coding convention không?”, thì cả 10 đều trả lời họ có. Nhưng mà đến lúc mở code ra thì phải đến 9 người chả có theo cái coding convention nào hết. Họ theo cái coding convention gọi là “Ờ thì nói chung là em có theo, chỉ có đoạn này em đang test thử có chạy không nên để tạm thế thôi”. Coding convention là thứ mà khi bạn học lập trình trường nào, lớp nào cũng dạy các bạn. Nhưng có 1 cái quan trọng nhất các trường lớp lại thường không dạy, đó là “tại sao” lại cần làm thế. Bởi vì không biết tại sao, nên hầu hết mọi người đều không hiểu được tầm quan trọng của coding convention, dẫn tới coi nhẹ nó. Cái câu trích dẫn ở trên, đợi tý để tôi quote lại to đẹp đóng khung lên nhìn cho dễ:

“Ờ thì nói chung là em có theo, chỉ có đoạn này đang em test thử có chạy không nên để tạm thế thôi”

~ Thanh niên làm overtime 1 tuần 7 ngày chia sẻ Các bạn có bao giờ nói câu này chưa? Nếu chưa bao giờ thì quá tốt, tôi mừng cho bạn. Nếu là câu cửa miệng thì rất buồn bạn ạ; mỗi lần bạn nói câu này là 1 lần sếp của bạn, đồng nghiệp của bạn phải thở dài 1 câu “Sao tôi lại phải làm cùng với 1 thằng dốt như thế này? Haizz….” (tôi có thâm niên thở dài 7 năm liên tiếp không ngừng nghỉ rồi các bạn ạ, thở dài chuyên nghiệp và có thần lắm) Coding convention chỉ có ý nghĩa, khi từng dòng từng dòng code trong project của bạn tuân thủ chặt chẽ theo ngay khi bạn viết nó. Thực ra trong các lời khuyên của tôi, chỉ riêng điều này sẽ đem lại hiệu quả tương đương với cả 4 điều còn lại cộng lại. Demo luôn, đoạn code sau có bug, các bạn thử xem lỗi tại sao nhé:

function renderScene()
{	if(this.matrixNeedsUpdate ) this.updateTextureMatrix();
      this.matrixNeedsUpdate = true;

      var scene=this;
    while ( scene.parent !==null){
    scene= scene.parent;
}
	if ( scene !== undefined && scene instanceof THREE.Scene ) {
		this.renderer.render( scene, this.mirrorCamera, this.tempTexture, true );
}

Rất khó tìm đúng không ạ? Có thể bạn thấy đây là một đống code loạn xạ, công nghệ gì đây bạn cũng không rõ. Đang nhiên bảo tìm bug thì ai mà tìm được? Giờ vẫn đoạn code đó, tab lại cho chuẩn:

function renderScene {
  if ( this.matrixNeedsUpdate ){
    this.updateTextureMatrix();
  }
  this.matrixNeedsUpdate = true;

  var scene = this;
  while ( scene.parent !== null ){
    scene = scene.parent;
  }

  if ( scene !== undefined && scene instanceof THREE.Scene ) {
    this.renderer.render( scene, this.mirrorCamera, this.tempTexture, true );
  }

Chẳng cần trình độ cao siêu gì, nhìn qua ai cũng thấy rõ ràng cái hàm renderScene này nó thiếu dấu } kết thúc ở cuối. Thêm cái đóng ngoặc vào là xong. Các bạn có thấy cảnh này rất quen không ạ? Code chạy lỗi, không hiểu tại sao. Vò đầu bứt tóc nửa ngày không tìm ra, đến cuối cùng hoá ra tại thiếu dấu ;. Tìm ra xong bạn thở phào buông 1 câu với sếp “Tại mỗi cái dấu chấm phẩy chứ code em đáng nhẽ ngon rồi.” Sai lầm. Sai rất lớn. Dấu chấm phẩy đấy nó không nhỏ đâu, và code của bạn nói 1 cách mỹ miều thì nó như cứt. Thiếu ;, đóng nhầm ngoặc, điền sai tên. Đáng nhẽ là I thì lại nhầm là l. Hơn một nửa số bug trong bất cứ chương trình nào đều là lỗi typo do sai chính tả. Giá mà có cách nào để những lỗi typo kiểu đấy không xảy ra thì tốt phải không ạ? Bớt 1 nửa số bug là giảm 1 nửa số tóc rụng trên đầu bạn mỗi ngày, giảm 1 nửa thời gian fix bug. Giá mà có 1 phép màu kỳ diệu nào để bạn có thể code trơn tru mà không còn phải lo chuyện viết sai chính tả nữa… Vâng, phép màu đấy không có gì xa vời, mà đã được dạy cho bạn từ khi còn đang mài đít trên ghế giảng đường rồi, nó chính là coding convention đấy ạ. Đặt tên biến như thế nào? Đặt tên hàm như thế nào? Xuống dòng ở đâu, chỗ nào tab lại, chỗ nào cách ra? Khai báo biến ở chỗ nào, hàm private vứt vào đâu? Mỗi file chỉ chứa 1 class, không viết code quá dài. Không dùng tiếng Việt trong code. Vân vân và vân vân. Tất cả, tất cả những cái đấy sinh ra chỉ với 1 mục đích duy nhất: để đảm bảo là code của bạn không có mấy cái “lỗi vặt” nữa. Để đảm bảo là code của bạn có một bố cục rõ ràng, hướng đi cụ thể; để bạn không phải vắt óc lên nghĩ mỗi khi cần đặt tên biến mới rồi sinh ra một cái tên lăng nhăng dẫn đến nhầm lẫn sau này. Làm lập trình càng lâu ta càng thèm muốn cảm giác code không có bug. Và kỹ năng né bug quan trọng nhất trong tất cả, dễ học dễ làm không cần kinh nghiệm mà hiệu quả kinh người là gì? Là coding convention. Tôi có đủ cơ sở cả về lý thuyết lẫn thực tế để tin rằng nếu code của bạn trông như một bãi rác, thì đầu của bạn thật ra cũng toàn là rác. Và muốn trở thành lập trình viên giỏi, dọn rác là điều cực quan trọng. Bây giờ là lúc tốt nhất để lên google search xem coding convention của ngôn ngữ bạn đang dùng là gì đấy ạ. Chỉ cần học thuộc, làm theo. Làm đến khi nó thành bản năng của mình. Tay code đến đâu tự động theo chuẩn đến đây, khi đó bạn sẽ thấy chỉ cần mắt bạn lướt qua sẽ nhìn ra ngay code ở đâu có bug.

• Code của mình - code đến đâu làm theo coding convention đến đấy.
• Code của người khác - cóp vào format lại theo chuẩn coding convention của project trước đã, rồi làm gì thì làm.

Nhớ kỹ: coding convention chỉ có một là theo 100%, hai là không theo. Theo 99% mà 1% còn lại freestyle thì cũng vô nghĩa.

Tôi hoàn toàn không phản đối các bạn lên google search khi gặp bug. Cũng không cấm các bạn dùng code của người khác cho việc của mình. Cái tôi phản đối là việc copy code của người khác vào mà hoàn không hiểu đoạn code đó cụ thể nó làm cái gì.

“Good Artists Copy; Great Artists Steal”

~Theo lời của Steve Jobs thì là lời của Pablo Picasso. Đặc điểm chung của các bạn mới vào nghề là khi cóp code vào thường chạy thử đã, nếu chạy thì ok việc đã xong, ta nhảy sang làm việc khác. Nếu có lỗi xảy ra mới đọc tiếp xem có khả năng sửa chữa gì không. Đây là một cách làm việc cực kỳ ấu trĩ và thiển cận. Trong phần lớn các trường hợp thì cùng lắm khoảng 1 tháng sau các bạn rồi lại phải quay lại với chỗ code lạ hoắc đó, vì có bug phát sinh. Bấy giờ thậm chí không còn hiểu nổi chỗ này lúc đó mình đang muốn cái gì, nói gì đến việc mò xem code đó sai ở đâu? Nếu một ngày tự nhiên có thanh niên lạ hoắc, mặt đầy sẹo tay cơ bắp lưng đeo ba lô vô duyên vô cớ gõ cửa nhà bạn xin ngủ nhờ qua đêm “Em chỉ ngủ nhờ thôi anh yên tâm hihi” thì các bạn có yên tâm mà cho thanh niên đấy ngủ nhờ không? Thế thì vì lý do gì bạn tin tưởng 1 đoạn code do 1 người mà bạn hoàn toàn không biết viết nên, cóp nó vào trong code của mình và không bao giờ ngó đến nữa, mà vẫn tin tưởng rằng mình có thể trở thành lập trình viên giỏi? Có 2 lý do chính để đọc kỹ bất cứ đoạn code nào bạn chuẩn bị cóp vào project trước khi sử dụng nó:

1. Để đảm bảo đoạn code đó chỉ làm những gì nó nói: Có rất nhiều câu chuyện các thanh niên lên mạng hỏi, gặp phải 1 đứa ngẫu hứng vứt cho đoạn code phá hoại. Thanh niên hào hứng đem về paste vào project chạy thử (vâng, đúng như bạn đang làm ấy ạ), kết quả là toàn bộ dữ liệu đi tong, khóc lóc bấy giờ đã muộn. Thằng kia “Ơ tao cũng chỉ trêu vui thôi, ai ngờ mày ngu vậy?”
2. Để học: Bạn đang gặp vấn đề, có người giúp bạn giải quyết nó. Đây là bài học thực tiễn vô cùng quý giá. Hãy đọc những dòng code đó, cố gắng hiểu xem nó nghĩa là gì. Vấn đề của bạn đã được người đó giải quyết như thế nào.Nghĩ xem có cách nào sửa đổi, cải tiến nó để phù hợp với tình huống cụ thể của mình không.

Biến code của người khác thành của mình. Hôm nay bạn phải hỏi họ vấn đề này, thì hãy đảm bảo ngày mai bạn sẽ là người trả lời. Việc nắm vững từng dòng code mà mình viết ra là vô cùng quan trọng. Nó trực tiếp ảnh hưởng đến tốc độ giải quyết vấn đề của bạn khi có bug xảy ra hoặc khi yêu cầu dự án thay đổi. Khi bạn thực sự đã hiểu từng dòng code làm gì, thì tư duy của bạn có thể tập trung giải quyết vấn đề theo phương pháp loại suy đơn giản, thay vì băn khoăn lạc lõng không biết đi về hướng nào. Điều đó cũng nghĩa là: nếu bạn tìm thấy một đoạn code hứa hẹn giải quyết được vấn đề của mình, nhưng bạn đọc không hiểu lắm, thì tốt nhất là đừng dùng nó. Đống code không-hiểu-lắm đấy sẽ đem lại cho bạn hậu quả thê thảm hơn nhiều những gì bạn đang mong nó giải quyết. 3 bước để biến code người khác thành code của mình:

1. Copy vào project, format lại ngay theo coding convention của project.
2. Đọc kỹ để hiểu đoạn code đó cụ thể làm những gì, đảm bảo nó làm đúng việc mà nó nói. Chạy thử, fix bug nếu cần.
3. Thay đổi, cải tiến, chỉnh sửa đoạn code đó để phù hợp với hoàn cảnh project của mình.

Đảm bảo 3 bước này xong, code đó đã là code của bạn. Sau này chắc chắn sẽ đến lúc bạn phải quay lại với nó: vì có bug, vì yêu cầu dự án thay đổi, hoặc cần optimize performance… Nhưng khi đó bạn đã là chủ nhân của nó rồi. Đọc phần 2 tại đây  

Tôn Hồng Đức

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