Developer Giỏi Không Nhất Thiết Phải Biết Nhiều Ngôn Ngữ

Cập nhật ngày: 25/04/2024 - Đã có 624 lượt xem bài viết này!
Developer Giỏi Không Nhất Thiết Phải Biết Nhiều Ngôn Ngữ
Để 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.

Developer Giỏi Không Nhất Thiết Phải Biết Nhiều Ngôn Ngữ

Cùng đọc bài phỏng vấn với anh Nguyễn Xuân Huy – Tech Architect của Cybozu Vietnam – để nghe anh chia sẻ về:

-  Những kinh nghiệm của anh để trở thành một developer 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

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.

Anh có thể chia sẻ quá trình làm việc và phát triển tại Cybozu được không?

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 dev, 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.

imicrosoft-developer-gioi-khong-nhat-thiet-phai-biet-nhieu-ngon-ngu

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 feature 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…

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 dev, 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.

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 developer mới cho công ty.

Anh cũng từng tham gia vào quy trình tuyển dụng cho công ty, vậy tiêu chí của anh đối với developer của 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.

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.


BTV.Trần Thị Thu Huyền
Phòng Truyền Thông IMicroSoft Việt Nam
Hotline: 0916 878 224
Email: huyenttt@imicrosoft.edu.vn

 

Bạn đang muốn tìm kiếm 1 công việc với mức thu nhập cao.
✅ Hoặc là bạn đang muốn chuyển đổi công việc mà chưa biết theo học ngành nghề gì cho tốt.
✅ Giới thiệu với bạn Chương trình đào tạo nhân sự dài hạn trong 12 tháng với những điều đặc biệt mà chỉ có tại IMIC và đây cũng chính là sự lựa chọn phù hợp nhất dành cho bạn:
👉 Thứ nhất: Học viên được đào tạo bài bản kỹ năng, kiến thức chuyên môn lý thuyết, thực hành, thực chiến nhiều dự án và chia sẻ những kinh nghiệm thực tế từ Chuyên gia có nhiều năm kinh nghiệm dự án cũng như tâm huyết truyền nghề.
👉 Thứ hai: Được ký hợp đồng cam kết chất lượng đào tạo cũng như mức lương sau tốt nghiệp và đi làm tại các đối tác tuyển dụng của IMIC. Trả lại học phí nếu không đúng những gì đã ký kết.
👉 Thứ ba: Cam kết hỗ trợ giới thiệu công việc sang đối tác tuyển dụng trong vòng 10 năm liên tục.
👉 Thứ tư: Được hỗ trợ tài chính với mức lãi suất 0 đồng qua ngân hàng VIB Bank.
👉  Có 4 Chương trình đào tạo nhân sự dài hạn dành cho bạn lựa chọn theo học. Gồm có:
1)  Data Scientist full-stack
2)  Embedded System & IoT development full-stack
3)  Game development full-stack
4)  Web development full-stack 
✅ Cảm ơn bạn đã dành thời gian lắng nghe những chia sẻ của mình. Và tuyệt vời hơn nữa nếu IMIC được góp phần vào sự thành công của bạn. 
✅ Hãy liên hệ ngay với Phòng tư vấn tuyển sinh để được hỗ trợ về thủ tục nhập học.
✅ Chúc bạn luôn có nhiều sức khỏe và thành công!

 

Tham khảo các khóa đào tạo nhân sự qua danh mục