Bài viết hướng tới độc giả là các bạn trẻ đang học lập trình, cũng như các bạn muốn trở thành lập trình viên giỏi dù mới vào nghề muốn trau dồi kỹ năng bản thân.
Có thể các bạn là sinh viên đang đi học, thấy project kỳ nào làm ra cũng rõ lắm bug, điểm thì lẹt đà lẹt đẹt mãi không khá được?
Hoặc có thể bạn mới đi làm, cuối tuần đáng lẽ ở nhà chơi game, đi xem phim với người yêu, thì lại bị chậm deadline, sếp bắt lên công ty ngồi code nốt?
Bạn bối rối, bạn loay hoay, không hiểu tại sao cùng là người với nhau, thằng ngồi cạnh bạn nó code nhoáy nhoáy nó rung đùi ngồi chơi, còn bạn thì trì trạc mãi hết ngày vẫn chưa xong cái gì cả?
Vậy có cách nào giải quyết tình trạng đấy không?
Thật ra là có đó.
Đọc tiêu đề nghe rất có mùi giật tít câu view phải không ạ? Nhưng hãy thử làm theo 1 trong số những điều tôi nói đến trong bài viết này, các bạn sẽ thấy sự khác biệt ngay-lập-tức.
“It’s not bragging if it’s true.”
Đây là bài viết hoàn toàn Tech và logic. Sẽ không có những lời khuyên về việc đặt đồng hồ buổi sáng, ngồi thiền tập yoga, tư thế chuẩn mực khi ngồi bàn hay công thức tính thời gian bạn nhìn máy tính bao nhiêu phút một ngày. Vì tôi không phải bác sĩ hay nhà báo, tôi là lập trình viên. Bạn thích sống thế nào là việc của bạn. Tôi chỉ đưa ra lời khuyên cho những lúc bạn ngồi code, và cả lý do logic tại sao dựa trên trải nghiệm của chính bản thân mình.
Tôi không thể biến bạn thành Bill Gates sau 1 đêm, cái này không ai làm được. Nhưng tôi có thể giúp bạn trở thành 1 thằng coder mỗi ngày đúng 6h tắt máy dắt xe đi về, đều như vắt chanh.
Vào bài ạ.
1. Luôn luôn tuân theo coding convention
“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.
2. Không copy paste code của người khác
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ó:
- Để đả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?”
- Để 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:
- Copy vào project, format lại ngay theo coding convention của project.
- Đọ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.
- 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.
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:
- 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.
- 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:
- 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.
- 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:
- Luôn luôn tuân theo coding convention
- Không copy paste code của người khác
- Luôn copy tên riêng thay vì viết tay
- 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
- 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!
(Theo http://techkids.vn)
No comments:
Post a Comment