Công Việc Hằng Ngày Của Một Lập Trình Viên | TopDev

Bài viết được sự cho phép của tác giả Phạm Bình

10 Kỹ năng quan trọng cần có của Front-end để tìm công việc dễ dàng hơn 10 hiểu lầm tai hại về lập trình

Chào các bạn,

Nhắc tới lập trình là nhắc tới các dòng code, nhắc tới các dòng code là nhắc tới lập trình viên, nhưng lập trình viên liệu có phải chỉ biết viết code? Trong bài viết này, mình sẽ chia sẻ với các bạn những công việc hằng ngày và điển hình nhất của lập trình viên.

Lập trình viên có phải chỉ biết viết code

I. DAILY MEETING

Thực chất, daily meeting là một hoạt động của Scrum – một mô hình phát triển phần mềm được nhiều team áp dụng.

Daily meeting được mô tả là một cuộc họp ngắn diễn ra hằng ngày (thường vào buổi sáng), với mục đích báo cáo tổng quan tình hình công việc của team. Tùy vào văn hóa của team, mà cuộc họp này có thể có hình thức và nội dung khác nhau.

Như team mình, cuộc họp này được gọi là “Chào buổi sáng”, các thành viên trong team sẽ lần lượt báo cáo (tổng quát) về tình hình công việc của mình, như hôm qua đã làm gì, làm đến đâu rồi, có gặp khó khăn gì không, công việc hôm nay là gì… hoặc đơn giản đây là cơ hội tuyệt vời để … cà khịa nhau.

II. PHÂN TÍCH NGHIỆP VỤ

Với các công ty lớn, có mô hình làm việc rõ ràng thì phân tích nghiệp vụ sẽ có riêng một bộ phận đảm nhiệm. Nhưng với các công ty cỡ vừa, hoặc các team nhỏ thì lập trình viên đôi khi sẽ phải “đá” sang vai trò của BA (Business Analyst – Phân tích nghiệp vụ).

BA là người đứng giữa khách hàng và team phát triển sản phẩm (là team có các anh dev đẹp trai), có nhiệm vụ phân tích yêu cầu của khách hàng. BA thường phải trả lời các câu hỏi sau:

• Yêu cầu của khách hàng có khả thi không? Ý là có làm được hay không, vì khách hàng đôi khi đòi những tính năng phi lý, nằm ngoài giới hạn của công nghệ.
• Có nên làm tính năng đó hay không? Khách hàng đôi khi đưa ra các tính năng mà để triển khai thì rất tốn kém, nhưng giá trị đem lại thì không cao. BA cần phân tích và chỉ ra cho khách hàng.

Một số công việc điển hình khác của BA:

• Chuyển đổi yêu cầu của khách hàng thành các đầu công việc cụ thể: Yêu cầu của khách hàng thường mơ hồ, chung chung, BA cần phân tích và làm rõ chúng, chuyển thành các đầu công việc cụ thể.
• Phân tích rủi ro khi thay đổi (bổ sung) tính năng: Khi một tính năng mới được thêm vào hệ thống, BA cần phân tích xem nó ảnh hưởng tới hệ thống như thế nào.
• Đưa ra các lời khuyên cho khách hàng: Khách hàng đôi khi rất “vô lý” đòi làm những thứ trên trời dưới bể mà chẳng đem lại lợi ích gì, BA cần phân tích, đưa ra các lời khuyên hợp lý cho khách hàng như “anh không nên làm thế, vì … thay vào đó anh nên làm thế này vì … “.

Hình ảnh cả team ngồi phân tích nghiệp vụ cho tính năng mới

III. VIẾT CODE

Lập trình viên biết code là điều đương nhiên, và “code của lập trình viên” là một chủ đề muôn thuở – dù đã tốn rất nhiều nước bọt nhưng vẫn chưa kể hết. Nên mình sẽ chỉ điểm qua một vài điều đáng chú ý phía sau công việc này:

• Viết code = Ngôn ngữ lập trình + Tư duy lập trình: Ngôn ngữ lập trình học thì dễ, nhưng tư duy lập trình thì phải chịu khó rèn luyện. Nghĩa là để viết code, thì bạn nên tập trung vào tư duy lập trình nhiều hơn là việc học một ngôn ngữ lập trình.
• Code chỉ là công cụ: Một phần mềm tốt thì bao gồm cả yếu tố “code tốt”, nhưng “code tốt” không có nghĩa là phần mềm tốt. Tức là để tạo ra một phần mềm tốt bạn cần tập trung nhiều kỹ năng hơn và việc “code sao cho tốt”.
• Viết code là quá trình chuyển đổi ý tưởng con người thành công việc cho máy tính: Nghĩa là bạn phải có ý tưởng trước khi thực sự viết code.

IV. REVIEW CODE

Review code là công việc xem, đánh giá một đoạn code đó có tốt hay không? Tốt hay không tốt ở điểm nào? Cần chỉnh sửa ra sao? … Để đảm bảo việc review có hiệu quả, thì công việc này thường được thực hiển bởi leader hay những người có kinh nghiệm code, hoặc cũng có thể là các developer review chéo code của nhau, chứ ít khi “mình tự review code của mình”.

So với việc viết code, thì review khó và áp lực hơn, bởi:

• Những dòng code đó không phải do bạn viết ra, bạn cần phải hiểu tại sao sao “nó lại được code như vậy”. Nói thật chứ code mình viết ra nay mai đọc lại còn chẳng hiểu, chứ nói gì đến đọc code của người khác.
• Code sau khi được bạn review, mà vẫn có lỗi, thì lỗi đó là lỗi của bạn, bởi bạn đã không tìm ra lỗi đó trong lúc review.
• Bạn phải suy nghĩ ở mức “high level” hơn so với người viết ra đoạn code đó thì mới có thể tìm ra các trường hợp mà đoạn code đó không xử lý được (hoặc xử lý kém).

V. TEST

Cũng giống như việc phân tích nghiệp vụ, các team nhỏ chưa chắc đã có vị trí tester (người kiểm thử và đảm bảo phần mềm chạy đúng), nên nhiều khi lập trình viên phải kiêm luôn vai trò của một tester.

Về cơ bản, vai trò của tester là nghĩ ra thật nhiều trường hợp và đảm bảo phần mềm phải chạy tốt trên tất cả các trường hợp đó.

Mặc dù các developer được khuyên là nên test chéo tính năng của nhau để kết quả test khách quan hơn, nhưng kết quả test từ một developer vẫn không thật sự “đáng tin cậy”. Vì họ thường tin tưởng đồng nghiệp, họ nghĩ rằng trường hợp này quá cơ bản nên chắc chắn đồng nghiệp của họ đã xử lý rồi, nhưng kết quả thì có thể không như vậy. Dẫu không hiệu quả, nhưng méo mó có hơn không, nhiều team vẫn không hề có vị trí tester rõ ràng.

VI. HỌP

Bạn có thể nghĩ “họp” là công việc của “cán bộ”, nhưng thực tế, các lập trình viên cũng phải tham gia rất nhiều các cuộc họp khác nhau:

• Khi có dự án mới => họp.
• Khi hoàn thiện một dự án => họp.
• Khi có business không rõ ràng, cần thảo luận lại => họp.
• Khi thảo luận với đối tác => họp.
• Khi cần training công nghệ mới => họp.
• Khi team có member mới là nữ => họp.

Tuần suất diễn ra các cuộc họp với mỗi team, mỗi công ty, mỗi thời điểm có thể khác nhau, nhưng chung quy lại họp là một trong những công việc diễn ra khá thường xuyên khi bạn là một lập trình viên. Không những vậy, vai trò của các anh dev trong mỗi cuộc họp cũng rất đa dạng, họ có thể là người làm chủ cuộc họp, hoặc là người nêu ý kiến, đôi khi là thư ký …

VII. TỔNG KẾT

Kể ra mới thấy công việc của lập trình viên đâu phải chỉ là code đúng không? Mà chưa kể khi có kinh nghiệm thì họ sẽ có xu hướng “code ít” hơn, và chuyển sang làm các công việc như thiết kế hệ thống, quản lý dự án, quan hệ khách hàng,… Nói chung code chỉ level cơ bản nhất của lập trình viên, và chẳng có lập trình viên nào code cả đời cả.

Bài viết gốc được đăng tải tại phambinh.net

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

• Nếu một ngày tôi không còn mặn mà với lập trình nữa?
• Cô gái 8X khởi nghiệp thành công từ ngành tổ chức sự kiện
• Lập trình viên làm gì khi Corona hoành hành: ở nhà học tiếng Anh lập trình theo phong cách “fast and furious”

Xem ngay những tin đăng tuyển dụng IT mới nhất trên TopDev