Hôm trước, mình có viết một bài để “chửi nhẹ” những bạn lười học, lúc nào cũng hỏi “Có nên học cái này cái kia không?”

Tuy vậy, mình cũng biết những bạn rất thích công nghệ, ham học hỏi, thích tìm hiểu công nghệ mới.

Tuy vậy, các bạn này lại dễ sa đà vào tình trạng biết rộng mà không sâu, chỉ học và biết toàn những kiến thức bề mặt. (Thấy khổ chưa, lười học cũng bị chửi, mà học nhiều thứ quá cũng bị thằng Code Dạo nhắc nhở!)

Nguyên nhân dẫn đến chuyện này là các bạn chỉ biết hỏi Làm sao để làm (How), mà quên hỏi Tại sao phải làm (Why).

Do vậy, hôm nay chúng ta cùng nói về tầm quan trọng của việc đặt câu hỏi nhé!

Khi bắt đầu học, ta thường hỏi Làm Sao (How)

Khi mới bắt đầu tìm hiểu một công nghệ, mình thường khuyên các bạn học và cố gắng sử dụng công nghệ để build một project nhỏ.

Lúc này, chúng ta hay đặt những câu hỏi kiểu:

• Làm sao để paging bằng AngularJS
• Làm sao viết RestAPI bằng Rail, AngularJS
• Làm sao để viết app chat bằng React và React-Native

Những câu hỏi này không có gì sai! Khi mới làm quen và tiếp cận một ngôn ngữ/công nghệ, những câu hỏi này giúp bạn làm quen với chúng, dần dần nâng cao khả năng của mình!

Tuy nhiên, nếu chỉ biết hỏi những câu như vậy, khả năng của bạn sẽ chỉ ở mãi mãi chỉ ở tầm junior, middle mà thôi! Khi đã thành thục một ngôn ngữ, muốn tiến xa hơn, chúng ta nên bắt đầu hỏi những câu hỏi “Vì sao”!

Vì sao lại phải hỏi “Vì sao”?

Đọc đến đây, hẳn bạn sẽ thắc mắc “Tại sao ta phải đặt câu hỏi Tại sao”? Chúc mừng, bạn đã tiến bộ hơn tí rồi đấy hihi.

Giả sử bạn đã thành thục React, thành thục Angular. Thay vì hỏi Làm sao, các bạn nên bắt đầu có những câu hỏi Tại sao:

1. Tại sao người ta tạo ra Angular? Tại sao phải dùng Angular?
2. Tại sao các framework mới lại dùng chung với Webpack?
3. Tại sao phải dùng React và Redux? Tại sao chúng lại hot?

Bạn có thấy những câu hỏi Why này có khác gì How không?

• Khi hỏi How, bạn có một vấn đề, bạn đang cần tìm ra giải pháp.
• Khi hỏi Why, bạn đã có giải pháp, và bạn muốn hiểu rõ vấn đề là gì? Giải pháp đó có giải quyết được hay không.

Why giúp bạn tìm ra vấn đề, thay vì tìm ra giải pháp

Khi thử trả lời cho 3 câu hỏi Why phía trên, bạn sẽ dần nhìn thấy nhiều vấn đề:

1. Angular có Dependency Injection nên ta có thể chia JavaScript ra nhiều module nhỏ, quản lý code tốt và dễ test hơn.
   • Angular có data binding giúp ta ít viết code để trình bày dữ liệu.
   • (Vào thời điểm Angular ra đời, vài framework trước đó cũng giải quyết vấn đề tương tự nhưng chưa tốt bằng).
2. Sử dụng Webpack giúp ta có thể phân tách JavaScript thành nhiều module nhỏ hơn, transpile code và build dễ dàng hơn.
3. React và Redux:
   • React giúp ta tách các thành phần của trang Web thành nhiều thành phần nhỏ gọi là module, có thể tái sử dụng. Ta không cần trực tiếp xử lý HTML DOM mà React sẽ làm hết!
   • Redux dùng chung với React, giúp giúp quản lý state của ứng dụng web một cách rõ ràng, dễ hiểu, dễ debug
   • Giải thích kĩ sẽ khá lòng vòng nên các bạn vào đây xem cho rõ nhé: http://almerosteyn.com/2016/08/redux-explained-again

 

Mỗi ngôn ngữ/framework ra đời là để giải quyết một vấn đề nào đó. Học một ngôn ngữ/công nghệ không phải chỉ là học cách dùng nó!

Chính những vấn đề cần giải quyết (file structrue, state management) cùng với cách chúng giải quyết vấn đề (dependency injection, reactive programming, unit test) mới là thứ bạn cần học!

Những kiến thức này rất sâu sắc và hữu dụng. Nó thuộc dạng nền tảng nên rất ít thay đổi, có thể tái sử dụng khi bạn học những ngôn ngữ, công nghệ mới.

Làm sao (How) vs Vì sao (Why)

Nới rộng ra, việc hỏi Why thay vì How cũng sẽ giúp bạn đạt nhiều thành công hơn trong sự nghiệp.

Như mình đã nói từ ban đầu, ở tầm junior, công việc của bạn chỉ là … code. Khi nhận được requirement, các bạn sẽ phải hỏi How để biết cách làm sao viết code cho đúng để hoàn thành được yêu cầu.

Tuy nhiên, ở cấp độ senior, hoặc team leader, đôi khi chúng ta phải đặt câu hỏi Why?

• Tại sao lại có yêu cầu này?
• Tại sao phải dùng công nghệ này cho dự án?

Đặt ra những câu hỏi này, ta sẽ hiểu rõ được bản chất vấn đề, từ đó đưa ra cách giải quyết tốt hơn, phù hợp hơn.

Tư duy How vs Why khi giải quyết vấn đề

Ví dụ, đây là một vấn đề mình từng gặp khi còn làm trong team Lancaster bên UK:

Yêu cầu là: Optimize một API tạo report và gửi email cho người dùng. API này chạy khá chậm, tận 10 phút mới xong!

Đầu tiên mình hỏi How, hướng tiếp cận của mình là:

1. Làm sao để optimize API này?
2. Mở code ra, bên dưới nó dùng stored producedure SQL, sau đó gửi mail kiểu synchonous.
3. Mình optimize một số query, đánh index cho một số column, sửa code gửi email thành asynchonous. Kết quả query sẽ được lưu vào cache để lần sau chạy nhanh hơn.

Cách này có gì sai không? Không sai, nó giải quyết được vấn đề API chậm, chỉ tốn chút ít thời gian code.

Tuy nhiên, sau đó mình bắt đầu hỏi Why để hiểu rõ vấn đề hơn:

1. Tại sao API lại chạy chậm? Tại sao phải optimize API này?
2. Đem vấn đề này đi hỏi bác team leader, mình nhận được câu trả lời là:
   • Vào mỗi cuối tháng, người dùng lại bấm vào nút Generate Report.
   • Web chạy hoài, chạy hoài khiến họ cảm thấy lâu nên mới phàn nàn team dev.
3. Ơ Rê Ka, tìm ra vấn đề rồi! Lúc này, mình có thể đưa ra 2 giải pháp:
   1.  Thay vì để web chạy hoài, ta hiển thị cho user “Generating Report”, sau đó cho task chạy ngầm, gửi mail sau khi xong
   2. Không cần chờ người dùng click vào, ta tạo 1 job chạy ngầm dưới hệ thống, tự động gửi mail cho user vào mỗi cuối tháng.
4. Sau đó mình và team quyết định dùng cách 2, chỉ cần tạo 1 cron job để tạo và gửi email cho user.
5. Task này chạy và đưa kết quả vào cache nên khi user xem lại kết quả trên Web, họ sẽ thấy kết quả ngay lập tức từ cache

Các bạn thấy đấy, nhờ hỏi Why mà mình hiểu rõ bản chất vấn đề hơn, cải thiện được hệ thống nữa.

Nếu mình chịu khó hỏi Why trước khi hỏi How thì chắc là không cần phí công sức để optimize luôn! Người dùng chỉ cần đọc email report, họ không cần click tay rồi chờ 10 phút làm gì!

Chốt

Tất nhiên, không phải trong môi trường làm việc nào bạn cũng có thể hỏi Why thay vì How.

Giả sử làm ở công ty outsource, đưa gì làm nấy, mỗi lần có task bạn cứ hỏi Why why sẽ dễ khiến team leader và đồng đội bực mình :))

Tuy vậy, khi làm việc trong các công ty product, cho các start-up, cách suy nghĩ Why thay vì How sẽ giúp bạn xác định được vấn đề tốt hơn, tạo ra sản phẩm tốt nhất cho người dùng!

 

Đấy, mình chỉ chém gió nhẹ nhàng vậy thôi, bạn nào có hứng thú xem thêm thì cứ ghé Youtube Channel của Tôi Đi Code Dạo nhé! Có những thứ chém gió hay ho bổ ích hơn nhiều :3.