Nếu bạn đã thực sự là 1 lập trình viên, bạn sẽ luôn tìm kiếm muôn vàn “điều mới lạ” cũng như liên tục giải quyết các vấn đề mới khi bắt tay làm dự án dù to hay nhỏ. Do đó nhiều công ty công nghệ yêu cầu các bạn Coder phải có khả năng đọc hiểu tiếng anh tốt, tự tìm hiểu,.. Bài viết này đúc kết kinh nghiệm từ tác giả trong việc “làm thế nào để giải quyết 1 vấn đề”.
Nào, mời bạn đọc cùng xem!
1 . Cách Tận Dụng các Tutorial Trên Internet
Thông thường để dễ tiếp cận 1 vấn đề mới, ta sẽ đọc tutorial và tập trung tìm hiểu các khái niệm, đọc các đoạn mã và cố gắng gõ lại chúng thay vì copy – paste.
Cách này không sai, nhưng đừng chỉ dừng lại ở việc đọc tài liệu, gõ lại chúng mà hãy dùng nó (từ những gì đã học) làm 1 cái gì đó có ý nghĩa hơn. Hay đơn giản là phát triển, sửa đổi lại project bạn đang xem trong tutorial.
2. Chia Nhỏ Vấn Đề:
Cái này gần như là cái quan trọng nhất trong bài viết này, mình muốn nhấn mạnh với các bạn. Khi thực sự đào sâu vào project, bạn sẽ thấy việc chia nhỏ vấn đề ra sẽ dễ code và quản lý hơn, hay rộng hơn là chia nhỏ tính năng.
Bạn có thói quen ghi chú công việc cần làm trong ngày không? Nếu có thì đó là 1 thói quen tốt. Mình thường ghi 1 vài task nhỏ dễ làm trong ngày và cố gắng hoàn thành nó trước, điều đó giúp mình có thời gian sắp xếp cho những việc “khó hơn” và quan trọng là có động lực để hoàn thành mấy task lớn lớn đã đặt mục tiêu trước đó. Điều này cũng đúng với việc viết code. Chia nhỏ code giúp bạn dễ quản lý và đạt được nhiều “điểm thăng” thú vị hơn.
Bạn nên dành nhiều thời gian để chia nhỏ vấn đề, tốn thời gian đó nhưng bạn sẽ thấy ngay hiệu quả, cụ thể điều này giúp bạn viết ít mã hơn.
Mình từng điên đầu khi lộn tùng phèo trong đống code “hầm bà lằng”, mình trước đây code cũng “xiềng” lắm nhưng giờ đỡ rồi :v
Những ngày đầu đi làm công ty mình toàn bị nói kiểu “cầm đèn chạy trước ô tô”, “không biết gì cũng lên stackoverflow hỏi”, “không có định hướng trước khi code”, kiểu ngu học đấy. Để dễ hình dung khi bạn giải một câu đố ghép hình, bạn thường giải quyết những ảnh ghép bên ngoài trước, sau đó giải các phần còn lại của bức tranh. Điều điên rồ là bạn cố gắng ghép các mảnh lại với nhau theo cách hoàn toàn ngẫu nhiên với 1 niềm tin “lắp thử coi nó có hoạt động không”. Điều này cũng đúng với viết code! Xây dựng mọi thứ một cách có phương pháp thay vì chỉ đoán mọi thứ 1 cách ngẫu nhiên – suy nghĩ thông qua giải pháp cho toàn bộ tính năng sau đó chia nhỏ vấn đề thay vì chỉ viết mã mà không có định hướng trong đầu.
3. Rút Ra Những Vấn Đề Tương Tự
Cái này cũng rất quan trọng nha, thông thường bạn đã có chút ít kinh nghiệm thì hãy sử dụng kiến thức đó, sẽ luôn có những vấn đề được liên kết với nhau. Và may thay, việc giải quyết vấn đề A tương tự vấn đề B cho phép trí não bạn phát triển hơn, cả về tư duy lẫn sáng tạo. Hãy clone ngay 1 project nho nhỏ trên Github đủ sức bạn và tiếp tục phát triển nó theo ý bạn, bạn sẽ rút ra những vấn đề tương tự theo 1 cách nhanh đáng kinh ngạc đấy!
4. Tin Tưởng Vào Bản Thân
Câu này nghe hơi buồn cười, nhưng chắc a/e đang hiểu theo 1 cách khác. Tin tưởng bản thân ở đây là thử tin tưởng khả năng của bạn để thử viết code mà không cần trợ giúp lúc đầu – bạn có mã giả và đã đọc qua Tutorial trước đó. Mình ví dụ case mới ra trường đang thực tập hoặc thử việc 2 tháng luôn nha. Khoảng thời gian này đúng là ác mộng… Đừng lo, bạn có sự giúp sức của Google, Stackoverflow,… bla bla,.. Đây là bước khá quan trọng vì với những bạn Coder mới ra trường thường hay sợ sai, sợ bị đuổi,.. nhưng hãy tự tin và viết code.
Không công ty nào cấm các bạn search Google khi làm việc, nhất là trong khoảng thời gian thử việc 2 tháng. Họ cũng không mong bạn làm được việc gì lớn trong 2 tháng đó. Đây là khoảng thời gian vô cùng áp lực nếu bạn không được training,mỗi ngày lên được giao task tự làm, tự gỡ lỗi theo phương pháp “ocs chos” nhất có thể. Nhưng lúc đi làm mình thấy rằng mấy ông trong công ty sẽ xem cách các bạn giải quyết vấn đề: nếu bạn viết mã sai và điên cuồng fix mà không suy nghĩ sao nó lại không hoạt động hay debug mà không biết mình debug cái gì sẽ là 1 điểm trừ lớn đấy. Hạn chế hỏi những câu ngớ ngẩn nha. 🙂
5. Kinh Nghiệm Search Google
Đù mớ, tau thấy thằng này hơi khùng khi chém câu này rồi nha. Nhưng không, thiệt sự là search Google cũng là 1 nghệ thuật đó anh em. :v
Dev trên thế giới dành luôn 1 từ cho việc này “Googling”. Google là công cụ cứu cánh cho dev – được ví như 1 công cụ hợp lệ trong bất cứ trường hợp nào. Trong thực tế, nếu không có Google hay Stackoverflow thì dev trở thành người tối cổ ngay, đa số trường hợp Googling là ok nhưng đôi khi nó có thể gây hại cho bạn. Mình thấy lỗi phổ biến nhất a/e mới học lập trình là thay vì Google 1 lỗi, 1 vấn đề cụ thể thì lại search kiểu toàn bộ vấn đề, rất chung chung. Googling: “reverse string in Python” sẽ cho bạn câu trả lời ngay vấn đề mà bạn đang tìm kiếm – nhưng bạn sẽ không tự mình giải quyết vấn đề và bạn sẽ không thu được nhiều kinh nghiệm. Thay vào đó, nếu bạn nhận được thông báo lỗi trong khi bạn đang cố gắng thử, Googling! Hoặc, nếu bạn quên cú pháp của một vòng lặp for, hãy Googling…
Ngoài ra, đừng luôn phụ thuộc vào Google! Thay vào đó, hãy tin tưởng vào bản thân. Đương nhiên là không phải tin tưởng mù quáng rồi. Ví dụ bạn đang thử 1 vấn đề và gặp chút rắc rối khi tính “trung bình cộng của 1 mảng các số để tìm ra danh sách số chẵn nhỏ hơn 69”. Bạn gặp chút rắc rối trong vòng lặp và điều kiện vì kết quả in không đúng yêu cầu, đừng ngại ngần đọc lại mã của bạn. Đặt breakpoint ở những vị trí bạn nghĩ rằng “có gì đó sai sai ở đây”, console kết quả ra và từng bước gỡ lỗi.
Mình đã từng rất nhiều lần làm như vậy và đôi khi cảm giác thích lắm, kiểu như nó đơn giản như vậy là sao không nghĩ ra. Bạn nên nhớ rằng chút đơn giản đó chính là chông gai bất kỳ lập trình viên nào cũng đã trải qua. Và nó là hành trang vững chắc cho những khó khăn lớn hơn sắp tới. Đừng ngại ngần nhé a/e!!
Eureka! Eureka!
6. Test case – tại sao không?
Để hiểu tại sao phải dùng test case, bạn cần hiểu rõ tác dụng của nó
- Thất bại, thử lại – lại thất bại => điên.
- Thất bại nhanh qua test case => bớt điên.
Kiểu như có test case bạn sẽ biết code có ý thức hơn, biết được ngay lỗi của mình ở đâu để sửa ngay chứ không để càng chục ngàn lỗi rồi sửa thì nản. Chưa kể fix cái này lòi cái kia.
Lỗi, thất bại, bug,… là chuyện thường tình ở huyện devs. Nhưng làm sao để rút ngắn số lần thất bại? Thế giới sản sinh ra nhiều mô hình quản lý dự án như Agile, Scrum nhưng mình thấy nó khác biệt ở khâu kiểm thử phần mềm. Mình cũng từng làm việc ở 1 công ty công nghệ theo mô hình Waterfall và fall toàn tập khi deadline về.
Vì việc kiểm thử – tạo test case không được coi trong ở mô hình Waterfall cho nên khi deadline đến gần rất nhiều lỗi mà chủ yếu liên quan tới việc nhập liệu, kiểm thử điều kiện trong ứng dụng.
Mình thấy rằng 70-80% lỗi đến từ việc này, và nếu chúng ta biết vấn đề nằm ở đâu thì ta nên đặt trọng tâm vào nó. Khi đi làm việc tạo 1 sample input để test các trường hợp đầu vào là rất cần cần thiết. Bạn phải đảm bảo code hoạt động tốt với những test case đó.
- Điều gì xảy ra khi khách hàng nhấn nút trừ (-) ở nút tăng giảm số lượng đơn đặt hàng?
- Nếu khách hàng không nhập gì, khách hàng nhập chữ ở ô Sđt, khách hàng nhập tên đăng ký quá dài?
- Sẽ ra sao nếu khách hàng là những tay scan SQL Injection cố gắng chèn mã vào các ô nhập liệu với mục đích xấu?
Bạn cần thật chú ý với điều này, đây là điều quan trọng để giảm thiểu sai sót cũng như mất công debug lại khi chương trình của bạn trở nên cồng kềnh hơn.
7. Nghỉ mắt mỗi 2 tiếng / lần:
Khi bạn fix đống mã 1 năm trước bạn viết, bạn thầm tự trách bản thân rằng sao lúc đó mình ngu quá nhưng vẫn cắn răn fix vì code bạn viết ra. Nhưng oái ăm thay nếu ông sếp bắt bạn maintain code của 1 ông ất ở nào đó nghỉ lâu rồi. Project của ông ấy lại viết bằng framework Kohana, trong khi bạn quá quen thuộc với Laravel được chăm chút, bón cho từng thư viện thì bạn qua Kohana – 1 framework PHP cũ search document mới nhất toàn 2012-2013 sẽ khiến bạn căng như dây đàn.
Nói khá nhiều nhưng tựu chung lại devs rất hòa đồng, nhưng đôi lúc cũng cáu gắt ắt ỏng. Bạn nên cho mình 10-20p khuây khỏa bằng cách pha cafe, qua bàn chém gió với mấy anh design để hỏi thăm danh tính thanh niên ất ơ kia là ai mà khiến bạn hốt shit sml.
Có 1 vài chậu xương rồng, cây xanh => khoảng 2 tiếng đến 4 tiếng mình hay ngơi mắt ra nhìn xung quanh cho đỡ căng thẳng hoặc vừa gõ vừa nhìn xung quanh.
Khi bạn quay trở lại công việc, có lẽ bạn sẽ ở trong 1 tư thế tốt hơn, đầu óc sảng khoái hơn.
8. Thực hành, thực hành & thực hành:
Hãy cho bạn 1 thử thách mỗi ngày nếu bạn tự nhận mình là 1 người rảnh rỗi. Với những người đi làm có lẽ mỗi ngày đã luôn là 1 thử thách, và hãy vui vẻ về điều đó nhé.
Bởi vì những thử thách dù vật ta ngã sml nhưng sẽ cho ta cái mà không ai có thể dạy bạn: kinh nghiệm. Hãy tưởng tượng bạn là 1 nhà đô vật, bạn phải đấu với nhiều võ sĩ mỗi ngày tương ứng mỗi võ sĩ là 1 vấn đề muôn ngàn thử thách. Dù bạn có hạ được hay không bạn cũng đã làm được gì đó, và bạn học hỏi được. Thực hành => thất bại hoặc thành công => kinh nghiệm.
Hãy học từ những thất bại, lặp đi lặp lại. Luôn có những vấn đề khác nhau luôn chờ bạn. Cuộc sống của 1 lập trình viên là vậy. Đặt mục tiêu xây dựng 1 cái gì đó to lớn, áp dụng điều từ 1->7. Ví dụ:
Xây dựng 1 ứng dụng thời tiết bằng Angular (mình có viết 1 bài gồm 2 phần, mời a/e click vào đọc chơi):
- Tìm cách tutorial về việc xây dựng ứng dụng thời tiết trên Internet (làm theo nhưng không nhìn mã trong tutorial)
- Gặp khó khi code lại 1 tính năng nào đó => hãy chia nhỏ vấn đề.
- Vượt qua vấn đề => rút ra những vấn đề tương tự.
- Đặt những dòng code tiếp theo => tin tưởng vào bản thân và cố gắng viết nó.
- Lại gặp khó => chia nhỏ vấn đề => Googling 1 cách thông minh.
- Tập làm quen với test case từ những ứng dụng quy mô nhỏ để đỡ công gỡ lỗi sau này.
- Code nhiều quá MỆT => nghỉ ngơi dưỡng sức => code tiếp.
- Thực hành đi thực hành lại những bước trên với những project mới.
=> hình thành tư duy và bạn sẽ thành 1 lập trình viên giỏi.
Kết Bài
Đêm cũng qua cmnr, mình xin dừng bút. =)))
Mình hy vọng rằng những mẹo nhỏ này sẽ giúp bạn khi bạn đang muốn biết làm sao để giải quyết vấn đề. Hãy chém mình nhẹ tay vì mình mong muốn a/e trở nên tốt hơn.
Trước đây mình cũng từng viết nhiều bài chia sẻ về chủ để lập trình rất hay ho như:
- Chuyện dev kể: fix bug ứng dụng Đặt Vé Máy Bay và thu về món hời to bự
- Chia sẻ kinh nghiệm khi học CNTT cùng Bà Na
- Tâm sự devs: Đâu là ngôn ngữ lập trình đầu tiên bạn nên học?
- Ứng dụng mạng neural thần kinh trong việc phục hồi ảnh Hentai bị mờ
Mong là bài viết này đạt được mục đích của mình là giúp đỡ tất cả mọi người, bao gồm cả những bạn đang tập tành, đi làm hay đơn giản có 1 niềm đam mê với máy tính, với coding.
