Lập trình viên lâu năm thường dặn người mới mấy điều mà trường ít dạy: đọc mã đang có trước khi viết mã mới, tự thử một lúc rồi hãy hỏi nhưng đừng ngồi im cả ngày, sao lưu trước khi chạy bất cứ lệnh nào xoá dữ liệu, không bao giờ để mật khẩu hay khoá bí mật trong mã nguồn, viết để người khác đọc được, và nhận góp ý khi review mã mà không tự ái. Kỹ thuật thay đổi theo từng năm, còn những thói quen này dùng được suốt nghề.
Bài này tổng hợp kinh nghiệm phổ biến của nghề lập trình ở công ty phần mềm và bộ phận công nghệ: năm đầu dễ vấp gì, thói quen làm việc với mã nguồn, an toàn dữ liệu, làm việc trong nhóm, đạo đức nghề, và cách người đi trước kèm người mới. Các nấc nghề từ fresher lên senior hay ngả rẽ sang quản lý là chuyện khác, không bàn ở đây.
Năm đầu đi làm, lập trình viên mới hay vấp ở đâu
Vấp phổ biến nhất là viết lại thứ đã có. Người mới được giao một tính năng, thấy mã cũ khó hiểu nên tự viết một phiên bản mới từ đầu. Kết quả là hệ thống có hai cách làm cùng một việc, và lỗi ở cách cũ vẫn còn đó. Người đi trước dặn: dành thời gian đọc mã đang có, hiểu vì sao nó được viết như vậy, rồi mới quyết định sửa hay viết lại.
Vấp thứ hai là im lặng khi bị kẹt. Người mới sợ hỏi nhiều sẽ bị đánh giá yếu, nên ngồi cả ngày với một lỗi mà người khác có thể chỉ ra trong năm phút. Ngược lại, có người hỏi ngay khi gặp lỗi đầu tiên mà chưa tự đọc thông báo lỗi. Kinh nghiệm phổ biến là tự thử có giới hạn thời gian, ghi lại những gì đã thử, rồi hỏi kèm thông tin đó.
Vấp thứ ba là ước lượng quá lạc quan. Một việc nhìn có vẻ hai ngày, người mới hứa hai ngày, rồi gặp phần tích hợp, phần kiểm thử, phần sửa sau review và trễ hạn. Người lâu năm thường tính thêm thời gian cho những phần chưa biết và báo sớm khi thấy sắp trễ.
Cuối cùng là coi việc xong khi mã chạy được trên máy mình. Việc chỉ thật sự xong khi đã được kiểm thử, được review, triển khai được và người khác đọc hiểu được.
Thói quen làm việc với mã nguồn người lâu năm giữ suốt nghề
Những thói quen dưới đây không phụ thuộc ngôn ngữ hay công nghệ, nên người đi trước truyền lại cho người mới ở hầu hết các nhóm phát triển:
- Đọc thông báo lỗi đến hết. Rất nhiều lỗi đã được mô tả khá rõ trong chính thông báo lỗi, chỉ là người mới lướt qua dòng đầu rồi đi tìm trên mạng.
- Thay đổi nhỏ, lưu lại thường xuyên. Mỗi lần ghi thay đổi vào hệ thống quản lý phiên bản chỉ nên chứa một việc, kèm mô tả rõ làm gì và vì sao.
- Viết cho người đọc sau. Đặt tên biến, tên hàm nói rõ ý nghĩa; chú thích giải thích vì sao chứ không chỉ lặp lại mã đang làm gì.
- Viết kiểm thử cho phần mình sửa. Kiểm thử giúp người sau dám sửa mã mà không sợ phá vỡ thứ đang chạy.
- Ghi nhật ký hệ thống có ích. Khi có sự cố lúc nửa đêm, nhật ký rõ ràng là thứ giúp người trực tìm ra nguyên nhân.
- Ghi lại điều đã học. Một tệp ghi chú cá nhân về các lỗi đã gặp, cách cấu hình môi trường, lệnh hay dùng giúp tiết kiệm rất nhiều thời gian về sau.
Những thói quen này nghe cơ bản, nhưng nhìn vào lịch sử thay đổi và cách đặt tên trong mã của một người, người lâu năm có thể đoán khá chính xác người đó đã làm nghề cẩn thận đến đâu.
An toàn dữ liệu và hệ thống: những lời dặn không có ngoại lệ
Sao lưu trước khi chạy lệnh xoá hay sửa hàng loạt. Lệnh xoá dữ liệu, cập nhật hàng loạt, thay đổi cấu trúc cơ sở dữ liệu cần có bản sao lưu và cách quay lại trước khi chạy. Người lâu năm nào cũng có một câu chuyện về lần quên điều này.
Không để mật khẩu, khoá bí mật trong mã nguồn. Mã nguồn được chia sẻ, sao chép, đẩy lên nhiều nơi. Thông tin bí mật đặt trong tệp cấu hình riêng hoặc công cụ quản lý bí mật mà nhóm quy định, và không bao giờ được đưa vào kho mã.
Phân biệt rõ môi trường thử và môi trường thật. Nhiều sự cố nghiêm trọng bắt đầu từ việc chạy một lệnh thử trên hệ thống thật. Đặt tên, màu sắc, quyền truy cập khác nhau cho từng môi trường để khó nhầm.
Dữ liệu người dùng chỉ dùng cho đúng mục đích. Lập trình viên thường có quyền xem dữ liệu khách hàng để sửa lỗi. Quyền đó không có nghĩa là được tò mò xem, sao chép ra ngoài hay dùng cho việc khác. Quy định về bảo vệ dữ liệu cá nhân hiện hành áp dụng cho cả người làm kỹ thuật.
Thận trọng với thay đổi sát giờ nghỉ. Triển khai thay đổi lớn ngay trước kỳ nghỉ hay cuối ngày làm việc mà không có người trực là cách để sự cố xảy ra khi không ai kịp xử lý. Nhiều nhóm có quy tắc riêng về thời điểm triển khai, người mới nên hỏi và làm theo.
Review mã: người mới hay phản ứng thế nào và nên làm gì
Review mã là lúc người mới học được nhiều nhất, nhưng cũng là lúc dễ tự ái nhất. Bảng dưới gom những phản ứng quen thuộc và cách người lâu năm khuyên làm.
| Tình huống | Người mới hay làm | Nên làm |
|---|---|---|
| Nhận nhiều góp ý trên một thay đổi | Cảm thấy bị chê, sửa qua loa | Đọc từng góp ý, hỏi lại chỗ chưa hiểu, sửa và trả lời từng điểm |
| Không đồng ý với góp ý | Im lặng sửa theo hoặc tranh cãi gay gắt | Giải thích lý do bằng lập luận kỹ thuật, chấp nhận quyết định chung của nhóm |
| Thay đổi quá lớn, review lâu | Gửi một lần cả nghìn dòng | Chia nhỏ thành nhiều thay đổi, mỗi thay đổi một mục đích |
| Được nhờ review mã người lâu năm | Ngại góp ý | Hỏi những chỗ chưa hiểu; câu hỏi của người mới thường chỉ ra chỗ mã khó đọc |
| Góp ý lặp lại nhiều lần | Sửa từng lần | Ghi lại thành danh sách tự kiểm trước khi gửi review |
Người đi trước thường nhắc rằng review mã nhận xét về mã, không nhận xét về con người. Nhóm nào giữ được tinh thần đó thì người mới tiến bộ rất nhanh.
Khi gây ra sự cố: cách người lâu năm xử lý
Lập trình viên nào làm đủ lâu cũng từng gây ra sự cố: một lỗi làm trang web ngừng chạy, một thay đổi làm sai dữ liệu, một lệnh chạy nhầm môi trường. Điều người đi trước dặn người mới không phải là đừng bao giờ gây sự cố, mà là khi gây ra thì làm gì.
Việc đầu tiên là báo ngay cho người phụ trách, nói rõ mình đã làm gì, lúc nào, thấy hiện tượng gì. Giấu đi vài chục phút để tự sửa thường làm sự cố lớn hơn và mất lòng tin nhiều hơn. Việc thứ hai là ưu tiên khôi phục dịch vụ trước, tìm nguyên nhân gốc sau.
Sau khi xử lý xong, nhiều nhóm làm một buổi rà soát sự cố theo tinh thần không đổ lỗi: chuyện gì đã xảy ra, vì sao hệ thống cho phép nó xảy ra, cần thay đổi gì để không lặp lại. Người mới nên tham gia những buổi như vậy, kể cả khi sự cố không phải do mình, vì đó là nơi học được nhiều nhất về cách hệ thống thật vận hành.
Ví dụ giả định: anh Khoa, lập trình viên mới ở một công ty bán hàng trực tuyến, chạy nhầm một đoạn lệnh cập nhật giá trên dữ liệu thật. Anh báo trưởng nhóm ngay trong vài phút, nhóm khôi phục từ bản sao lưu. Buổi rà soát sau đó không phê bình anh mà thêm một bước xác nhận bắt buộc trước mọi lệnh cập nhật hàng loạt.
Hiểu nghiệp vụ và sức bền nghề
Một lời dặn người lâu năm hay nhắc là đừng chỉ hiểu mã, hãy hiểu việc mà mã phục vụ. Phần mềm kế toán thì cần hiểu một chút kế toán, phần mềm bán hàng thì cần hiểu đơn hàng, kho, đổi trả. Lập trình viên hiểu nghiệp vụ hỏi được những câu đúng, phát hiện được yêu cầu mâu thuẫn trước khi viết mã, và được tin giao những phần quan trọng.
Về sức bền, nghề lập trình ngồi nhiều, nhìn màn hình nhiều, và đôi khi phải làm thêm giờ khi có sự cố. Người lâu năm thường giữ vài thói quen: đứng dậy vận động sau mỗi khoảng làm việc, chỉnh bàn ghế và màn hình cho đúng tư thế, nghỉ mắt định kỳ, không biến làm đêm thành thói quen. Đau lưng, đau cổ tay kéo dài nên được khám sớm.
Cuối cùng là học liên tục mà không chạy theo mọi thứ mới. Công nghệ ra đời liên tục, và người mới dễ cảm thấy phải học hết. Người đi trước thường khuyên nắm thật chắc nền tảng như cấu trúc dữ liệu, cơ sở dữ liệu, mạng, bảo mật cơ bản, vì những thứ đó thay đổi chậm và giúp học công nghệ mới nhanh hơn.
Người đi trước kèm lập trình viên mới thế nào
Ở nhiều nhóm phát triển, người mới được gán một người hướng dẫn trong vài tháng đầu. Cách kèm hiệu quả thường gồm những bước sau:
- Tuần đầu, cùng cài môi trường làm việc và đi một vòng qua kiến trúc hệ thống, chỉ ra những phần quan trọng và những phần nguy hiểm.
- Giao một việc nhỏ nhưng đi trọn quy trình: đọc yêu cầu, viết mã, kiểm thử, review, triển khai.
- Lập trình cặp vài buổi: người đi trước gõ, người mới quan sát và hỏi; sau đó đổi vai.
- Review mã của người mới kỹ, giải thích vì sao chứ không chỉ ghi "sửa lại".
- Hẹn một buổi trò chuyện ngắn mỗi tuần để người mới hỏi những điều ngại hỏi trong nhóm.
- Tăng dần độ khó và để người mới tự chịu trách nhiệm một phần hệ thống khi họ đã vững.
Kèm cặp tốn thời gian của người đi trước trong vài tháng, nhưng một người mới được kèm tử tế thường đóng góp thật sớm hơn nhiều so với người bị để tự bơi.
Câu hỏi thường gặp
Lập trình viên mới bị kẹt bao lâu thì nên hỏi?
Không có con số chung, nhưng nhiều nhóm khuyên tự thử trong một khoảng thời gian có giới hạn, ghi lại những gì đã thử, rồi hỏi kèm thông tin đó. Ngồi im cả ngày với một lỗi tốn thời gian của cả nhóm hơn là hỏi đúng lúc.
Có nên viết lại mã cũ khó hiểu không?
Hãy đọc và hiểu vì sao mã được viết như vậy trước. Nhiều đoạn mã trông lạ nhưng xử lý những trường hợp đặc biệt mà người mới chưa biết. Nếu vẫn cần viết lại, trao đổi với nhóm, có kiểm thử đi kèm và làm từng bước nhỏ.
Lỡ đưa mật khẩu vào kho mã thì xử lý thế nào?
Báo ngay cho người phụ trách và đổi mật khẩu hoặc khoá đó càng sớm càng tốt, vì xoá khỏi mã không xoá được khỏi lịch sử. Sau đó làm theo hướng dẫn của nhóm để dọn lịch sử và đưa thông tin bí mật ra cấu hình riêng.
Làm sao để không tự ái khi review mã bị góp ý nhiều?
Nhớ rằng góp ý nhắm vào mã chứ không nhắm vào bạn. Đọc từng góp ý, hỏi lại chỗ chưa hiểu, ghi những lỗi lặp lại thành danh sách tự kiểm. Sau vài tháng, số góp ý giảm rõ và bạn sẽ thấy mình tiến bộ.
Gây ra sự cố trên hệ thống thật thì lập trình viên mới nên làm gì?
Báo ngay cho người phụ trách, nói rõ đã làm gì và thấy gì, ưu tiên khôi phục dịch vụ. Sau đó tham gia rà soát để tìm nguyên nhân và cách phòng tránh. Giấu sự cố để tự sửa thường làm hậu quả lớn hơn.
Lập trình viên mới nên học gì ngoài ngôn ngữ đang dùng?
Nền tảng thay đổi chậm như cấu trúc dữ liệu, cơ sở dữ liệu, mạng và bảo mật cơ bản, cộng với hiểu nghiệp vụ của sản phẩm mình làm. Những thứ này giúp học công nghệ mới nhanh hơn và hỏi được những câu đúng.
