Bài viết sau là chia sẻ từ kinh nghiệm cá nhân của tác giả Stephen McLean. Sau hơn 04 năm lăn lộn với sự nghiệp phát triển phần mềm, anh ấy đã rút ra được 05 bài học bổ ích cho các lỗi sau mà mọi nhà phát triển đều dễ mắc phải.

Không bao giờ “cho rằng…”

Dự án đầu tiên của tôi là một nhiệm vụ ngắn hạn cho một dự án dài hạn. Dự án đã đi qua nhiều sprint và nhiều nhà phát triển. Cơ sở mã lớn, phức tạp và có nhiều tích hợp với các dịch vụ bên ngoài.

Nhiệm vụ đầu tiên của tôi là sửa một số bài kiểm tra đơn vị không liên tục. Mã đang được thử nghiệm tương đối cũ và được viết bởi một nhà phát triển cấp cao. Vì chức năng hoạt động tốt từ giao diện người dùng và đã được kiểm tra kỹ lưỡng bởi QA, tôi đã đưa ra giả định rằng vấn đề phải do chính các bài kiểm tra.

Tôi đã dành gần ba ngày để cố gắng sửa các bài kiểm tra không bị hỏng. Khi tôi giải thích với trưởng nhóm của mình tại sao việc sửa lỗi diễn ra quá lâu, anh ấy đã dạy tôi bài học quan trọng đầu tiên. Anh ấy nói với tôi rằng đừng bao giờ cho rằng mã của người khác là đúng chỉ vì nó trông có vẻ như vậy.

Đó có lẽ là bài học quan trọng nhất mà tôi đã học được và có thể áp dụng cho nhiều tình huống, không chỉ liên quan đến mã:

1. Đừng bao giờ cho rằng ai đó sẽ làm điều gì đó chỉ vì bạn đã yêu cầu họ. Hãy luôn có được một thỏa thuận rõ ràng. Bạn chưa nhận được câu trả lời từ người mà bạn đã yêu cầu kiểm tra điều gì đó? Gửi email follow-up. Chính bạn phải đảm bảo việc quan trọng đó được thực thi đầy đủ.
2. Đừng bao giờ cho rằng ai đó hiểu những gì bạn đã nói với họ, ngay cả khi họ khẳng định là hiểu. Đây là điều tôi học được sau khi phát triển sự nghiệp của mình đến mức tôi đã giúp cố vấn cho nhiều junior developer. Hãy nhờ junior developer mà bạn hướng dẫn trình bày với bạn về những gì đã được thảo luận để bạn có thể chắc chắn rằng họ hiểu. Điều này không chỉ áp dụng cho các nhà phát triển cố vấn, chẳng hạn như giải thích điều gì đó cho BA / QA’s, v.v đều có thể thực hiện tương tự.
3. Đừng bao giờ cho rằng đối phương sai. Tôi nghĩ rằng các nhà phát triển có xu hướng đổ lỗi cho mọi người khác về việc mã của họ không hoạt động. Đôi khi bạn bảo vệ code của mình quá mức đến độ bạn tin rằng nó không thể sai. Nếu QA cho bạn biết họ đã gặp sự cố, họ có lý do để làm như vậy. Hãy kiểm tra và cho họ thấy nghi ngờ của họ là đúng hay sai, hơn là “đóng sập cửa” ngay từ đầu.

Các vấn đề phi kỹ thuật là khó nhất

Ở trường đại học, tất cả các vấn đề đều là kỹ thuật. Tìm ra cách làm cho một đoạn mã hoạt động gần như luôn là vấn đề trong tầm tay. Tuy nhiên, trong cuộc sống nghề nghiệp, tôi thấy rằng điều đó hiếm khi xảy ra.

Đảm bảo giao tiếp rõ ràng trong một nhóm lớn làm việc trên nhiều múi giờ. Đảm bảo các quy trình hoạt động và được lập thành văn bản rõ ràng. Tìm ra cách giúp đỡ các thành viên trong nhóm hoặc cố vấn cho các thành viên mới trong nhóm. Cố gắng giới thiệu một cách trôi chảy điều gì đó mới cho quá trình phát triển. Thuyết phục ban quản lý dự án tập trung vào sức khỏe mã lâu dài khi các con số đang thúc đẩy chương trình nghị sự của họ trong hiện tại.

Đây chỉ là một số ví dụ cho thấy những thứ bạn có thể gặp phải trong một dự án. Theo ý kiến ​​của tôi, chúng khó khăn hơn gấp nhiều lần so với việc truy tìm con trỏ null đang làm phiền bạn.

Nghĩ trước, code sau

Bạn phát hiện ra một quá trình có thể được cải thiện. Bạn ngay lập tức quyết định tự động hóa nó. Bạn dành mỗi giờ rảnh rỗi để phát triển một thứ gì đó sẽ thay đổi hoàn toàn cách thức hoạt động của nhóm bạn.

Nghe quen thuộc đúng không? Các nhà phát triển, bao gồm cả tôi, yêu thích các giải pháp tự động.

Tôi đã học được gì? Đừng bắt tay vào code ngay lập tức. Hãy dừng lại, và nghĩ về vấn đề, không phải giải pháp. Nói chuyện với nhiều người, không chỉ nhà phát triển. Trước tiên, hãy tìm hiểu xem vấn đề là vấn đề kỹ thuật hay vấn đề quy trình. Sau đó, bạn có thể tìm ra giải pháp.

Chắc chắn, việc đưa ra một số giải pháp phức tạp bằng Docker và các tập lệnh được viết hoàn hảo sẽ rất tuyệt và bạn có thể học được nhiều điều tốt, nhưng đề xuất một giải pháp kỹ thuật cho một vấn đề không liên quan đến kỹ thuật có thể sẽ không giúp ích gì cho nhóm về lâu dài . Nó có thể chỉ che dấu vấn đề lớn hơn.

Thành phẩm của bạn quan trọng hơn những công cụ được sử dụng để tạo ra nó

Khi tốt nghiệp, tôi thích viết mã, học các ngôn ngữ và framework mới, và bất cứ thứ gì liên quan đến yếu tố kỹ thuật.

Đừng hiểu sai ý tôi, tôi bây giờ vẫn vậy. Nhưng, tôi nhận ra rằng miễn là các công cụ mà chúng tôi sử dụng với tư cách là nhà phát triển cho phép chúng tôi hoàn thành công việc của mình, thì những công cụ đó là gì không quan trọng. Trong quá trình phát triển front-end, cứ cách ngày lại có một framework mới. Và mặc dù điều quan trọng là nhà phát triển phải theo kịp, nhưng người dùng cuối (những người quan trọng), không quan tâm đến cách hoạt động của một thứ gì đó, chỉ cần nó hoạt động.

Mọi vai trò đều quan trọng như nhau

Tôi đã đề cập đến tầm quan trọng của việc không tự động cho rằng tất cả những người không phải là nhà phát triển đều sai. Ngoài ra, tôi đã học được rằng mỗi thành viên tạo nên nhóm của bạn (BA, QA, quản lý dự án, các bên liên quan khác, v.v.) cũng quan trọng như bất kỳ nhà phát triển nào.

Một dự án sẽ không hoạt động nếu không có sự đại diện của từng vai trò và tương tự cũng không hoạt động nếu nguồn cung ứng không được chia sẻ đồng đều giữa các loại tài nguyên khác nhau.

Tôi đã học được rằng mặc dù chính nhà phát triển viết code, nhưng sẽ không cần code nếu không có các bên liên quan yêu cầu, và sẽ không có bên liên quan nào nếu không đảm bảo chất lượng cho những gì họ cần.

Tổng hợp việc làm IT - Software trên VietnamWorks
VietnamWorks InTECH
Theo freecodecamp