trieu.dev.da
Nguyễn Thanh Triều
Sức mạnh của thói quen
Hàng ngày, tôi vẫn tự hỏi mình năng lực lập trình là do thứ gì quyết định? Có người học lập trình rất nhanh nhưng có người lại học rất chậm. Thông thường, người ta hay gọi cái đó là “ngộ tính tốt, ngộ tính chưa tốt” và cho qua.
Nhưng tôi thấy rõ ràng có những yếu tố quyết định đến việc học nhanh hay chậm.
Vài năm trước vào một lần nọ, tôi có xem màn hình của đồng nghiệp ngồi bên cạnh và thỉnh thoảng đi quanh phòng làm việc xem màn hình của những người khác nữa. Có một điều làm tôi thực sự ngạc nhiên. Người hay “nộp bài” chậm thì màn hình lại thường có xu hướng hiển thị stack trace (dùng cho đầu ra của web application).
Đồng nghiệp ngồi cạnh tôi thường lập trình theo quy trình dưới đây. Tôi không thống kê chi tiết, nhưng đại loại là vậy.
Ngay lập tức, tôi chỉ cho cậu ấy cách check syntax và cách chạy thử từng module. Dựa vào đó, tôi chỉ thêm cho cậu ấy cách viết những test code nhỏ cho phần logic nữa. Nhưng hình như cậu ấy vốn đã biết cả rồi.
Tuy nhiên, vì nghĩ là phiền phức nên cậu ấy đã bỏ qua.
Tôi hỏi tại sao lại phiền thì cậu ấy có hơi lúng túng, giải thích khá nhiều nhưng đại ý là “Đằng nào cũng phải hiển thị, nên xem nó hiển thị thế nào là nhanh nhất”.
Đây là vấn đề về thói quen. Ngày đó công ty tôi chưa có quy trình CI (continous integration) nên hầu như không ai có thói quen viết test cho code cả.
Về sau, quy trình CI được áp dụng, việc viết test cho code trở thành bắt buộc. Tuy nhiên khi đó thì sau khi hiển thị ngon hết rồi cậu ta mới viết, với một thái độ không lấy gì làm vui vẻ cho lắm.
Quy trình phía trên của cậu ấy, do chạy code sau khi đã ghép nên màn hình sẽ hiện một đống lỗi rất phức tạp làm cho công việc kéo dài ra. Cậu ta dường như không quan tâm đến chuyện đó mà có khi cũng chẳng đọc lỗi nữa.
Cậu ấy không quen test từng phần một, mà sau khi ghép code sẽ khó test hơn rất nhiều.
Quy trình vốn sinh ra để tăng năng suất, bây giờ do thói quen của người làm việc, thành ra lại làm giảm năng suất.
Thói quen xấu
Gần đây, tôi có pair programming với vài kĩ sư trẻ. Một ngày tôi làm với họ vài tiếng, chiếm phần lớn thời gian ở công ty của tôi.
Tôi sẽ giới thiệu vài thói quen xấu của họ mà trong khi làm việc tôi đã phát hiện và nhắc nhở.
Ít đọc code
Tùy từng project mà thời gian đọc code khác nhau, nhưng nhìn chung thời gian đọc code luôn chiếm tỉ lệ lớn. Cách phân bố thời gian thường thấy là 80% đọc, 20% viết. Đọc code là bắt buộc để có thể hiểu được những phần liên quan, và hiểu framework.
Đối với những kĩ sư mà công việc hay bị trục trặc, không tiến triển, tôi thấy tỉ lệ thời gian họ dành cho việc đọc code là rất thấp.
Một ví dụ là có một cậu định sử dụng chức năng có trong framework thì bị lỗi. Tôi nói với cậu ấy là ở framework đang hiển thị lỗi sai đầu vào.
Tuy nhiên cậu ấy sau đó không hề xem chỗ tôi bảo trên framework.
Vậy thì cậu ấy làm gì?
Cách sửa
Tôi chỉ cho cậu ấy cách tìm đoạn bị sai tương ứng trên framework. Đồng thời, tôi bảo cậu ấy đọc xem đoạn ấy xử lí cụ thể như thế nào và kết luận tại sao code không chạy.
Vấn đề tâm lí
Tôi hỏi tại sao cậu ấy không đọc code của framework thì cậu ấy trả lời rằng “Nhìn phức tạp lắm, với lại em muốn làm xong sớm”. Tôi cũng công nhận là nội dung bên trong framework phức tạp thật, và đúng là rất khó để nắm được tổng thể.
Tuy nhiên bằng cách nghiên cứu nó, kiến thức về ngôn ngữ và khả năng đọc hiểu thư viện sẽ tăng lên, trình độ bản thân sẽ tăng lên.
Tôi đã cho cậu ấy trải nghiệm việc phá bỏ rào cản tâm lí đó, ngồi nghiên cứu code sẽ khiến vấn đề được giải quyết nhanh như thế nào.
Vì những lẽ ở trên, tôi nghĩ là người hướng dẫn cũng không nên nói những câu đại loại như “Phần này không hiểu cũng được”, “Đừng đọc nhiều làm gì, cứ cho chạy đi đã” - điều đó cũng rất quan trọng.
Tôi luôn nghĩ : giới hạn trưởng thành của bạn cao đến mức nào, phụ thuộc vào việc bạn hiểu code sâu đến mức nào.
Không test riêng những đoạn xử lí phức tạp
Tôi đã từng nói ở bài viết trước là việc chia nhỏ các hàm rất quan trọng. Tại sao lại phải chia? “Vì như thế thì sẽ nhàn hơn”. Tuy nhiên đối với người chưa thuần thục thì lại cảm thấy như thế là “khổ hơn”.
Ví dụ :
function process(list){
for(var i=0,l=list.length;i<l;i++){
...
// viết cái gì cần xử lí
}
...
// xử lí thêm gì nữa thì viết vào đây
}
Hàm có cấu trúc như thế này nghĩa là muốn thực hiện xử lí riêng từng phần một. Người chưa thuần thục thường có xu hướng cứ thế viết những gì muốn xử lí vào những chỗ comment ở trên.
Nhưng đúng ra nó phải là như thế này :
function process(list){
var next = []:
for(var i=0,l=list.length;i<l;i++){
...
var elem = doSomethingForElement(list);
if ( elem ) {
next.push(elem):
}
}
...
if( next.length == 0 ){
return doSomethingWhenNoResponse(args);
}
...
}
function doSomethingForElement(){
#viết những gì cần xử lí
}
function doSomethingWhenNoResponse(){
#viết những gì cần xử lí
}
Những phần muốn xử lí viết tách ra ngoài, độc lập (gọi là sprout method). Làm như thế sẽ tránh cho hàm gốc bị phức tạp hóa, và giúp ta test được từng xử lí một.
Cách sửa
Tôi cho họ làm quen với quy trình là trước khi động tay vào hàm gốc thì hãy tách những gì mình cần xử lí ra thành những hàm rời, sau đó viết và test những cái rời trước. Sau đó họ đã thấy kết quả là việc giải quyết lỗi phát sinh trở nên nhanh như thế nào. Đồng thời, tôi giúp họ ý thức đầu ra đầu vào là gì, phần mình làm ảnh hưởng các phần khác như thế nào.
Vấn đề tâm lí
Nguyên nhân của chuyện cảm thấy việc chia nhiều hàm là khổ chính là từ suy nghĩ “muốn xong sớm” mà ra. Họ nghĩ “Sau này có lỗi thì chỉ cần xem lỗi ở đâu rồi sửa là xong” nên họ thấy chia nhiều hàm rất là “phức tạp hóa vấn đề”, chỉ là chuyện “nếu thừa thời gian thì làm”.
Tuy nhiên, nếu gộp hết tất cả thành 1 hàm rồi chạy, thì việc hiểu code sẽ rất khó và cái vòng luẩn quẩn “chạy và lỗi” sẽ kéo dài, lỗi lại còn rất nặng. Như thế mới chính là đang làm mất thời gian.
Cũng như trong Hình học để giải bài toán ta hay phải kẻ đường phụ. Việc học cách kẻ đường đó như thế nào là một điều rất quan trọng.
Không kiểm tra quy trình làm việc của bản thân
Như phần đầu tôi đã nói, thói quen chính là sức mạnh. Chúng ta cần phải có một quy trình làm việc nhanh nhất có thể, hướng đến mục tiêu là tự động hóa.
Từ hôm pair programming, tôi mới nhận ra một cậu hay ngồi nhìn code chằm chằm sau khi viết. Tôi hỏi là đang làm gì thế thì cậu ấy bảo “Em đang kiểm tra”. Cậu ấy đúng là đang kiểm tra từng dòng code một, xem mình có viết sai gì không.
Tôi bảo cậu ấy trước tiên hãy check syntax đi thì cậu ấy hỏi “Check syntax nghĩa là sao ạ?”. Sau khi tôi chỉ cậu ấy cách làm thì cậu ấy sau đó cứ liên tục hỏi tôi “Câu này đúng chưa anh?”, “Thế này được chưa?”.
Tôi trả lời là trước hết cứ tự mình kiểm tra đi đã, cậu ấy không hiểu ý tôi là gì.
Tôi đã nhận ra rằng ngoài quy trình check xem code của mình sau khi build và cho chạy thật đã ngon chưa, họ không có thêm một quy trình nào khi làm việc cả. Unit test vốn là thứ được sinh ra để xem từng phần có hoạt động chính xác không. Nếu trong khi làm không chuẩn bị trước, không phải là người có thói quen vừa làm vừa test (test first), thì sau này làm unit test sẽ rất mệt.
Cách sửa
Phần code dùng để check syntax hãy để riêng ra editor và dùng thường xuyên. Nếu cần thiết, cứ khi save code là tự động cho chạy luôn để test.
Vì cậu ấy dùng editor là vim nên cần cài plugin như quickrun hay syntastic.
Các class và các hàm cũng vậy, ở đâu cũng được, nhưng cần phải tạo môi trường để kiểm tra từng cái một. Nếu kiểm tra thấy ngon rồi, thì hãy lưu lại vào một file test.
Đó là quy trình mà tôi muốn cậu ấy thực hiện. Trước khi hỏi “Thế này được chưa” thì hãy làm tất cả những việc trên đã.
Khi đã quen rồi, nên tạo một môi trường CI dựa trên cách dùng debug hoặc fswatch. Mỗi khi save code thì cho chạy luôn cái CI đó để test là tốt nhất.
Vấn đề tâm lí
Vấn đề về môi trường như bên trên có vẻ như liên quan đến kiến thức chứ không liên quan đến tâm lí. Tuy nhiên sau khi phân tích, tôi thấy nó liên quan đến nhận thức về 2 khái niệm thường gặp khi lập trình là “code chuẩn” và “code lỗi mà không biết vì sao”.
Một thực tế là, không phải chỉ có duy nhất một “code chuẩn”.
Tuy nhiên, người hay copy paste thường có xu hướng nghĩ rằng : copy paste mà cũng không chạy được thì chắc là do mình thao tác sai chỗ nào đó, copy paste bị thiếu chỗ nào đó và thường có thói quen ngồi tìm kiếm những cái đó.
Vì lí do đó, code của họ sau khi viết xong chẳng khác nào mật mã ngoài hành tinh, và họ sẽ phải tìm lỗi sai trong đống mật mã đó. Phần mà họ tự viết ra cũng dựa trên những đoạn copy paste, mà sau này rồi cũng sẽ trở thành thứ mà họ không thể tự lí giải nổi.
Tâm lí của họ là luôn nghĩ việc đọc hiểu và kiểm tra từng dòng một, kém năng suất hơn việc copy paste cả một đoạn rất nhiều.
Hàng ngày, tôi vẫn tự hỏi mình năng lực lập trình là do thứ gì quyết định? Có người học lập trình rất nhanh nhưng có người lại học rất chậm. Thông thường, người ta hay gọi cái đó là “ngộ tính tốt, ngộ tính chưa tốt” và cho qua.
Nhưng tôi thấy rõ ràng có những yếu tố quyết định đến việc học nhanh hay chậm.
Vài năm trước vào một lần nọ, tôi có xem màn hình của đồng nghiệp ngồi bên cạnh và thỉnh thoảng đi quanh phòng làm việc xem màn hình của những người khác nữa. Có một điều làm tôi thực sự ngạc nhiên. Người hay “nộp bài” chậm thì màn hình lại thường có xu hướng hiển thị stack trace (dùng cho đầu ra của web application).
Đồng nghiệp ngồi cạnh tôi thường lập trình theo quy trình dưới đây. Tôi không thống kê chi tiết, nhưng đại loại là vậy.
- Viết code
- Lưu code
- Switch màn hình sang browser
- Reload
- Màn hình lỗi hiện ra
- Switch sang màn hình code luôn
Ngay lập tức, tôi chỉ cho cậu ấy cách check syntax và cách chạy thử từng module. Dựa vào đó, tôi chỉ thêm cho cậu ấy cách viết những test code nhỏ cho phần logic nữa. Nhưng hình như cậu ấy vốn đã biết cả rồi.
Tuy nhiên, vì nghĩ là phiền phức nên cậu ấy đã bỏ qua.
Tôi hỏi tại sao lại phiền thì cậu ấy có hơi lúng túng, giải thích khá nhiều nhưng đại ý là “Đằng nào cũng phải hiển thị, nên xem nó hiển thị thế nào là nhanh nhất”.
Đây là vấn đề về thói quen. Ngày đó công ty tôi chưa có quy trình CI (continous integration) nên hầu như không ai có thói quen viết test cho code cả.
Về sau, quy trình CI được áp dụng, việc viết test cho code trở thành bắt buộc. Tuy nhiên khi đó thì sau khi hiển thị ngon hết rồi cậu ta mới viết, với một thái độ không lấy gì làm vui vẻ cho lắm.
Quy trình phía trên của cậu ấy, do chạy code sau khi đã ghép nên màn hình sẽ hiện một đống lỗi rất phức tạp làm cho công việc kéo dài ra. Cậu ta dường như không quan tâm đến chuyện đó mà có khi cũng chẳng đọc lỗi nữa.
Cậu ấy không quen test từng phần một, mà sau khi ghép code sẽ khó test hơn rất nhiều.
Quy trình vốn sinh ra để tăng năng suất, bây giờ do thói quen của người làm việc, thành ra lại làm giảm năng suất.
Thói quen xấu
Gần đây, tôi có pair programming với vài kĩ sư trẻ. Một ngày tôi làm với họ vài tiếng, chiếm phần lớn thời gian ở công ty của tôi.
Tôi sẽ giới thiệu vài thói quen xấu của họ mà trong khi làm việc tôi đã phát hiện và nhắc nhở.
Ít đọc code
Tùy từng project mà thời gian đọc code khác nhau, nhưng nhìn chung thời gian đọc code luôn chiếm tỉ lệ lớn. Cách phân bố thời gian thường thấy là 80% đọc, 20% viết. Đọc code là bắt buộc để có thể hiểu được những phần liên quan, và hiểu framework.
Đối với những kĩ sư mà công việc hay bị trục trặc, không tiến triển, tôi thấy tỉ lệ thời gian họ dành cho việc đọc code là rất thấp.
Một ví dụ là có một cậu định sử dụng chức năng có trong framework thì bị lỗi. Tôi nói với cậu ấy là ở framework đang hiển thị lỗi sai đầu vào.
Tuy nhiên cậu ấy sau đó không hề xem chỗ tôi bảo trên framework.
Vậy thì cậu ấy làm gì?
- Nhìn chăm chú vào code của mình, ngẩn ngơ tìm chỗ sai.
- Nghiền ngẫm một đoạn code trên mạng để xem có nên copy paste không.
Cách sửa
Tôi chỉ cho cậu ấy cách tìm đoạn bị sai tương ứng trên framework. Đồng thời, tôi bảo cậu ấy đọc xem đoạn ấy xử lí cụ thể như thế nào và kết luận tại sao code không chạy.
Vấn đề tâm lí
Tôi hỏi tại sao cậu ấy không đọc code của framework thì cậu ấy trả lời rằng “Nhìn phức tạp lắm, với lại em muốn làm xong sớm”. Tôi cũng công nhận là nội dung bên trong framework phức tạp thật, và đúng là rất khó để nắm được tổng thể.
Tuy nhiên bằng cách nghiên cứu nó, kiến thức về ngôn ngữ và khả năng đọc hiểu thư viện sẽ tăng lên, trình độ bản thân sẽ tăng lên.
Tôi đã cho cậu ấy trải nghiệm việc phá bỏ rào cản tâm lí đó, ngồi nghiên cứu code sẽ khiến vấn đề được giải quyết nhanh như thế nào.
Vì những lẽ ở trên, tôi nghĩ là người hướng dẫn cũng không nên nói những câu đại loại như “Phần này không hiểu cũng được”, “Đừng đọc nhiều làm gì, cứ cho chạy đi đã” - điều đó cũng rất quan trọng.
Tôi luôn nghĩ : giới hạn trưởng thành của bạn cao đến mức nào, phụ thuộc vào việc bạn hiểu code sâu đến mức nào.
Không test riêng những đoạn xử lí phức tạp
Tôi đã từng nói ở bài viết trước là việc chia nhỏ các hàm rất quan trọng. Tại sao lại phải chia? “Vì như thế thì sẽ nhàn hơn”. Tuy nhiên đối với người chưa thuần thục thì lại cảm thấy như thế là “khổ hơn”.
Ví dụ :
function process(list){
for(var i=0,l=list.length;i<l;i++){
...
// viết cái gì cần xử lí
}
...
// xử lí thêm gì nữa thì viết vào đây
}
Hàm có cấu trúc như thế này nghĩa là muốn thực hiện xử lí riêng từng phần một. Người chưa thuần thục thường có xu hướng cứ thế viết những gì muốn xử lí vào những chỗ comment ở trên.
Nhưng đúng ra nó phải là như thế này :
function process(list){
var next = []:
for(var i=0,l=list.length;i<l;i++){
...
var elem = doSomethingForElement(list);
if ( elem ) {
next.push(elem):
}
}
...
if( next.length == 0 ){
return doSomethingWhenNoResponse(args);
}
...
}
function doSomethingForElement(){
#viết những gì cần xử lí
}
function doSomethingWhenNoResponse(){
#viết những gì cần xử lí
}
Những phần muốn xử lí viết tách ra ngoài, độc lập (gọi là sprout method). Làm như thế sẽ tránh cho hàm gốc bị phức tạp hóa, và giúp ta test được từng xử lí một.
Cách sửa
Tôi cho họ làm quen với quy trình là trước khi động tay vào hàm gốc thì hãy tách những gì mình cần xử lí ra thành những hàm rời, sau đó viết và test những cái rời trước. Sau đó họ đã thấy kết quả là việc giải quyết lỗi phát sinh trở nên nhanh như thế nào. Đồng thời, tôi giúp họ ý thức đầu ra đầu vào là gì, phần mình làm ảnh hưởng các phần khác như thế nào.
Vấn đề tâm lí
Nguyên nhân của chuyện cảm thấy việc chia nhiều hàm là khổ chính là từ suy nghĩ “muốn xong sớm” mà ra. Họ nghĩ “Sau này có lỗi thì chỉ cần xem lỗi ở đâu rồi sửa là xong” nên họ thấy chia nhiều hàm rất là “phức tạp hóa vấn đề”, chỉ là chuyện “nếu thừa thời gian thì làm”.
Tuy nhiên, nếu gộp hết tất cả thành 1 hàm rồi chạy, thì việc hiểu code sẽ rất khó và cái vòng luẩn quẩn “chạy và lỗi” sẽ kéo dài, lỗi lại còn rất nặng. Như thế mới chính là đang làm mất thời gian.
Cũng như trong Hình học để giải bài toán ta hay phải kẻ đường phụ. Việc học cách kẻ đường đó như thế nào là một điều rất quan trọng.
Không kiểm tra quy trình làm việc của bản thân
Như phần đầu tôi đã nói, thói quen chính là sức mạnh. Chúng ta cần phải có một quy trình làm việc nhanh nhất có thể, hướng đến mục tiêu là tự động hóa.
Từ hôm pair programming, tôi mới nhận ra một cậu hay ngồi nhìn code chằm chằm sau khi viết. Tôi hỏi là đang làm gì thế thì cậu ấy bảo “Em đang kiểm tra”. Cậu ấy đúng là đang kiểm tra từng dòng code một, xem mình có viết sai gì không.
Tôi bảo cậu ấy trước tiên hãy check syntax đi thì cậu ấy hỏi “Check syntax nghĩa là sao ạ?”. Sau khi tôi chỉ cậu ấy cách làm thì cậu ấy sau đó cứ liên tục hỏi tôi “Câu này đúng chưa anh?”, “Thế này được chưa?”.
Tôi trả lời là trước hết cứ tự mình kiểm tra đi đã, cậu ấy không hiểu ý tôi là gì.
Tôi đã nhận ra rằng ngoài quy trình check xem code của mình sau khi build và cho chạy thật đã ngon chưa, họ không có thêm một quy trình nào khi làm việc cả. Unit test vốn là thứ được sinh ra để xem từng phần có hoạt động chính xác không. Nếu trong khi làm không chuẩn bị trước, không phải là người có thói quen vừa làm vừa test (test first), thì sau này làm unit test sẽ rất mệt.
Cách sửa
Phần code dùng để check syntax hãy để riêng ra editor và dùng thường xuyên. Nếu cần thiết, cứ khi save code là tự động cho chạy luôn để test.
Vì cậu ấy dùng editor là vim nên cần cài plugin như quickrun hay syntastic.
Các class và các hàm cũng vậy, ở đâu cũng được, nhưng cần phải tạo môi trường để kiểm tra từng cái một. Nếu kiểm tra thấy ngon rồi, thì hãy lưu lại vào một file test.
Đó là quy trình mà tôi muốn cậu ấy thực hiện. Trước khi hỏi “Thế này được chưa” thì hãy làm tất cả những việc trên đã.
Khi đã quen rồi, nên tạo một môi trường CI dựa trên cách dùng debug hoặc fswatch. Mỗi khi save code thì cho chạy luôn cái CI đó để test là tốt nhất.
Vấn đề tâm lí
Vấn đề về môi trường như bên trên có vẻ như liên quan đến kiến thức chứ không liên quan đến tâm lí. Tuy nhiên sau khi phân tích, tôi thấy nó liên quan đến nhận thức về 2 khái niệm thường gặp khi lập trình là “code chuẩn” và “code lỗi mà không biết vì sao”.
Một thực tế là, không phải chỉ có duy nhất một “code chuẩn”.
Tuy nhiên, người hay copy paste thường có xu hướng nghĩ rằng : copy paste mà cũng không chạy được thì chắc là do mình thao tác sai chỗ nào đó, copy paste bị thiếu chỗ nào đó và thường có thói quen ngồi tìm kiếm những cái đó.
Vì lí do đó, code của họ sau khi viết xong chẳng khác nào mật mã ngoài hành tinh, và họ sẽ phải tìm lỗi sai trong đống mật mã đó. Phần mà họ tự viết ra cũng dựa trên những đoạn copy paste, mà sau này rồi cũng sẽ trở thành thứ mà họ không thể tự lí giải nổi.
Tâm lí của họ là luôn nghĩ việc đọc hiểu và kiểm tra từng dòng một, kém năng suất hơn việc copy paste cả một đoạn rất nhiều.