- Trang chủ
- Giới thiệu
- Du học
- Đào tạo ngắn hạn
- Đào tạo chuyên sâu
- Tin Tức
- Học viên
- Blog
- Tin THPT
- Liên hệ
VIỆN CÔNG NGHỆ THÔNG TIN VÀ TRUYỀN THÔNG ITPLUS
ITPLUS INSTITUTE OF INFORMATION AND COMMUNICATION TECHNOLOGY
10 điều khó chịu nhất đối với lập trình viên
Dù bạn là ai, làm công việc gì, luôn có những điều trong công việc làm bạn không thích. Đó có thể là sếp của bạn, là tiền lương hàng tháng chưa đáp ứng đủ yêu cầu, là ông bạn đồng nghiệp luôn săm soi. Nếu bạn là một lập trình viên (LTV), hoặc đã từng tham gia lập trình hay liên quan đến nó, bạn đã bao giờ nghĩ đến những điều khó chịu nhất đối với nghề của bạn chưa?
10. Comment code giải thích “thế nào” nhưng không giải thích “tại sao”
Các khóa học lập trình luôn dạy sinh viên phải comment trong code sớm và thường xuyên. Thà comment nhiều còn hơn là quá ít. Tuy nhiên nhiều người lại thích thử thách chính mình bằng cách comment ở mọi dòng code. Ví dụ như thế này:
r = n / 2; // Set r to n divided by 2
// Loop while r - (n/r) is greater than t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // Set r to half of r + (n/r)
}
Bạn có hiểu ý tưởng của đoạn code này không? Chắc là không. Vấn đề là trong khi có rất nhiều comment mô tả code làm việc gì nhưng lại không có chỗ nào giải thích tại sao lại làm thế.
Bây giờ hãy xem một cách comment khác:
// square root of n with Newton-Raphson approximation
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
}
Tốt hơn nhiều đúng không? Mọi người thực sự có thể không hiểu chính xác đoạn code trên làm gì nhưng ít nhất nó cũng đem lại một điểm bắt đầu, để có thể tìm hiểu sâu hơn.
Comment là để giúp người đọc hiểu được code chứ không phải là chỉ ra cú pháp của nó. Đã làm việc thì ắt phải hiểu loop dùng để làm gì, nên không cần phải comment sau câu lệnh loop một cách kiểu như “//iterate over a list of customers”. Cái mà người đọc muốn biết là tại sao đoạn code đấy lại chạy được và tại sao bạn lại chọn cách viết như vậy.
9. Sự gián đoạn
Nói chung, chúng ta quen với xe lửa hơn là những chiếc xe Ferrari. Sẽ rất khó cho bạn khi dòng suy nghĩ liên tục phải đi chệch đi so với luồng suy nghĩ của khách hàng, quản lí và các đồng nghiệp. Nói một cách đơn giản là chúng ta có quá nhiều thông tin cần phải ghi nhớ đối với 1 công việc đang làm. Chúng ta phải tạm thời bỏ nó lại, nhận một công việc khác rồi sau đó lại quay lại với công việc cũ. Thật khó để công việc cũ vẫn trôi chảy như cũ mà không lỡ một nhịp nào cả. Sự gián đoạn làm mất đi luồng suy nghĩ và khi nhận việc đó trở lại là một quy trình gây tốn thời gian và bực bội cho tất cả.
8. Vượt phạm vi (scope creep)
Theo Wikipedia, “Trong quản trị dự án, vượt phạm vi là tình trạng thay đổi một cách không kiểm soát phạm vi của dự án. Hiện tượng này xảy ra khi phạm vi của dự án không được xác định, mô tả và kiểm soát đúng đắn. Nó là sự cố tiêu cực cần phải tránh.”
Scope creep là biến những yêu cầu tương đối đơn giản thành cực kì phức tạp và tốn thời gian khủng khiếp. Chỉ mất vài tổ hợp phím ngây thơ từ những người đề ra yêu cầu mà thôi:
Ahhhh!!! Vốn là 1 yêu cầu đơn giản như version 1, chỉ mất khoảng 30 phút để làm nhưng đã biến thành một yêu cầu cực kì phức tạp, tốn hàng trăm giờ làm việc. Thậm chí tệ hơn, trong suốt quá trình phát triển điều này luôn diễn ra, luôn phải viết lại yêu cầu, sửa đổi, đôi khi bỏ đi cả những phần công việc, hay cả đống code mới được phát triển mấy ngày trước.
7. Quản lí không hiểu công việc lập trình
Quản lí không phải là một việc dễ dàng. Chúng ta mỗi người một kiểu, người hay thay đổi, người mong manh, người luôn muốn chứng minh mình là số một. Giữ cho một nhóm lớn đồng lòng và gắn kết là một núi công việc. Tuy nhiên, điều đó không có nghĩa là các nhà quản lí có thể bỏ qua mà không có hiểu biết cơ bản về những công việc nhỏ của cả dự án.
Khi quản lí không thể nắm bắt các khái niệm cơ bản về công việc sẽ dẫn đến vượt phạm vi (scope creep), thời hạn không thực tế, và thất vọng chung của cả hai bên. Luôn có những xung đột khá phổ biến như vậy.
Có một tranh vui để minh họa cho điều này (xem ảnh). Quản lí: “làm việc đi thôi!”. Nhân viên (luôn có lí do): “code đang compile, sếp”. Sếp: “Thế à, tiếp tục đi”. Một lí do tuyệt vời cho 1 quản lí không biết mấy về công việc.
6. Viết tài liệu cho các ứng dụng
Có rất nhiều tài liệu cần cho ứng dụng phải viết ra nhưng theo kinh nghiệm thì chỉ có tài liệu API là quan trọng đối với LTV thôi. Nếu bạn làm việc với một ứng dụng mà người bình thường hàng ngày đang sử dụng, bạn sẽ có một số tài liệu viết để người trung bình có thể hiểu được (ví dụ như mô tả hoạt động của ứng dụng, hướng dẫn khắc phục sự cố, v.v...).
Không khó để thấy rằng đây là một cái gì đó làm LTV sợ. Hãy xem ở tất cả các dự án mã nguồn mở mà xem. Điều mà tất cả chúng ta luôn liên tục yêu cầu trợ giúp là gì? Là tài liệu.
Tôi có thể nói một câu, thay mặt cho tất cả các LTV ở khắp mọi nơi rằng, "có ai đó khác có thể làm điều đó không?".
5. Ứng dụng không tài liệu
Tôi chưa từng nói rằng chúng ta không phải kẻ đạo đức giả. LTV liên tục được yêu cầu kết hợp các thư viện bên thứ 3 vào các ứng dụng vào công việc của họ. Để làm điều đó, chúng ta cần tài liệu. Không may là, như đã đề cập tại mục 6, LTV ghét viết tài liệu. Thật trớ trêu!
Không có gì bực bội hơn viếc cố gắng sử dụng một thư viện bên thứ 3 trong khi hoàn toàn không có nổi một nửa ý tưởng về một chức năng trong các API của nó. Sự khác nhau giữa poorlyNamedFunctionA() và poorlyButSimilarlyNamedFunctionB() là gì? Có cần phải thực hiện một kiểm tra null trước khi truy cập thuộc tính X? Tôi đoán tôi sẽ phải cố để tìm hiểu thông qua kiểu làm việc “thử và sai”! Ughhhh.
4. Phần cứng
Bất kỳ LTV nào được kêu gọi để gỡ lỗi một sự cố bất thường trên máy chủ cơ sở dữ liệu hoặc lí do tại sao các ổ đĩa RAID không làm việc đúng, khi biết vấn đề nằm ở phần cứng thì thật đau đớn. Có một quan niệm sai lầm phổ biến kể từ khi LTV làm việc với máy tính, chúng ta phải biết làm thế nào để khắc phục chúng.
Phần lớn trong chúng ta không biết hoặc thực sự quan tâm về những gì xảy ra sau khi mã được dịch sang Assembly. Chúng ta chỉ muốn chúng làm việc như đúng nghĩa vụ của nó để chúng ta có thể tập trung vào các công việc bên trên.
3. Sự mập mờ
"Trang web bị lỗi". "Tính năng X không hoạt động đúng". Những yêu cầu mơ hồ là một vấn đề phải đối mặt. Nó luôn luôn gây ngạc nhiên và bực tức khi những người không biết về lập trình được yêu cầu mô phỏng lại sự cố cho một lập trình viên. Họ dường như không hiểu rằng "nó bị lỗi, hãy sửa nó đi" là không đủ thông tin để chúng ta làm việc được.
Phần mềm (với hầu hết các phần) là định tính. Chúng ta thích nó theo cách đó. Hài hước là cho phép chúng ta tìm ra bước nào của quá trình này có vấn đề, thay vì yêu cầu chúng ta chỉ đơn giản là "sửa nó đi".
2. Các LTV khác
LTV không luôn luôn đi cùng với các LTV khác. Sốc, nhưng là sự thật. Có thể dễ dàng liệt kê được ra những điều làm phiền những đồng nghiệp khác của họ:
Và cuối cùng, điều khó chịu số 1 đối với LTV là…
1. Code của chính họ, sau 6 tháng
Đã bao giờ bạn nhìn lại một số code cũ của bạn và nhăn mặt trong đau đớn? Sao mình lại có thể ngu như vậy được! Làm thế nào mà mình, một người biết nhiều bây giờ, lại có thể viết ra những dòng code như thế? Bỏ nó đi, bỏ hết nó đi!
Vâng, tin tốt. Bạn không đơn độc
Sự thật là, thế giới lập trình liên tục thay đổi. Những gì chúng ta coi là cách làm tốt nhất hiện nay có thể sẽ lỗi thời vào ngày mai. Nó chỉ đơn giản là không thể viết code hoàn hảo bởi vì các tiêu chuẩn để đánh giá code được phát triển mỗi ngày. Đó là khó khăn, bạn phải đối phó với thực tế là công việc của bạn, như bây giờ nó có thể là tốt, nhưng lại là sự nhạo báng sau đó. Thật là bực bội vì dù chúng ta bỏ bao nhiêu công nghiên cứu các công cụ, thiết kế, nền tảng và kĩ năng tốt nhất, rồi chúng ta ý thức được rằng có nhiều thứ hơi xa tầm tay.
Vâng, đây là 10 điều có lẽ là gây khó chịu nhất đối với dân lập trình. Vẫn còn những điều khác nữa, vì chúng ta mỗi người một quan niệm, một mức độ cảm nhận khác nhau. Bạn cũng có 10 điều của riêng bạn đúng không?
Nguồn: ITPlus Academy
.jpg)
