Bạn là dạng nào trong hai dạng lập trình viên?

Thật ra trong thế giới lập trình viên có nhiều dạng hay thể loại khác nhau, loại ngáo đá, loại bất chấp, loại an toàn… Nhưng trong bài viết này chúng ta chỉ tập trung hai dạng lập trình viên đặc biệt mà thôi.

Hai dạng lập trình viên

Trong một công ty hay nói gọn lại là một team thì thể nào cũng có hai dạng developer, một có thể giải quyết được vấn đề tốt, loại còn lại là không. (Không chứ chưa phải là chưa tốt).

Người có thể giải quyết được vấn đề tốt chưa hẳn là người có kinh nghiệm lâu năm hay là được học trường bài bản, mà họ nắm được những kỹ năng, lý thuyết tốt. Họ được trau dồi mỗi ngày, họ có thể review code của họ vào ngày mai, để có thể code lại một cách tốt hơn. Do đó hiệu suất làm việc của họ cao hơn hẳn loại còn lại.

Ví dụ thực tế:

Làm thể nào để remove duplicate trong array một cách nhanh nhất và hiệu quả nhất?

Cùng một vấn đề nhưng những người không nắm tốt việc giải quyết vấn đề lại mất thời gian nhiều cho việc seach google về các giải pháp. Vì đây là câu hỏi cách nào, cho nên loại này phải tìm rất nhiều phương pháp trên google. Đôi khi tìm được, họ lại vứt vào code luôn, miễn là chạy được là done.

Vì chính bản thân họ không biết cách giải quyết vấn đề. Ở đây cái đơn giản nhất cho việc giải quyết vấn đề là đi hỏi trong team. Đó cũng là cách giải quyết vấn đề nhanh nhất giúp bạn có thể có những ý tưởng hơn. Vì bạn đang làm trong mội trường team work. Điều ấy mà bạn còn không nhận ra được thì sẽ càng khó cho bạn trong những task tiếp theo của team.

Việc này không những rất nguy hại cho chính bản thân của họ, mà còn có thể phá huỷ công sức của một team. Khi mà module của bạn bị khiếm khuyết thì kéo theo không ít hệ luỵ trong team. Để rồi team phải ngồi lại để giải quyết vấn đề.

Còn loại còn lại khi nói đến vấn đề hay giải pháp nào thì họ đã có săn ở trong đầu vì họ luôn control được những gì cần giải quyết.

Vậy làm thế nào để giải quyết được vấn đề tốt trong lập trình?

Trong bài viết này tôi sẽ tham khảo rất nhiều bài viết về vấn đề này và để có cái nhìn sâu sắc thì tôi tin trích đoạn từ blog của Huy TD (https://dev.to/huytd).

Lại nói về công việc hằng ngày của một developer là gì? Build thêm feature mới, hoặc build một sản phẩm hoàn toàn mới, nhưng cũng có thể là bảo trì (maintenance – tên gọi hoa mỹ của những hành động: fix bug, refactoring,…) sau khi sản phẩm được released. Dù bạn làm gì, thì cũng đều có thể gói gọn trong các bước sau:

• Tiếp nhận và hiểu vấn đề: ở dây có thể là bug description, hoặc là yêu cầu của sản phẩm/feature,…
• Phân tích vấn đề: nếu là bug, đây là bước điều tra các hiện tượng, tìm cách tái hiện (reproduce) lại bug đó, tìm hiểu nguyên nhân gốc rễ của vấn đề (root cause) và hướng giải quyết. Nếu là build mới, đây là bước phân tích các yêu cầu kĩ thuật, search google để tìm các thư viện hỗ trợ nếu có (vì mình thường thấy nhiều bạn làm gì cũng search thư viện có sẵn, nên mình đoán cái đó nằm trong quy trình này, nên ghi vô luộn).
• Lên phương án hành động: sau khi đã có đầy đủ các dữ kiện cần thiết, hiểu rõ được bản chất của vấn đề và hình dung được hướng giải quyết, thì chúng ta cần vạch ra kế hoạch từng bước để hiện thực hóa giải pháp đó, quan trọng hơn nữa, là phương án hành động này phải đảm bảo chỉ giải quyết vấn đề cần giải quyết  mà không làm ảnh hưởng đến những thứ khác.
• Thực hiện: get done.
• Rút kinh nghiệm: sau khi đã giải quyết xong vấn đề, đây là bước cực kì quan trọng. Nhìn lại quá trình thực hiện và những sai lầm mắc phải, rút kinh nghiệm. Nếu là vấn đề gì hay ho thì có thể viết thành blog cũng được.

Các bạn có thấy nếu một trong những bước trên fail thì bạn khó có thể giải quyết được vấn đề:

• Không đọc kỹ yêu cầu: Bạn có thể sai ngay từ bước đầu tiên khi giải quyết vấn đề.
• Không hiểu rõ vấn đề: Bạn sẽ không bao giờ giải quyết được nó, vì bạn đâu có biết nguyên nhân tại sao nó lại như vậy? Điều đó dẫn tới nhiều hệ luỵ trong cách phân tích, do bạn không biết phân tích ngay từ lúc đầu cho nên bạn không có giải pháp, or chỉ là giải pháp nửa vời (chơi chiêu) cho qua chuyện và tệ hơn nữa có thể gây ra regression.
• Không có kế hoạch hành động cụ thể, bạn sẽ bị lệch hướng khi thực hiện và tai hại hơn là gây ảnh hưởng đến các thành phần khác của hệ thống. Giải quyết xong vấn đề là vứt nó qua một bên luôn không bao giờ nhìn lại, cứ thế bạn sẽ không bao giờ thu được tí kinh nghiệm gì ngoài việc làm nhiều rồi quen tay.

Một software engineer giỏi không phải là người biết nhiều kĩ thuật hay ngôn ngữ, mà là người có khả năng giải quyết vấn đề tốt.

Bạn có bao giờ đặt câu hỏi “tại sao fix bug hoài mà càng fix thì càng ra bug không?”. Vì Cách giải quyết của bạn không như những lập trình viên khác. Bạn chỉ tập trung làm cho quen tay mà thôi, và khi đặt câu hỏi bạn đều không hiểu những giải pháp đưa ra thay vào đó bạn chỉ trả lời chung chung…

Kết luận

Thật đáng tiếc với những bài viết thế này vì những ai rơi vào loại 2 đều cảm thấy buồn, thay vì chia sẻ những kỹ năng học lập trình. Nhưng hy vọng các bạn có những trường hợp như thế này cần xem lại chính bản thân mình, và tự mình vươn lên.

Có rất nhiều developer khi họ mới nhập team còn khổ hơn bạn rất nhiều. Tự trau dồi những kỹ năng giải quyết vấn đề mà trong bài này có nói tới chính là phương pháp giúp loại không giải quyết tốt vấn đề có thể sớm quay lại với vòng quay của một function.

Có thể bạn quan tâm:

• 15 đặc điểm của một lập trình viên giỏi
• Tóm tắt con đường trở thành Lập Trình Viên
• Lập trình viên và hội chứng Tự kỷ

Xem thêm việc làm Software Developers hấp dẫn trên TopDev

TopDev via Anonystick.com