“Để phát triển tại công ty product, một developer giỏi không nhất thiết phải biết nhiều ngôn ngữ… Kiến thức nền tảng và niềm đam mê mới là cái cốt lõi để bạn tiến xa hơn trong công việc.” Vậy thì công thức để trở thành một lập trình viên giỏi là gì?
Cùng đọc bài phỏng vấn của ITviec với anh Nguyễn Xuân Huy – Tech Architect của Cybozu Vietnam – để nghe anh chia sẻ về:
- Kinh nghiệm để trở thành lập trình viên giỏi cho công ty product
- Thử thách và khó khăn cùng những bài học mà anh học được trên con đường phát triển sự nghiệp của mình
Xem việc làm Developer chất trên ITviec
Anh có thể chia sẻ quá trình làm việc và
Tất nhiên. Anh bắt đầu với vị trí developer. Khoảng 4-5 năm đầu tiên, anh làm các dự án PHP. 5 năm trở lại đây, anh chuyển sang làm SharePoint.
1-2 năm đầu, do không biết gì về sản phẩm, anh phải học nhiều từ trainer của anh, đặc biệt là việc: ở vị trí junior developer, anh cần hoàn thành tốt công việc của mình trước, rồi mới tính đến những công việc khác. Và một trong những công việc khác mà anh nên làm trong thời gian rảnh, chính là RESEARCH.
Có nhiều thứ cần research. Là junior developer cho một công ty product, anh nhận ra rằng hiểu biết cặn kẽ về sản phẩm của công ty giúp anh thăng tiến rất nhanh, vì vậy anh dành nhiều thời gian research sản phẩm của công ty, đặc biệt là sản phẩm anh đang đảm nhiệm.
Cái cần research thứ hai chính là các vấn đề kỹ thuật. Khi vừa vào công ty, anh làm về PHP, vì vậy anh research công nghệ PHP. Anh hướng mình đến là một Full-stack Developer cho công ty Product, vì vậy không chỉ research về Programming, anh còn tìm hiểu thêm về modeling, cách vận hành hệ thống, UI/UX.
Là một developer của công ty product, bạn không nên chỉ biết lập trình, mà phải xây dựng được sản phẩm trên các môi trường khác nhau. Ban đầu, anh không rành về các hệ điều hành dành cho môi trường server, ví dụ như môi trường Linux, Windows Server, nên dành thời gian tìm hiểu về cách vận hành các hệ điều hành này.
Anh Huy ngồi thứ hai từ phải sang trái
Trong thời gian rảnh, ngoài việc research, anh còn làm gì nữa để phát triển bản thân?
Ở Cybozu có một hoạt động mà anh rất thích, chính là Research & Development (R&D). Nghĩa là mình tự nghĩ ra những ý tưởng hay tính năng mới cho sản phẩm rồi làm prototype, tức là sản phẩm mẫu, để 1) tự học hỏi, 2) áp dụng những kiến thức mình research.
Nếu ở công ty product mà các bạn đang làm không có hoạt động này thì anh khuyên các bạn cũng nên rủ một vài đồng nghiệp và tự mình thực hành điều này vào thời gian rảnh của các bạn. Tuy nó không phải là một project chính thức để release, nhưng lại là một project hữu ích để mình tự phát triển trong nội bộ.
Theo anh, ngôn ngữ lập trình có phải là yếu tố quan trọng nhất để phát triển sự nghiệp của một developer trong công ty product?
Ngôn ngữ lập trình không phải là yếu tố quan trọng nhất. Ngôn ngữ lập trình chỉ là công cụ mình phát triển sản phẩm. Cái quan trọng là tư duy để xây dựng sản phẩm.
Muốn xây dựng sản phẩm, ngoài lập trình, mình cần phải có kiến thức UI/UX để xây dựng giao diện giúp người dùng sử dụng thoải mái, dễ chịu; phải có kiến thức hệ điều hành để deploy sản phẩm. Mình cũng phải là người biết cài đặt và vận hành các môi trường ảo hóa như VMWare, VirtualBox v.v…
Xem thêm: Tại sao mọi developer cần học UI/UX
Trong quá trình phát triển, anh từng học được bài học nào tâm đắc nhất?
Làm lập trình viên, công việc chính là viết code. Khi mới bắt đầu, anh cũng hơi tùy tiện, viết theo đủ kiểu A, B, C. Có khi xem code cũ rồi viết lại, anh cũng không biết là nó tốt hay không. Trong quá trình làm, anh dần nhận ra cách viết code của mình không thống nhất và không hiệu quả nên anh tìm hiểu cách viết tốt hơn. Đây cũng chính là điều anh tâm đắc nhất trong cả sự nghiệp của mình.
Anh xem những điểm nào chưa hợp lý trong quá trình viết code của bản thân cũng như của anh em trong team rồi thảo luận cùng mọi người. Cuối cùng, anh rút ra được tiêu chí viết code (coding standard) cho anh nói riêng và team Việt Nam nói chung, đó là nó phải đáp ứng được 4 điểm:
1) Readability – phải dễ đọc, dễ hiểu
2) Mantainability – những người viết code tiếp theo của anh phải dễ dàng chỉnh sửa code anh đang viết
3) Security – phải đảm bảo không gây ra lỗ hổng về bảo mật (vulnerability)
4) Performance – phải đạt hiệu suất tốt
Công việc hàng ngày của anh là gì ạ?
Ngoài việc là developer chính cho dự án SharePoint mà anh chia sẻ ở trên, hàng ngày anh còn review code cho các bạn. Anh không review code ở mức chi tiết, mà chủ yếu là xem code có đáp ứng đủ 4 coding standard mà anh chia sẻ ở trên chưa.
Xem thêm: Góc nhìn của một chuyên gia SharePoint cho người mới nhập môn
Tùy thời điểm khác nhau, anh sẽ có những công việc khác nhau. Thỉnh thoảng, anh training cho các bạn về sản phẩm hoặc về các công nghệ mới, hay mà anh nghiên cứu được. Gần đây nhất, anh training về kiến thức lập trình cho QA, để họ ứng dụng trong việc thực hiện automation test cho sản phẩm. Thỉnh thoảng, anh tham gia vào quá trình tuyển dụng lập trình viên mới cho công ty.
Anh từng tham gia vào quy trình tuyển dụng lập trình viên, vậy tiêu chí tìm người mới cho một công ty product là gì?
Theo tiêu chí của anh, các bạn phải có kiến thức nền tảng tốt, không nhất thiết phải biết nhiều ngôn ngữ. Các bạn không chỉ cần có kiến thức về lập trình mà còn phải biết cơ bản về vận hành các hệ thống liên quan, ví dụ như database, web server, mail.
Kiến thức nền tảng là cái cốt lõi để một developer nói chung tiến xa hơn trong công việc.
Một thử thách mà mọi Tech Architect đều phải trải qua khi đã vào nghề là gì vậy anh?
Theo anh, đó là việc đưa ra quyết định chọn giải pháp phù hợp. Một vấn đề có nhiều giải pháp, và một giải pháp có thể là hay nhất nhưng chưa chắc là phù hợp để giải quyết vấn đề nhất.
Ví dụ anh phát hiện team A viết code chưa tốt, cài đặt hệ thống chưa tốt. Giải pháp tốt nhất là viết lại tất cả và cài đặt lại toàn bộ hệ thống để quá trình bảo trì và nâng cấp sau này được dễ dàng hơn. Tuy nhiên, việc này sẽ tốn nhiều thời gian, không phù hợp với hoàn cảnh là cần giao hàng cho khách hàng đúng hạn. Anh đã đưa ra phương án khác, sửa lại cách viết code một chút và chỉnh lại việc cài đặt hệ thống. Tuy phương án này không hoàn thiện bằng phương án kia, nhưng lại phù hợp với tình huống lúc bấy giờ.
Anh thường ra quyết định một mình hay còn tham khảo ý kiến của người khác?
Anh không bao giờ quyết định chủ quan. Khi gặp vấn đề, anh luôn có ý kiến của mình và nói chuyện với mọi người để tham khảo ý kiến của họ, mục đích là luôn luôn cùng nhau tìm ra những vấn đề đang tồn tại và tìm cách cải thiện tốt hơn.
Lấy ví dụ project của một sản phẩm mà anh đang phụ trách phát triển. Trong lần nâng cấp sản phẩm từ version 1.x lên version 2.0.0, anh đã quyết định redesign lại một số phần trong source code và UI.
Lý do anh đưa ra quyết định này là vì anh thảo luận với team và mọi người đều đồng ý là version 1.x có những điểm chưa tốt.
Ví dụ, trong source code của version cũ, một số chức năng chưa được thiết kế tốt để có thể tái sử dụng được (reusable); phần business logic code có khi bị gắn chặt (coupling) với phần controller; một số component dùng chung cũng chưa thực sự tiện lợi về cách sử dụng; phần code CSS, các CSS rule được định nghĩa cũng khá rối rắm.
Khi thực hiện redesign lại, các thành phần như controller, business logic code, UI control, javascript… đã được phân tách thành những component riêng biệt.
Sau này, khi thực hiện develop cho những phiên bản nâng cấp tiếp theo, anh nhận thấy quyết định của mình tại thời điểm trước đây là hợp lý. Chẳng hạn như ở lần nâng cấp sản phẩm để cung cấp thêm chức năng API (web service), anh có thể tái sử dụng được phần code đã được redesign lại từ version 2.0.0.
Kết quả là thời gian phát triển API được rút ngắn, số lượng vấn đề phát sinh ở những version tiếp theo nữa cũng giảm đáng kể.
Đặc biệt, qua dự án trên, anh cũng rút ra một bài học là: luôn tự đánh giá những điểm chưa tốt trong hiện tại và tìm hướng cải thiện. Khi có cơ hội thực hiện sự cải tiến, hãy thực hiện nó ở mức tốt nhất có thể.
Anh Huy chụp cùng đồng nghiệp tại công ty Cybozu
Anh từng mắc phải sai lầm nào và anh học được gì từ nó?
Lúc trước, khi đi học, anh tò mò muốn tìm hiểu về Linux nên cài đặt thử. Sau một hồi chật vật thì cũng thành công, nhưng tất cả dữ liệu thì cũng… đi hết trơn. Kể từ đó, anh rút ra bài học là: trong mọi thứ, mình cần biết rõ mình đang làm gì, có rủi ro gì không, và phải backup mọi thứ trước khi thử một thứ gì mới.
Anh có lời khuyên nào dành cho bạn muốn phát triển bản thân mình tại một công ty product?
Anh có 3 lời khuyên.
1) Khi bắt đầu, các bạn cần hoàn thành công việc của bản thân trước.
2) Phải có niềm đam mê và không đầu hàng. Vì khi nghiên cứu, có thể bạn chưa thấy hiệu quả trước mắt, nhưng tương lai sẽ có. Lúc trước, anh làm sản phẩm chính là PHP, nhưng do thích JavaScript, nên khi rảnh thì anh tìm hiểu. Thời điểm đó anh cũng chưa dùng đến JavaScript, nhưng sau này, JavaScript được sử dụng trong sản phẩm ngày càng nhiều hơn, anh dùng kiến thức đã tích lũy được để chia sẻ, hỗ trợ team, giúp mọi người viết code tốt hơn, ví dụ như viết như thế nào để có performance cao hơn.
Tìm hiểu thêm: 20+ Tài liệu JavaScript cơ bản đến nâng cao hay nhất
3) Nên chia sẻ kiến thức với mọi người. Xem việc chia sẻ là niềm vui. Một mình bạn không thể tìm hiểu hết mọi thứ. Việc mọi người chia nhau tìm hiểu rồi chia sẻ lại giúp tiết kiệm thời gian mà vẫn học được nhiều kiến thức mới.
Anh có thường xuyên tham khảo sách và resources nào trong suốt sự nghiệp của mình?
Có một vài quyển sách tác động sâu sắc đến suy nghĩ của anh.
1) Clean Code và Maintainable JavaScript. Hai quyển sách này giúp anh xây dựng coding standard. Nó hướng dẫn developer cách suy nghĩ để viết source code.
2) Patterns of Enterprise Application Architecture. Đây là sách về pattern để thiết kế hệ thống.
Tiểu sử:
Sau khi tốt nghiệp trường NIIT năm 2005, anh Huy làm việc cho Cybozu đến nay (thời điểm viết bài phỏng vấn này là tháng 6 năm 2015).
Cybozu là một công ty IT của Nhật Bản làm về 1) phần mềm groupware gọi là Cybozu Office chạy trên nền tảng web, 2) Cybozu Garoon, 3) kintone (chữ “k” viết thường), và một số sản phẩm khác.
Nếu bạn nghĩ những chia sẻ này có thể giúp ích cho bạn bè hoặc đồng nghiệp thì đừng ngại nhấn nút Share bên dưới nhé!
Xem thêm việc làm Developer chất trên ITviec