Ngạc nhiên với 7 công việc lập trình viên sẽ phải làm hằng ngày

Khi chúng ta nói về lập trình, chúng ta đang nói về các dòng mã, và khi chúng ta nói về các dòng mã, chúng ta đang nói về các lập trình viên, nhưng các lập trình viên chỉ biết viết mã? Trong bài đăng này, tôi sẽ xem xét các công việc lập trình viên phổ biến nhất hàng ngày.

I. DAILY MEETING

Trên thực tế, các cuộc họp hàng ngày là một hoạt động Scrum, một mô hình phát triển phần mềm được nhiều nhóm sử dụng.

Cuộc họp hàng ngày được định nghĩa là một cuộc họp ngắn được tổ chức hàng ngày (thường vào buổi sáng) nhằm mục đích báo cáo về tiến độ của nhóm. Cuộc họp này có thể diễn ra theo một hình thức và chủ đề khác tùy thuộc vào văn hóa của đội.

Thường thì các cuộc họp có tên là “Chào buổi sáng” và các thành viên trong nhóm sẽ lần lượt báo cáo (thường) về tình trạng công việc của họ, chẳng hạn như những gì họ đã làm ngày hôm qua và họ đã đi được bao xa. Bạn có vấn đề gì không, và công việc của bạn hôm nay là gì … Nói một cách đơn giản, đây là một cơ hội tuyệt vời để … có một khoảng thời gian vui vẻ.

Đăng ký ngay

Đăng ký ngay

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

Phân tích kinh doanh sẽ có bộ phận riêng ở các công ty lớn với mô hình hoạt động được xác định rõ ràng. Tuy nhiên, ở những doanh nghiệp vừa hoặc đội ngũ nhỏ, lập trình viên có thể buộc phải “đá” vào vị trí BA (Business Analyst).

BA là liên kết giữa khách hàng và nhóm phát triển sản phẩm (một nhóm các nhà phát triển hấp dẫn), những người chịu trách nhiệm đánh giá nhu cầu của khách hàng. BA thường được yêu cầu trả lời các câu hỏi sau:

• Có thể thực hiện được yêu cầu của khách hàng không? Câu hỏi đặt ra là có nên làm hay không, bởi vì người tiêu dùng đôi khi muốn những thứ vượt ra ngoài phạm vi của công nghệ.
• Có cần thiết để triển khai tính năng đó không? Khách hàng đôi khi đề xuất các tính năng tốn kém để xây dựng nhưng mang lại ít lợi ích. BA phải đánh giá dữ liệu và trình bày nó cho khách hàng.

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

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

III. VIẾT CODE

Các lập trình viên bắt buộc phải biết cách viết mã, và “mã của lập trình viên” là một vấn đề lâu đời – rất nhiều thứ đã bị lãng phí, nhưng không phải là tất cả. Vì vậy, tôi sẽ chỉ nêu một vài khía cạnh đáng chú ý của công việc này:

• Ngôn ngữ lập trình Cộng với suy nghĩ lập trình = viết mã: Ngôn ngữ lập trình rất đơn giản để học, những suy nghĩ về lập trình thì khó. Nói cách khác, bạn nên tập trung vào tư duy lập trình hơn là nghiên cứu một ngôn ngữ lập trình nếu bạn muốn sản xuất mã.
• Mã không hơn gì một công cụ: Mặc dù “mã tốt” là một thành phần của phần mềm xuất sắc, nhưng “mã tốt” không có nghĩa là “phần mềm tốt”. Nói một cách khác, nếu bạn muốn tạo ra một phần mềm tốt, bạn cần phải tập trung vào các tài năng bổ sung và “viết mã tốt”.
• Mã hóa là quá trình biến ý tưởng của con người thành mã máy tính; nói cách khác, trước tiên bạn phải có một khái niệm trước khi viết mã.

IV. REVIEW CODE

Việc REVIEW CODE đòi hỏi phải kiểm tra và phân tích một đoạn mã để xem nó có xuất sắc hay không. Nó trở nên tốt hay xấu ở những điểm nào? Tôi nên tiếp tục chỉnh sửa như thế nào? … Nhiệm vụ này thường được thực hiện bởi người lãnh đạo hoặc các lập trình viên có kinh nghiệm để đảm bảo việc xem xét thành công, mặc dù nó cũng có thể được thực hiện bởi các nhà phát triển, những người đánh giá chéo mã của nhau, nhưng hiếm khi “Tôi tự xem lại mã của mình”. 

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

• Bạn phải hiểu tại sao “nó được lập trình như vậy” vì những dòng mã đó không phải do bạn tạo ra. Thành thật mà nói, tôi sẽ không hiểu được đoạn mã mà tôi đặt xuống cho đến ngày mai, chứ đừng nói đến việc đọc tác phẩm của người khác.
• Nếu bạn xem lại mã và nó vẫn bao gồm các vấn đề, đó là lỗi của bạn vì bạn đã không nắm bắt được lỗi trong quá trình xem xét.
• Để phát hiện ra các trường hợp mà mã không xử lý được, bạn phải suy nghĩ ở “cấp độ cao hơn” so với người đã phát triển mã (hoặc làm kém).

V. TEST

Các nhóm nhỏ, như phân tích kinh doanh, có thể không có vị trí người kiểm tra (người kiểm tra và đảm bảo sản phẩm hoạt động bình thường), do đó, lập trình viên phải thường xuyên đảm nhận công việc của người kiểm tra.

Về cơ bản, công việc của người kiểm thử là xem xét càng nhiều kịch bản càng tốt và đảm bảo rằng chương trình hoạt động bình thường trong từng tình huống đó.

Mặc dù các nhà phát triển nên kiểm tra chéo các tính năng của nhau để cải thiện tính khách quan của các kết quả kiểm tra, kết quả kiểm tra từ một nhà phát triển duy nhất vẫn không thực sự “đáng tin cậy”. Bởi vì mọi người thường tin tưởng đồng nghiệp của mình, họ tin rằng tình huống đơn giản đến mức đồng đội của họ phải xử lý nó, nhưng kết quả có thể khác. Nhiều nhóm vẫn thiếu một vai trò người kiểm tra xác định, điều này không hiệu quả nhưng tốt hơn là không có gì. 

VI. HỌP

Mặc dù bạn có thể tin rằng các “sĩ quan” chịu trách nhiệm về “các cuộc họp”, các lập trình viên cũng được yêu cầu tham gia nhiều 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

Các cuộc họp với từng nhóm, từng công ty và vào những thời điểm khác nhau có thể khác nhau, nhưng các cuộc họp là một trong những điều thường xuyên xảy ra khi bạn là một lập trình viên. Không chỉ vậy, vai trò của các nhà phát triển trong mỗi cuộc họp cũng khá đa dạng: họ có thể là người chủ trì cuộc họp, người bình luận hoặc thậm chí là thư ký …

VII. TỔNG KẾT

Nói cho tôi biết, công việc của một lập trình viên không chỉ là viết mã, đúng không? Không phải nói thêm, khi họ có kiến thức chuyên môn, họ có thể sẽ “viết mã ít hơn” và thay vào đó tập trung vào các nhiệm vụ như thiết kế hệ thống, quản lý dự án và dịch vụ khách hàng. Nói chung, mã chỉ là một loại cơ bản. Những lập trình viên giỏi nhất và không có lập trình viên nào viết mã trong suốt quãng đời còn lại của họ.

Tổ Chức Giáo Dục FPT – fpt.edu.vn

Hệ Thống Đào Tạo Lập Trình Viên Quốc Tế – aptech.fpt.edu.vn