Ai cũng nói trong lập trình thì tư duy giải quyết vấn đề quan trọng hơn là khả năng code vậy thì rốt cuộc nó là cái gì
Đến trình độ fresher thì cần xử lý ngoại lệ, dự đoán các trường hợp có thể xảy ra càng nhiều càng tốt, giúp cho logic của hàm được chắc chắn, hạn chế tối đa lỗi có thể xảy ra. Ko có tiêu chí nào để phân chia rõ ràng các trình độ với nhau, nhưng nhìn chung thì 2 mức intern và fresher ban đầu cũng chỉ gặp phải những vấn đề thuần túy về code như vậy thôi. 1 là đặt tên biến tên hàm ngu, 2 là logic ko được bền, rất dễ phát sinh lỗi.
19/07/2025•Ngô Tuấn
Ở mỗi 1 trình độ hay vị trí khác nhau sẽ gặp phải các vấn đề khác nhau. Vấn đề của 1 intern sẽ khác với của junior, của junior sẽ lại khác với của senior. Ví dụ intern thì cần đặt tên biến, tên hàm, làm sao để nhìn vào có thể biết được ý nghĩa của nó thì càng tốt. Nghe thì dễ ấy thế mà nhiều ông junior cũng chưa làm được đâu. Cái này còn phụ thuộc vào cả khả năng ngôn ngữ chứ ko phải chỉ riêng mình lập trình.
Đến trình độ fresher thì cần xử lý ngoại lệ, dự đoán các trường hợp có thể xảy ra càng nhiều càng tốt, giúp cho logic của hàm được chắc chắn, hạn chế tối đa lỗi có thể xảy ra. Ko có tiêu chí nào để phân chia rõ ràng các trình độ với nhau, nhưng nhìn chung thì 2 mức intern và fresher ban đầu cũng chỉ gặp phải những vấn đề thuần túy về code như vậy thôi. 1 là đặt tên biến tên hàm ngu, 2 là logic ko được bền, rất dễ phát sinh lỗi.
Đối với các level sau, nếu nói về khả năng lập trình, về logic, về cách phân chia hàm, về hiệu năng và luồng thì bây giờ chúng sinh đều bình đẳng, vì có AI hỗ trợ hết rồi. Ông nào càng tự tin vào khả năng lập trình của bản thân thì có thể hiệu suất làm việc sẽ lại càng kém. Bởi vì quá tự tin nên mới thích tự code hơn là dùng AI, mà sức người thì so làm sao được. Cho nên kinh nghiệm lâu năm cũng ko có nhiều ý nghĩa nữa. Câu chuyện bây giờ là ai sử dụng AI hiệu quả hơn thôi.
Đấy là về lập trình. Còn giải quyết vấn đề sẽ khác, thậm chí là trái ngược với tư duy lập trình thông thường, càng tà đạo thì càng tốt. Chẳng hạn vì 1 lý do nào đó mà sau khi golive lại phát sinh 1 lỗi nghiêm trọng, nếu theo tư duy lập trình thông thường thì sẽ tìm lỗi đó và fix cho thật chuẩn. Nhưng làm vậy rất mất thời gian, trong lúc đó chờ để fix xong thì đã bị khách hàng chửi um lên rồi. Lúc này sẽ cần phải linh hoạt giấu đi lỗi đó trước rồi mới từ từ fix lại sau.
Nếu cứ đúng quy trình, phải sửa hết cái này đến cái kia, cần người này người kia, thì sẽ mất rất nhiều thời gian. Lúc này cần phải làm bất cứ cách nào để giảm thiểu thiệt hại mới là điều quan trọng nhất. Chứ không phải cứ hùng hục lao vào code cho thật chuẩn đâu, đây là người ko có tư duy giải quyết vấn đề.
1 trường hợp cũng gần tương tự là khi khách hàng phản ánh về 1 lỗi của phần mềm, nếu chiếu theo tài liệu thì đó là lỗi thật. Người ko có tư duy giải quyết vấn đề sẽ chỉ biết xin lỗi khách hàng và lao vào fix cho thật chuẩn. Còn tư duy giải quyết vấn đề ở đây là phải diễn giải làm sao để biến lỗi thành tính năng mới là đỉnh cao. Hoặc ít nhất thì cũng phải khiến nó trở thành 1 lỗi về trải nghiệm thay vì logic. Bởi vì trải nghiệm ko tốt thì vẫn có thể cải thiện được, nhưng nếu sai logic thì vấn đề sẽ nghiêm trọng hơn rất nhiều.
Hay khi cần thêm tính năng mới mà thời gian thì gấp, nguồn lực lại hạn chế. Nếu cứ cứng nhắc làm đúng quy trình, code cho thật chuẩn, thì sẽ ko thể có được đầu ra cho khách hàng. Lúc này lại cần phải xử lý linh hoạt quyết đoán, ưu tiên cho đầu ra đã, còn chất lượng thì sẽ bù vào sau.
1 loại nữa là đưa ra được giải pháp kỹ thuật giúp cải tiến quy trình. Bình thường việc check log ở server sẽ rất khó khăn, ko phải ai cũng có thể truy cập được. Lúc này việc bắn log về zalo hoặc tele cũng có thể coi là 1 cách để giải quyết vấn đề. Lúc này ai cũng có thể xem được log để biết lỗi gì và kịp thời fix. Đôi khi chỉ 1 ý tưởng thôi cũng đáng giá hơn nhiều công sức của 1 thợ code lâu năm chỉ biết code và code.
Nói chung là có vô vàn vấn đề sẽ gặp phải. Thường thì càng tà môn sẽ càng có cách giải quyết tốt hơn. Không phải cứ hùng hục như trâu húc mả, càng lao vào code thì càng ko giải quyết gì. Thậm chí có thể gây ra hậu quả nghiêm trọng hơn. Đôi khi không cần code mới lại là tốt. Cũng giống như câu lấy vô chiêu thắng hữu chiêu trong kiếm hiệp vậy.