Lời khuyên cho người mới phát triển phần mềm
Là người phát triển phần mềm, nhiều người trong các bạn có lẽ còn nhớ tuần đầu tiên đi làm của mình. Là một sinh viên mới tốt nghiệp bắt đầu một nghề nghiệp mới trong công nghiệp, bạn có thể thấy công việc vừa kích động và thất vọng. Là một nhân viên mới, bạn muốn biết người khác nghĩ gì về bạn và làm sao bạn có thể là một phần của tổ của họ? Bạn có lẽ thấy rằng có nhiều điều bạn không biết và điều bạn đã học trong trường và điều xảy ra trong công ty khác biệt thế. Bạn muốn cảm thấy được đón chào nhưng không biết phải làm gì nên bạn cảm thấy lúng túng. Về căn bản, bạn không một mình bởi vì mọi người cũng cảm thấy theo cách đó khi họ là người mới với công việc.
Để tôi bắt đầu bằng kinh nghiệm riêng của mình quãng 40 năm trước đây. Trong việc làm đầu tiên của mình, tôi và vài người phát triển mới được trao nhiều tài liệu để đọc bởi vì mọi người trong công ty đều bận rộn và không có thời gian dành cho chúng tôi. Tôi phải uống nhiều cà phê để giữ cho mình tỉnh thức và tôi sợ vì tôi không hiểu gì về những tài liệu đó. Sau vài tuần dài uống nhiều cà phê, cuối cùng chúng tôi được phân công sửa một số mã trong một ứng dụng bảo trì. Chúng tôi coi lại hàng nghìn dòng mã mà ai đó đã viết để hiểu dự án này nhưng chúng tôi không biết phải làm gì vì phần lớn mã không có chú thích và không có tài liệu. Vào thời đó, ngôn ngữ lập trình là hợp ngữ, không phải là các ngôn ngữ bậc cao hơn như C++ hay Java ngày nay. Vài người mới không sửa được mã, và được bảo đi đọc lại thêm tài liệu. Tôi đã sửa được mã khi được bảo và sống sót qua nhiệm vụ đầu tiên đó. Sau sáu tháng, tôi có khả năng hiểu cách chương trình đó làm việc. Đáng sẽ cần thêm ba tháng nữa trước khi tôi hiểu chương trình này đầy đủ và bắt đầu đánh giá được nhiệm vụ được phân cho trong việc làm đầu tiên của mình. Lời khuyên của tôi với những người phát triển mới là bạn không nên cảm thấy thất vọng bởi vì mọi người có lẽ cũng cảm thấy theo cùng cách vì phải tốn thời gian để học mọi thứ với việc làm mới.
Kinh nghiệm của việc làm đầu tiên của tôi còn lại với tôi trong một thời gian dài. Ngày nay, là người quản lí cấp cao, tôi yêu cầu những người quản lí dự án phải dành thời gian cho các nhân viên mới, giúp họ và làm cho họ cảm thấy được đón chào trong vài tuần đầu tiên. Qui tắc đầu tiên của tôi là “Không xem tài liệu” ít nhất trong vài tháng đầu để cho không ai phải uống nhiều cà phê như tôi đã uống nhiều năm trước. Qui tắc thứ hai là người quản lí dự án và thành viên tổ phải ăn trưa cùng nhân viên mới trong vài tuần đầu để làm cho họ cảm thấy được đón chào, và dần biết họ. Tuy nhiên, tôi hiểu những người phát triển có kinh nghiệm nhìn người mới thế nào khi họ bắt đầu làm việc cùng nhau và đôi khi điều đó có thể làm thất vọng cho cả hai phía. Mọi người khác nhau thấy các vấn đề theo những cách khác nhau và có ý tưởng khác nhau về cách chúng có thể được giải quyết. Thật khó cho người phát triển có kinh nghiệm KHÔNG giận khi một thiết kế tốt được thực hiện theo cách thiếu kinh nghiệm và vụng về. Tất nhiên, người có kinh nghiệm có những cách nào đó để làm mọi sự và họ bao giờ cũng thích hay không thích những cách tiếp cận nào đó.
Tôi đã có nhiều thảo luận với những người phát triển có kinh nghiệm trên chủ đề này. Qua nhiều năm, tôi đã thu thập một số lời ghi chép mà tôi chia sẻ cùng các sinh viên ở Carnegie Mellon. Sau đây là cách nhìn của người phát triển có kinh nghiệm về nhân viên mới mà bạn có thể thấy có ích:
1) “Người mới không hỏi câu hỏi, họ dường như hiểu mọi thứ nhưng khi thực hiện, họ làm sai cả.” Tôi thấy rằng khác biệt chính thường là giữa “Lí thuyết và thực hành” hay “ý kiến cá nhân” về những cách tiếp cận nào đó. Người phát triển có kinh nghiệm biết đích xác cái gì cần làm và cách tiếp cận nào nên được dùng cho dự án này bởi vì họ quen thuộc với các qui trình của công ty. Những người mới KHÔNG như vậy, họ thử tạo ra giải pháp riêng của mình và thấy rằng nó đưa tới bất đồng nào đó. Cho dù không có "cách đúng" trong việc giải quyết vấn đề, cách tiếp cận tốt hơn là "Nếu bạn không biết, hỏi câu hỏi về cách tiếp cận nào nên được dùng. Hỏi người có kinh nghiệm để xem lại cách tiếp cận của bạn trước khi thực hiện nó.”
2) “Người mới không biết cách kiểm soát mã của họ. Họ không có khái niệm về quản lí cấu hình hay kiểm soát phiên bản. Họ làm lộn xộn mọi thứ.” Tôi thấy rằng nhiều người phát triển đã không thực sự hiểu rõ quản lí cấu hình, hoặc trường của họ không dạy điều đó hoặc họ không hiểu nó rõ. Đây là vấn đề về tri thức có thể được giải quyết với đào tạo thêm. Khái niệm về môi trường phát triển, môi trường kiểm thử, môi trường sản xuất hay đưa ra, kiểm soát sửa đổi, và số hiệu phiên bản nên được nhấn mạnh và cũng không mất lâu thời gian cho người phát triển mới hiểu khái niệm này.
3) “Người mới không thấy toàn thể bức tranh. Họ chỉ hội tụ vào một phần nhỏ chi tiết và bỏ lỡ mục đích chính.” Phải mất chút thời gian để học về cách toàn bộ hệ thống làm việc và hiểu cách tất cả các phần khớp với nhau. Trong khi điều tốt là bắt đầu với một phần nhỏ, tôi thường thấy rằng những người phát triển mới hội tụ quá nhiều vào chi tiết và chưa bao giờ thấy phần của họ làm gì cho toàn thể hệ thống. Hiểu cách toàn thể hệ thống làm việc là chủ đề về kiến trúc hệ thống, nhưng nhiều trường không dạy kiến trúc trong chương trình khoa học máy tính của họ. Tôi khuyến cáo rằng người quản lí dự án hay người phát triển có kinh nghiệm giải thích về kiến trúc hệ thống cho người phát triển mới sau khi họ đã làm việc được vài tháng với dự án. Người mới phải cảm thấy thoải mái với dự án và các chức năng của nó trước khi họ có thể đánh giá được thiết kế và kiến trúc hệ thống. Người mới cần hiểu rằng cho dù phân công việc của họ là một phần nhỏ nào đó nhưng các phần này khớp vào trong "hệ thống lớn”. Điều quan trọng là cần đọc tài liệu nào đó về dự án rồi hỏi các câu hỏi về cách mọi sự làm việc cùng nhau. Lời khuyên của tôi là “Nếu bạn không hiểu, hỏi các câu hỏi đi.” Không ai cười bạn khi bạn là mới và họ mong đợi rằng bạn sẽ hỏi các câu hỏi. Tuy nhiên, họ sẽ cảm thấy không thoải mái nếu bạn KHÔNG hỏi câu hỏi. “Không có câu hỏi tồi mà chỉ có im lặng tồi.”
4) “Một số người nghĩ họ khôn. Họ muốn thay đổi mọi thứ. Họ làm mọi thứ lộn xộn lên.” Tôi thấy rằng một số người phát triển mới muốn gây ấn tượng với người quản lí bằng cách gợi ý những điều mà họ có thể không hiểu hết. Một số đã tự làm mình bối rối khi họ cố thiết kế lại toàn thể hệ thống trong vài tháng đầu của họ. Vì họ muốn chứng tỏ rằng họ biết cái gì đó, họ thường cáu bẳn với nhiều người phát triển có kinh nghiệm. Lời khuyên của tôi là “Là người mới, bạn cần thời gian để học về hệ thống, cách thiết kế được thực hiện; lí do cho việc làm điều này theo cách đó, cũng như các cá tính của người phát triển khác. Bạn là một phần của tổ cho nên đừng cố đứng ra như người anh hùng bởi vì bạn biết cái gì đó. Điều tốt là bạn có thể có ý tưởng nào đó nhưng bạn còn cần biết lưu ý, đừng xúc phạm người nào, bạn có thể gợi ý cái gì đó cho tổ và hỏi ý kiến của họ. Cách tiếp cận tốt hơn là gặp những người có kinh nghiệm và yêu cầu họ thảo luận với bạn về cách tiếp cận của họ như một phần của việc học của bạn. Sau đó, bạn có thể chia sẻ điều bạn nghĩ với họ và yêu cầu phản hồi từ họ, bạn sẽ học nhiều hơn về họ vì họ cũng học cái gì đó từ bạn.
5) “Người mới không hiểu gì về qui trình phần mềm. Họ chỉ viết mã và phạm sai lầm.” Tôi thấy rằng khái niệm về qui trình phần mềm KHÔNG được dạy trong chương trình khoa học máy tính hay trong đào tạo ngôn ngữ lập trình. Mọi công ty thường có qui trình riêng của họ hay cách họ phát triển phần mềm. Một số qui trình là "chính thức" và một số thì không, và mọi người cần thời gian để học về nó. Chẳng hạn, kiểm điểm thiết kế và giám định mã là các qui trình rất nghiêm túc trong một số công ty nhưng các công ty khác có thể không để mấy chú ý vào nó. Phải mất thời gian để làm quen với qui trình công ty là gì và biết cách đi theo nó. Đây là điều khó bởi vì điều bạn đã học trong trường có thể không phải là điều công ty đang làm (Lại khác biệt giữa lí thuyết và thực hành). Lời khuyên của tôi là trước khi bạn làm cái gì đó, hỏi các câu hỏi và nếu cần, yêu cầu kiểm điểm qui trình trước khi thực hiện.
6) “Người mới chỉ viết mã. Họ không biết về thư viện tái dụng phần mềm và không làm mã tái dụng được.” Đây là điều chung mà hầu hết những người mới đều hăm hở viết mã mà không hiểu rằng một số chức năng hay đối tượng họ làm đã có rồi trong thư viện tái dụng. Tái dụng phần mềm thường KHÔNG được dạy trong nhiều chương trình khoa học máy tính. Nhiều người mới chỉ thích viết mã bởi vì đó là điều họ biết rõ. Tuy nhiên, nếu bạn viết mã theo cách riêng lẻ của mình thì đó KHÔNG phải là thiết kế cho tái dụng và KHÔNG thể được đặt vào trong thư viện tái dụng thì có thể bạn đang làm điều gì đó không hiệu quả. Bạn sẽ thấy rằng nhiều trong những chức năng hay đối tượng đó sẽ được cần tới lần nữa. Bạn cần nghĩ về tính năng suất và tính bảo trì được, vì chìa khoá của phát triển phần mềm thành công KHÔNG phải về viết mã mà là lắp ráp các mã đã có vào trong hệ thống mới. Mã tái dụng và kiến túc hệ thống là các khái niệm quan trọng của cách mọi người dựng phần mềm ngày nay.
Có thời gian để học và có thời gian để thực hiện. Là người phát triển mới, việc của bạn là học cách những người có kinh nghiệm khác thực hiện phần mềm trong công ty. Nếu bạn không hiểu, đừng ngần ngại hỏi các câu hỏi. Bạn sẽ có cơ hội để thực hiện và quan sát người khác học khi người mới được thuê vào trong công ty.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Lời khuyên cho sinh viên
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
