Ở kì trước, mình có khuyên các bạn Nên đặt câu hỏi vì sao (why) thay vì làm sao (how). Việc này sẽ giúp các bạn học sâu hơn, nhìn nhận vấn đề tốt hơn!

Ngay sau đó, mình lại nhận được một câu hỏi “Vì sao” khá hay từ vài bạn độc giả:

Anh ơi, tại sao các công ty họ lại thích dùng công nghệ cũ vậy ạ?
Em tự học, tự tìm hiểu Spring/Struts với Angular đồ; vào cty F lại dùng toàn đồ cũ, làm dự án toàn VB.NET rồi JSP rồi jQuery là sao anh?

Hẳn nhiều bạn sinh viên mới ra trường cũng có suy nghĩ tương tự nhỉ!

Bài viết này sẽ cho bạn một góc nhìn khác về các công nghệ mới, cũng như trả lời câu hỏi: Tại sao đa phần các công ty thích dùng công nghệ cũ??

Vì công nghệ cũ từng là công nghệ “mới”

Đa phần công việc của lập trình viên không phải là tạo ra một sản phẩm hoàn toàn mới, mà là bảo trì, cải tiến thêm chức năng cho những sản phẩm đã cũ.

Khi sản phẩm mới được tạo ra, các bác lập trình viên trước chúng ta đã lựa chọn những công nghệ mới nhất, tốt nhất vào lúc đó! Đến khi tới lượt chúng ta bảo trì, những công nghệ mới lúc xưa giờ đã trở thành “hàng cũ” mất rồi.

Ủa, vậy tại sao không nâng cấp nó lên?? Đây là chuyện nói dễ hơn làm:

1. Các bác lập trình viên lâu năm có một câu nói: If it ain’t broke, don’t fix it. Dịch nôm na là nếu nó vẫn hoạt động bình thường thì không cần sửa làm gì!
2. Đứng từ góc nhìn của PM, của khách hàng, họ chỉ nâng cấp khi bất khả kháng (tăng performance, sửa lỗ hổng bảo mật). Vì việc nâng cấp này sẽ tốn thời gian, công sức mà không đẹm lại nhiều hiệu quả

 

Các bạn thấy đấy, có thể các dự án bạn đang làm đã 5-10 năm tuổi Đảng (đặc biệt là các dự án COBOL, VB.NET của Nhật), chúng sử dụng công nghệ “lỗi thời” là chuyện rất bình thường.

Dự án mới, sao vẫn dùng công nghệ cũ?

Ủa, các dự án bảo trì dùng công nghệ cũ là chuyện đương nhiên ồi. Vậy còn các dự án mới thì sao, tại sao họ lại vẫn chọn dùng công nghệ cũ nhỉ?

Để hiểu lý do, các bạn phải biết hai điều:

• Công nghệ mới nhất không có nghĩa nó là công nghệ tốt nhất!
• Khi lựa chọn công nghệ cho một dự án, bản thân công nghệ chỉ là một trong nhiều yếu tố!

Thật vậy, khi lựa chọn công nghệ cho một dự án, người technical lead/software architecture thường đưa ra những câu hỏi sau:

• Công nghệ này có được nhiều người dùng không? Document có đầy đủ rõ ràng không?
• Công nghệ này có phù hợp với dự án hiện tại không?
• Team hiện tại có quen với công nghệ này không, hay phải bỏ thời gian training?

 

Những công nghệ mà ta tưởng “cũ”, công nghệ “lỗi thời” hoàn toàn đáp ứng được những yêu cầu trên:

• Công nghệ đã cũ, từng được nhiều người dùng, từng chạy trên production. Cộng đồng và document có rất nhiều và đầy đủ. Những lỗi quan trọng cũng đã được vá.
• Dự án cũ dùng công nghệ cũ thấy có vẻ ok. Dự án mới yêu cầu cũng na ná dự án cùng, sao không dùng cái cũ?
• Team hiện tại cũng đã có kinh nghiệm do đã từng dùng công nghệ này trong dự án trước, không phải tốn thời gian training

Ví dụ bên mảng front-end, nếu dùng những công nghệ “cũ” như jQuery, Angular 1 sẽ có nhiều người biết hơn Angular 2, VueJS, ReactJS. Khi team cần tuyển người cũng sẽ dễ tuyển hơn nhiều.

Developer chúng ta phải làm sao?

Thông thường, khi làm việc với công nghệ cũ, thường chúng ta sẽ cảm thấy khá nản, bực mình và bất mãn:

• Nản vì chúng ta phải học lại những công nghệ “lỗi thời”, giờ còn ít người sử dụng
• Bực mình là vì công nghệ cũ … dài dòng lôi thôi. Nếu đã quen với công nghệ mới, đôi khi bạn chỉ cần cài đặt hay setup vài dòng, công nghệ cũ phải viết và test cả chục dòng
• (Các bạn thử chuyển từ dùng ORM sang viết Query chay, hoặc chuyển từ React sang code jQuery xem).
• Bất mãn vì những thứ mình học sẽ không có giá trị về lâu dài, không có tác dụng bỏ vào CV xin việc sau này.

Nếu gặp trường hợp trên, có hai việc các bạn có thể làm

1. Học những thứ ngoài công nghệ “cũ”

Thật vậy, bạn học được rất nhiều trong môi trường làm việc.

Thay vì chỉ chăm chú vào công nghệ, các bạn có thể học được những điều sau:

• Học qui trình hoạt động của team và công ty
• Học business logic của sản phẩm mình đang làm. Như mình đang làm app về thị trường chứng khoán thì mình tìm hiểu về nó luôn
• Trong dự án cũ, có những architecture hay, design pattern hay có thể học được

2. Đề xuất thay đổi

Muốn thay đuổi, muốn dùng cái mới, chính bạn phải là người đề xuất!

Nếu làm trong startup, môi trường mở, họ sẽ dễ dàng tiếp nhận cái mới. Bạn cứ thử đặt vấn đề với team leader hoặc khách hàng, “dụ dỗ” họ là nếu dùng công nghệ mới ABC này thì code sẽ tốt và gọn hơn, tạo ra sản phẩm nhanh hơn.

Hãy nhớ rằng, với PM hoặc khách hàng, thứ họ quan tâm là năng suất làm việc và chất lượng sản phẩm, chứ không phải là công nghệ gì nên sử dụng.

Sau khi đề xuất, bạn có thể thử áp dụng công nghệ mới vào các module nho nhỏ trước. Như mình cũng từng để xuất dùng Firebase, Electron, NoSQL cho một số module của dự án cũ viết bằng AngularJS.

Chốt – Đừng kì thị công nghệ cũ

Điều quan trọng nhất là, đừng nên kĩ thị những công nghệ cũ! Đừng thấy nó cũ là nghĩ rằng nó “dỏm”, nó “lạc hậu”!

Nói nhỏ các bạn nghe nè, startup Slack – phần mềm chat nhóm nổi tiếng từng có technical stack là LAMP (Linux, Apache, MySQL, PHP). Phía front-end thì dùng jQuery, toàn những công nghệ “già đời” cả!

Khi chọn công nghệ hãy nhớ câu của Đặng Tiểu Bình: Mèo trắng hay mèo đen không quan trọng, miễn là nó bắt được chuột!

Code Dạo cũng có câu tương tự: Công nghệ cũ hay mới không quan trọng, miễn là nó tạo ra sản phẩm tốt!

Bài viết tham khảo thêm

• https://dev.to/liquid_chickens/hype-isnt-a-use-case-3a7
• http://mcfunley.com/choose-boring-technology
• https://dev.to/codemouse92/beware-the-trendites-26d