Bài viết được sự cho phép bởi tác giả Vũ Thành Nam
Cuộc sống của một lập trình viên rất thực tế, tạo ra những sản phẩm và những chức năng chạy được, giúp ích cho đời, giúp ích cho cuộc sống. Tuy nhiên không phải không có những góc khuất, chính xác hơn là những nỗi khổ tâm của anh em lập trình mà nói hay không nên nói đều có sự bế tắc của riêng họ. Dù sao thì cuộc sống mà, ai chẳng có dăm ba lần nói dối, nói xạo, thảo mai cho anh em đồng nghiệp hay khách hàng vui vui một xíu nhỉ!
Dưới đây là 8 điều nói dối thường gặp nhất mà mình thấy được, đôi khi mình cũng vậy mà
1. Trước đó nó chạy bình thường mà ta
Wow! Nó vừa mới chạy ngon lành xong mà không biết sao sang máy anh/chị lại chết ta! Như có một thế lực vô hình nào ta
Thực ra thì có nhiều nguyên nhân dẫn tới tình trạng này, nhưng thường là 2 nguyên nhân chính sau.
Một là lập trình viên viết ra một chức năng, họ chỉ chạy mẫu trên máy họ một hai trường hợp (smoke test) không hề kỹ càng. Và phần code mà “ủa! ủa!” kia chưa hề được chạy và với niềm tin là code mình đúng mà, logic này đọc lướt qua là thấy chạy đúng rồi thì “chắc là pass thôi”. Niềm tin và hi vọng qua được cửa ải của các chị tester trời đánh kia. Nhưng không đời không như là mơ, tester mà, họ có nghiệp vụ và đôi khi là adhoc case. Bà ý bắt bài rồi, nhưng em đây vẫn thích lươn với chị sao được.
Nguyên nhân thứ hai thì khách quan hơn là config môi trường chưa đúng. Máy môi trường dev và môi trường test thường khác nhau đôi chút và cần phải setting tùy biến để phù hợp. Đôi khi máy dev đã cài sẵn những phần tích hợp từ trước hay hỗ trợ nhiều thành phần hơn, nhưng sang máy tester hay client thì không, nó như là một tờ giấy trắng hay không muốn nói là một số đã lỗi thời, chẳng hạn như người nhật đến giờ vẫn dùng trình duyệt IE6. Dù khách quan nhưng mà nó cũng là một câu nói dối khi đúng là mình chưa kiểm tra môi trường thật. Biết sao giờ, phải lươn thôi!
2. Code cho chạy tính năng chính đã, thêm comments sau, hay viết tài liệu sau
Có một sự thật là không mấy lập trình viên mặn mà với việc viết comments hay tài liệu bởi vì khi họ thay đổi code họ lại phải thêm việc đi cập nhật lại các comments và tài liệu liên quan trước đó. Hơn nữa, việc chính của họ là code, việc viết tài liệu và comments giải thích tài liệu cho một ai đó thường được coi không phải việc của họ. Tại sao tôi phải viết, vì sách nói hay những nguyên tắc chuẩn chỉ để trở thành một lập trình viên tốt và có trách nhiệm ư!
Việc làm đó tốt đó nhưng thôi để làm sau đi, khi nào rảnh rồi làm, giờ chức năng còn chưa chạy xong mà cứ bới việc vậy!
Sau một vài tháng, họ chuyển qua dự án mới, người mới tiếp nhận. Wth! hờn cả thiên hạ và méo hiểu cái gì, hỏi lại chính chủ tác giả cũng méo nhớ gì luôn! Trách ai bây giờ đây.
3. Nó không phải trách nhiệm của tôi
Cái này là của anh A viết ra nó!, Đây không phải là lỗi phần chức năng của tôi! Cái này do kiến trúc hạ tầng! Vấn đề này của team khác! Nhưng bạn biết và bạn hiểu rằng trong đó có một phần trách nhiệm của bạn. Bạn là người nhận bàn giao từ dev trước, bạn là người tích hợp chức năng đó với team khác. Bạn là người triển khai phần mềm và cài đặt cơ sở hạ tầng hay ít nhất là biết đến nó. Tuy nhiên, thật sự rằng ai cũng khó lòng chấp nhận được lỗi lầm và cái tôi luôn đẩy lên cao. Cứ đá banh đi trước đã, tính sau!
4. Tôi không biết về nghiệp vụ hay chức năng này
Chuyên môn hóa nghiệp vụ mỗi thành viên trong team đúng là làm cho mỗi thành viên trở nên cô lập, họ chỉ nắm nghiệp vụ của riêng họ và hoàn thành việc của họ là đúng. Khi sếp hỏi đến thì thay vì bạn trả lời rằng tôi cần thời gian tìm hiểu chức năng đó vì hiện tại tôi chưa nắm rõ, hay chức năng đó khá phức tạp và cần tìm hiểu hay tham khảo của các cấp bậc cao hơn thì bạn buôn một câu tôi không biết, tôi không làm được nó. Điều này vô tình hạ điểm của bạn trong mắt người khác, họ cũng hiểu được rằng bạn chỉ đang nói dối và trốn tránh trách nhiệm mà thôi.
5. Tôi không có khả năng diễn thuyết, thuyết trình, demo
Có một số trường hợp dự án phải thuyết trình cho khách hàng hay demo sản phẩm. Thường BA hay QC sẽ làm việc này vì họ nắm rõ flow và các use case tổng quát hơn bạn thật. Nhưng chức năng mà bạn làm ra, lẽ nào bạn không biết, vậy mà bạn vẫn lươn em không giỏi demo, em sợ khách hàng không hiểu. Mình cũng hay rơi vào tình trạng này. Thật lòng thì đôi khi không có sự lựa chọn, mình vẫn phải chuẩn bị và tập demo, tập seminar cho dự án. Hay thay là nó cũng thành công và không quá tệ như mình nghĩ!
6. Sắp xong rồi, cuối ngày hôm nay là xong
Có những vấn đề bạn chưa chắc chắn hay chưa biết cách giải quyết như thế nào, nhưng để an ủi sếp và đồng nghiệp bạn hứa lèo rằng, sắp xong rồi anh, cuối ngày có cho chị test. Một ngày, hai ngày, một tuần, hai tuần chưa xong. Tự nhiên bạn thành trò đùa và chẳng ai tin bạn dám giao gì cho bạn nữa. Kế hoạch và hoạch định thời gian bàn giao trước là điều cần phải làm, đôi khi có những vấn đề khó phát sinh, thay vì cùng nhau ngồi lại bàn bạc khúc mắc và tính toán các trường hợp xấu nhất để tránh ảnh hưởng thời gian chơ của người khác thì bạn cứ sắp xong rồi, nói dối để rồi họ ngồi chờ bạn luôn. Thật tai hại!
7. Đây chỉ là giải pháp tạm thời
Tôi chưa có giải pháp nào tốt hơn tại thời điểm này. Tôi sẽ cải thiệt optimize, refactor sau. Yên tâm đi, tạm thời vậy đã.
Đúng là có những thời điểm không kịp deadline bạn sẽ phải chữa cháy tạm thời, nhưng cố gắng trình bày với sếp để họ biết trước để chuẩn bị kế hoạch và phương án sau này. Tạm thời, vậy khi nào cập nhật, khi nào vá, nợ kỹ thuật là một cái nợ không dễ dàng trả được đâu. Nó chồng chất theo từng ngày đó!
8. Nó không phải là bug, anh chị làm gì đó sai thôi
Một câu chữa cháy không thể nào hợp lý hơn. Đôi khi tưởng chừng như bạn đúng ở các trường hợp và tiền điều kiện để chạy chức năng đó, nhưng đâu ai cấm người dùng vọc phá và đảo lộn thứ tự các bước đâu.
Cũng như pháp luật vậy, cái gì không cấm thì có quyền làm, họ làm thế nào là theo cách của họ, thói quen của họ, chương trình của bạn chưa xử lý những trường hợp ngoại lệ như vậy thì đừng đổ thừa họ làm gì đó sai thôi. Mà kể cả sai thật thì cũng chữa cháy đá trách nhiệm cái đã. Mình giải quyết từ từ. Mình cũng đã gặp trường hợp sản phẩm lên production, khách hàng cũng chẳng biết họ đã làm gì, họ chỉ biết lỗi, họ không nhớ bước nào sai, kết qua là mình phải dò từng dòng log để biết các steps của họ như thế nào cả buổi rồi mới có thể fix được. Phận tôi tớ khổ vậy đó!
Trên đây là một số lời nói dối mà vô tình biến những anh lập trình viên đầy khí chất thành những con lươn của năm, đôi khi một hai câu nhỏ nhỏ không ảnh hưởng đến bất kỳ ai nhưng nó sẽ là một thứ không tốt về lâu về dài. Anh em cân nhắc nhé!
Nếu có lời nói dối kinh điển nào hay hơn thì anh em để lại dưới bình luận nhé!
Bài viết gốc được đăng tải tại ntechdevelopers.com
Xem thêm:
- 13 phím tắt trong VS Code hữu ích giúp lập trình dễ dàng hơn
- 5 cách để phát triển tư duy logic trong lập trình
- Top 5 kỹ năng quan trọng cần trang bị trong năm 2024
Xem thêm Top vị trí tuyển dụng IT trên TopDev
