Top 10 điều khó chịu đối với Lập trình viên (LTV)

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, 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:
1 r = n / 2; // Set r to n divided by 2
2
3 // Loop while r - (n/r) is greater than t
4 while ( abs( r -
(n/r) ) > t ) {
5 r = 0.5 * ( r + (n/r) ); // Set r to half of r +
(n/r)
6 }

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:

1 // square root of n
with Newton-Raphson approximation
2 r = n / 2;
3
4 while (
abs( r - (n/r) ) > t ) {
5 r = 0.5 * ( r + (n/r) );
6 }

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:

- Version 1: Hiển thị bản đồ khu vực
- Version 2: Hiện
thị bản đồ dạng 3D của khu vực
- Version 3: Hiện thị bản đồ dạng 3D
của khu vực mà người dùng có thể bay qua

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 “man hours”. 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

Lý do tuyệt hảo


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ó 1 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ế ah, 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 không bao giờ nói rằng chúng ta
chưa từng một lần giả tạo. LTV liên tục yêu cầu kết hợp các thư viện
bên thứ 3 và 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". Mơ hồ là một yêu cầu để
đối phó với cơn đau. 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ọ:

- Trở nên gắt gỏng, cục cằn cho
đến khi bị ghét
- Không hiểu rằng cần có một thời gian để tranh luận
kiến trúc hệ thống và một thời gian để thực hiện công việc
- Không
có khả năng giao tiếp hiệu quả và gây nhầm lẫn thuật ngữ
- Không
nâng cao được vị thế của riêng mình
- Thờ ơ đối với các code base và
dự án

Và cuối cùng, điều khó chịu số 1 đối với LTV …

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ế, frameworks và best practices tốt nhất, rồi chúng ta ý thức được rằng
có nhiều thứ hơi xa tầm tay.

Well,
đâ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?