10 sai lầm phổ biến nhất mà Unity Developers mắc phải

Unity là một công cụ tuyệt vời và đơn giản sử dụng để phát triển đa nền tảng. Nguyên tắc của nó rất dễ hiểu và bạn có thể bắt đầu tạo ra sản phẩm của mình bằng trực giác.



Tuy nhiên, nếu một số điều không được lưu ý, chúng sẽ làm chậm tiến độ của bạn khi bạn tiến hành công việc của mình sang cấp độ tiếp theo, khi bạn đang chuyển từ giai đoạn nguyên mẫu ban đầu hoặc tiếp cận bản phát hành cuối cùng. Bài viết này sẽ cung cấp lời khuyên về cách khắc phục hầu hết các vấn đề phổ biến và cách tránh những sai lầm cơ bản trong các dự án mới hoặc hiện tại của bạn. Xin lưu ý nội dung của bài viết này tập trung nhiều hơn vào phát triển ứng dụng 3D, nhưng mọi thứ được đề cập đều có thể áp dụng cho phát triển 2D.
 
Unity là một công cụ tuyệt vời và đơn giản để sử dụng để phát triển đa nền tảng.

1: Đánh giá thấp giai đoạn lập kế hoạch dự án
Đối với mỗi dự án, trước khi nó bắt đầu điều quan trọng là phải xác định các vấn đề trước khi thiết kế và lập trình ứng dụng. Ngày nay, khi tiếp thị sản phẩm là một phần quan trọng của toàn bộ quá trình, điều quan trọng là phải có ý tưởng rõ ràng về mô hình kinh doanh của ứng dụng được triển khai sẽ là gì. Bạn phải chắc chắn những nền tảng nào bạn sẽ phát hành sản phẩm và những nền tảng nào trong kế hoạch của bạn. Cũng cần thiết lập các thông số kỹ thuật của các thiết bị được hỗ trợ tối thiểu (bạn sẽ hỗ trợ các thiết bị cấp thấp cũ hơn hay chỉ là các mẫu gần đây?) Để có ý tưởng về hiệu suất và hình ảnh bạn có thể mua. 
Cần phải thiết lập trước quy trình làm việc, ngân sách và mô hình khi cung cấp chúng cho lập trình viên, đặc biệt chú ý đến iteration process  khi các model sẽ cần thêm một số thay đổi và tinh chỉnh. Bạn nên có một ý tưởng rõ ràng về tốc độ khung hình và ngân sách mong muốn, chuyên gia thiết kế 3D có thể biết các mô hình phải có độ phân giải tối đa là bao nhiêu và có bao nhiêu biến thể LOD mà anh ta phải thực hiện. Nó cũng nên được chỉ định làm thế nào để thống nhất tất cả các tính toán để có một quy chuẩn nhất quán và quy mua bán trong toàn bộ ứng dụng.
Vấn đề cấp độ kế là rất quan trọng cho công việc trong tương lai vì sự phân chia cấp độ ảnh hưởng rất nhiều đến hiệu suất. Mối quan tâm về hiệu suất phải luôn luôn trong tâm trí của bạn khi thiết kế các cấp độ mới. Đừng đi với tầm nhìn không thực tế. Điều quan trọng là bạn luôn phải tự hỏi mình câu hỏi có thể đạt được một cách hợp lý không?).

2: Làm việc với các mô hình chưa được tối ưu hóa
Điều quan trọng là tất cả các mô hình của bạn được chuẩn bị tốt để có thể sử dụng chúng trong các cảnh mà không cần sửa đổi thêm. Có một số điều mà mô hình nên đáp ứng.
Điều quan trọng là thiết lập tỷ lệ chính xác. Đôi khi, không thể cài đặt chính xác điều này từ phần mềm mô hình 3D do các đơn vị khác nhau mà các ứng dụng này đang sử dụng. Để làm cho mọi thứ đều ổn, hãy đặt hệ số tỷ lệ trong cài đặt nhập model  (để lại 0,01 cho 3dsMax và Modo, đặt 1.0 cho Maya) và lưu ý rằng đôi khi bạn sẽ cần nhập lại các đối tượng sau khi thay đổi cài đặt tỷ lệ. Các cài đặt này phải đảm bảo rằng bạn chỉ có thể sử dụng tỷ lệ cơ bản 1,1,1 trong các cảnh của mình để có hành vi nhất quán và không gặp sự cố vật lý. Dynamic batching  cũng có nhiều khả năng sẽ hoạt động chính xác. Quy tắc này cũng nên được áp dụng trên mọi subobject trong mô hình, không chỉ object chính. Khi bạn cần điều chỉnh kích thước đối tượng, hãy cũng thực hiện điều đó đối với các đối tượng khác trong ứng dụng mô hình 3D thay vì trong Unity.  Tuy nhiên, bạn có thể thử nghiệm tỷ lệ trong Unity để tìm ra các giá trị phù hợp, đối với final application và quy trình làm việc nhất quán, điều đó thật tốt khi chuẩn bị tốt mọi thứ trước khi vào Unity.
Về chức năng của đối tượng và các bộ phận động của chúng. Càng ít subobject, càng tốt. Chỉ phân chia các đối tượng trong trường hợp khi bạn cần chúng, ví dụ, để di chuyển hoặc xoay động, cho mục đích hoạt hình hoặc các tương tác khác. Mọi object  và các subobjects  của nó phải có trục chính được căn chỉnh và xoay đúng với chức năng chính của nó. Object chính phải có trục Z hướng về phía trước và trục phải ở dưới cùng của đối tượng để có vị trí tốt hơn cho cảnh. Sử dụng càng ít materials trên các đối tượng càng.

3: Xây dựng kiến trúc mã phụ thuộc lẫn nhau
Tạo mẫu và triển khai chức năng trong Unity khá dễ dàng. Bạn có thể dễ dàng kéo và thả bất kỳ tham chiếu nào đến các đối tượng khác, địa chỉ hóa mọi đối tượng trong scene và truy cập mọi thành phần mà nó có. Tuy nhiên, điều này cũng có thể nguy hiểm. Vấn đề hiệu năng cũng có nguy cơ lớn trong việc khiến các phần code phụ thuộc vào nhau. Hoặc phụ thuộc vào các hệ thống và tập lệnh khác cho ứng dụng của bạn...  Cố gắng mô-đun hóa nhiều hơn, tạo các phần có thể tái sử dụng.
Có rất nhiều cách tiếp cận khác nhau để đảm bảo điều này. Một điểm khởi đầu tốt là chính hệ thống thành phần Unity. Các vấn đề có thể xuất hiện khi các thành phần cụ thể cần giao tiếp với các hệ thống khác của ứng dụng. Đối với điều này, bạn có thể sử dụng các giao diện để làm cho các phần của hệ thống trừu tượng hơn và có thể sử dụng lại. Ngoài ra, bạn có thể sử dụng cách tiếp cận theo hướng sự kiện để tương tác với các sự kiện cụ thể từ phạm vi bên ngoài, bằng cách tạo một hệ thống tin nhắn hoặc bằng cách registering  trực tiếp vào các bộ phận của hệ thống khác như listeners. Cách tiếp cận đúng sẽ cố gắng tách các thuộc tính của gameObject khỏi logic chương trình, bởi vì thật khó để xác định đối tượng nào đang sửa đổi các thuộc tính biến đổi của nó, như vị trí và xoay. 

4: Lãng phí hiệu suất 
Update Loops
 Đừng đi sâu về hiệu suất trong update loops, thay vào đó hãy sử dụng bộ nhớ đệm. Một ví dụ điển hình là quyền truy cập vào các thành phần, các đối tượng khác trong scene hoặc các tính toán chuyên sâu trong các tập lệnh. Nếu có thể, hãy lưu trữ mọi thứ trong Awake()các phương thức hoặc thay đổi kiến trúc thành một cách tiếp cận theo hướng sự kiện để kích hoạt ngay khi cần thiết.
Instantiations
 Đối với các đối tượng được khởi tạo thường xuyên (ví dụ: đạn trong trò chơi FPS), hãy tạo một nhóm khởi tạo và chỉ cần chọn một đối tượng đã được khởi tạo khi bạn cần nó. Sau đó, thay vì phá hủy nó khi không cần thiết nữa, hãy tắt nó và đưa nó trở lại nhóm.
Rendering
 Sử dụng các kỹ thuật loại bỏ tắc nghẽn hoặc LOD để hạn chế các phần được hiển thị của scene. Cố gắng sử dụng các mô hình được tối ưu hóa để có thể giữ vertex count trong scene  được kiểm soát. Vertex count bị ảnh hưởng bởi những thứ khác như UV coordinates (UV seams) and vertex colors.... Ngoài ra, một số dynamic lights trong scene sẽ ảnh hưởng đáng kể đến hiệu suất tổng thể, vì vậy hãy cố gắng giải quyết mọi thứ bất cứ khi nào có thể.
Draw Calls
 Cố gắng giảm số lượng draw calls. Trong Unity, bạn có thể thực hiện giảm draw calls bằng cách sử dụng static batching cho các đối tượng tĩnh và dynamic batching cho các đối tượng động. Tuy nhiên, trước tiên bạn phải chuẩn bị các scenes  và models (batched objects phải chia sẻ cùng một materials) và việc tạo các đối tượng động chỉ hoạt động đối với các mô hình độ phân giải thấp. Ngoài ra, bạn có thể kết hợp các meshes  theo tập lệnh thành một ( Mesh.CombineMeshes) thay vì sử dụng batching, nhưng bạn phải cẩn thận không tạo các đối tượng quá lớn không thể xem trên một số nền tảng. Nói chung, chìa khóa là sử dụng càng ít materials  càng tốt và chia sẻ chúng trên scene. Đôi khi bạn sẽ cần tạo các atlases  từ kết cấu để có thể chia sẻ một tài liệu giữa các đối tượng riêng biệt. 

Overdraw Problems
 Không sử dụng kết cấu trong suốt khi không cần thiết, vì nó sẽ gây ra vấn đề về tỷ lệ lấp đầy. Bạn có thể sử dụng nó cho hình học phức tạp và xa hơn, như cây hoặc bụi cây. Khi bạn cần sử dụng nó, hãy sử dụng các shader pha trộn alpha thay vì các shader với thử nghiệm alpha hoặc thay vì các shader cutout cho các nền tảng di động. Để xác định những vấn đề này nói chung, hãy cố gắng hạ thấp độ phân giải của ứng dụng của bạn. Nếu nó có ích, có thể bạn có những vấn đề về tỷ lệ lấp đầy này, hoặc bạn cần tối ưu hóa các shader của mình nhiều hơn. Nếu không, nó có thể là một vấn đề bộ nhớ nhiều hơn.
Shader
Tối ưu hóa shader của bạn để có hiệu suất tốt hơn. Giảm số lần vượt qua, sử dụng các biến có độ chính xác thấp hơn, thay thế các phép tính toán phức tạp bằng kết cấu tra cứu được tạo trước.
Luôn luôn sử dụng một hồ sơ để xác định các tắc nghẽn. Đó là một công cụ tuyệt vời. Để kết xuất, bạn cũng có thể sử dụng Trình gỡ lỗi khung tuyệt vời, điều này sẽ giúp bạn tìm hiểu rất nhiều về cách mọi thứ hoạt động chung khi phân tách các quy trình kết xuất với nó.
Lỗi thống nhất thường gặp # 5: Bỏ qua các vấn đề về thu gom rác
Cần phải nhận ra rằng mặc dù thực tế rằng chính Garbage Collector (GC) giúp chúng ta thực sự hiệu quả và tập trung vào những điều quan trọng trong lập trình, có một vài điều chúng ta nên nhận thức rõ ràng. Việc sử dụng GC không miễn phí. Nói chung, chúng ta nên tránh phân bổ bộ nhớ không cần thiết để ngăn không cho GC tự bắn quá thường xuyên và do đó làm hỏng hiệu suất bằng cách tăng tốc độ khung hình. Lý tưởng nhất là không nên có bất kỳ sự phân bổ bộ nhớ mới nào xảy ra thường xuyên ở mỗi khung hình. Tuy nhiên, làm thế nào chúng ta có thể đạt được mục tiêu này? Nó thực sự được xác định bởi kiến trúc ứng dụng, nhưng có một số quy tắc bạn có thể tuân theo để trợ giúp:
•    Tránh phân bổ không cần thiết trong các vòng cập nhật.
•    Sử dụng các cấu trúc cho các thùng chứa tài sản đơn giản, vì chúng không được phân bổ trên heap.
•    Cố gắng phân bổ các mảng hoặc danh sách hoặc các bộ sưu tập đối tượng khác, thay vì tạo chúng trong các vòng cập nhật.
•    Tránh sử dụng những thứ có vấn đề đơn lẻ (ví dụ như biểu thức LINQ hoặc vòng lặp foreach) vì Unity đang sử dụng phiên bản Mono cũ hơn, không được tối ưu hóa lý tưởng (tại thời điểm viết nó là phiên bản sửa đổi 2.6, với bản nâng cấp trên lộ trình).
•    Chuỗi bộ nhớ cache trong Awake()phương thức hoặc trong các sự kiện.
•    Nếu cập nhật thuộc tính chuỗi trong vòng lặp cập nhật là cần thiết, hãy sử dụng đối tượng StringBuilder thay vì chuỗi.
•    Sử dụng profiler để xác định các vấn đề tiềm ẩn.
Lỗi thống nhất thường gặp # 6: Tối ưu hóa bộ nhớ và sử dụng không gian Lần cuối
Cần phải chú ý đến mức sử dụng bộ nhớ và dung lượng thấp nhất của ứng dụng từ khi bắt đầu dự án, vì sẽ phức tạp hơn khi bạn tối ưu hóa cho giai đoạn tiền phát hành. Trên các thiết bị di động, điều này thậm chí còn quan trọng hơn, bởi vì chúng tôi khá thiếu về tài nguyên ở đó. Ngoài ra, bằng cách vượt quá 100 MB kích thước cài đặt, chúng tôi có thể mất một lượng khách hàng đáng kể. Điều này là do giới hạn 100 MB cho tải xuống mạng di động và cũng vì lý do tâm lý. Sẽ tốt hơn khi ứng dụng của bạn không lãng phí tài nguyên điện thoại quý giá của khách hàng và họ sẽ có nhiều khả năng tải xuống hoặc mua ứng dụng của bạn khi kích thước của nó nhỏ hơn.
Để tìm các bộ thoát tài nguyên, bạn có thể sử dụng nhật ký trình soạn thảo nơi bạn có thể thấy (sau mỗi bản dựng mới) kích thước của các tài nguyên được chia thành các danh mục riêng biệt, như âm thanh, kết cấu và DLL. Để định hướng tốt hơn, có các phần mở rộng trình chỉnh sửa trên Unity Asset Store, sẽ cung cấp cho bạn một bản tóm tắt chi tiết với các tài nguyên và tệp được tham chiếu trong hệ thống tệp của bạn. Tiêu thụ bộ nhớ thực tế cũng có thể được nhìn thấy trong trình lược tả, nhưng nên kiểm tra nó khi được kết nối để xây dựng trên nền tảng đích của bạn vì có nhiều sự không nhất quán khi thử nghiệm trong trình chỉnh sửa hoặc trên bất kỳ thứ gì khác ngoài nền tảng đích của bạn.
Người tiêu dùng bộ nhớ lớn nhất thường là kết cấu. Tốt hơn là sử dụng kết cấu nén vì chúng chiếm ít không gian và bộ nhớ hơn. Làm cho tất cả các kết cấu bình phương, lý tưởng nhất, làm cho độ dài của cả hai bên (POT), nhưng hãy nhớ rằng Unity cũng có thể tự động điều chỉnh kết cấu NPOT thành POT. Hoạ tiết có thể được nén khi ở dạng POT. Kết cấu Atlas với nhau để lấp đầy toàn bộ kết cấu. Đôi khi, bạn thậm chí có thể sử dụng kênh alpha kết cấu cho một số thông tin bổ sung cho trình đổ bóng của mình để tiết kiệm không gian và hiệu suất bổ sung. Và tất nhiên, hãy cố gắng sử dụng lại họa tiết cho các cảnh của bạn càng nhiều càng tốt, và sử dụng các kết cấu lặp lại khi có thể để giữ lại hình ảnh trực quan tốt. Đối với các thiết bị cấp thấp, bạn có thể hạ thấp độ phân giải của hoạ tiết trong Cài đặt chất lượng. Sử dụng định dạng âm thanh nén cho các clip âm thanh dài hơn, như nhạc nền.
Khi bạn đang xử lý các nền tảng, độ phân giải hoặc bản địa hóa khác nhau, bạn có thể sử dụng các gói nội dung để sử dụng các bộ kết cấu khác nhau cho các thiết bị hoặc người dùng khác nhau. Các gói tài sản này có thể được tải động từ internet sau khi ứng dụng được cài đặt. Bằng cách này, bạn có thể vượt quá giới hạn 100MB bằng cách tải xuống tài nguyên trong trò chơi.
Lỗi thống nhất thường gặp # 7: Những sai lầm vật lý thường gặp
Đôi khi, khi di chuyển các vật thể trong cảnh, chúng ta không nhận ra rằng vật thể có máy va chạm vào nó và việc thay đổi vị trí của nó sẽ buộc động cơ phải tính toán lại toàn bộ thế giới vật lý một lần nữa. Trong trường hợp đó, bạn nên thêm Rigidbodythành phần vào nó (bạn có thể đặt thành không động học nếu bạn không muốn các lực lượng bên ngoài tham gia).
Để sửa đổi vị trí của đối tượng với Rigidbodynó, luôn luôn đặt Rigidbody.positionkhi vị trí mới không tuân theo vị trí trước đó hoặc Rigidbody.MovePositionkhi đó là một chuyển động liên tục, cũng cần tính đến phép nội suy. Khi sửa đổi nó, áp dụng các hoạt động luôn luôn trong FixedUpdate, không phải trong các Updatechức năng. Nó sẽ đảm bảo các hành vi vật lý nhất quán.
Nếu có thể, hãy sử dụng các trình tạo mã nguyên thủy trên các trò chơi, như hình cầu, hộp hoặc hình trụ và không phải các trình tạo lưới. Bạn có thể soạn trình tạo collider cuối cùng của bạn từ nhiều hơn một trong số các collider này. Vật lý có thể là một nút cổ chai hiệu năng của ứng dụng của bạn do chi phí hoạt động của CPU và va chạm giữa các máy va chạm nguyên thủy nhanh hơn nhiều để tính toán. Bạn cũng có thể điều chỉnh cài đặt Dấu thời gian cố định trong Trình quản lý thời gian để giảm tần suất cập nhật cố định vật lý khi độ chính xác của tương tác vật lý không quá cần thiết.
Lỗi thống nhất thường gặp # 8: Kiểm tra thủ công tất cả các chức năng
Đôi khi có thể có xu hướng kiểm tra chức năng bằng tay bằng cách thử nghiệm trong chế độ phát vì nó khá thú vị và bạn có mọi thứ dưới sự kiểm soát trực tiếp của mình. Nhưng yếu tố mát mẻ này có thể giảm khá nhanh. Ứng dụng càng trở nên phức tạp, lập trình viên càng phải lặp đi lặp lại và suy nghĩ để đảm bảo rằng ứng dụng hoạt động như dự định ban đầu. Nó có thể dễ dàng trở thành phần tồi tệ nhất của toàn bộ quá trình phát triển, bởi vì tính chất lặp đi lặp lại và thụ động của nó. Ngoài ra, vì việc lặp lại thủ công các kịch bản thử nghiệm không thú vị, nên có nhiều khả năng một số lỗi sẽ xảy ra trong toàn bộ quá trình thử nghiệm.
Unity có các công cụ kiểm tra tuyệt vời để tự động hóa việc này. Với thiết kế mã và kiến trúc phù hợp, bạn có thể sử dụng các thử nghiệm đơn vị để kiểm tra chức năng biệt lập hoặc thậm chí kiểm tra tích hợp để thử nghiệm các kịch bản phức tạp hơn. Bạn có thể giảm đáng kể phương pháp thử và kiểm tra khi bạn đang ghi dữ liệu thực tế và so sánh nó với trạng thái mong muốn.
Kiểm tra thủ công chắc chắn là một phần quan trọng của sự phát triển. Nhưng số lượng của nó có thể được giảm, và toàn bộ quá trình có thể mạnh mẽ hơn và nhanh hơn. Khi không có cách nào có thể tự động hóa nó, hãy chuẩn bị các cảnh thử nghiệm của bạn để có thể giải quyết vấn đề mà bạn đang cố gắng giải quyết nhanh nhất có thể. Lý tưởng nhất là một vài khung hình sau khi nhấn nút play. Thực hiện các phím tắt hoặc cheat để đặt trạng thái mong muốn để thử nghiệm. Ngoài ra, làm cho tình huống thử nghiệm bị cô lập để chắc chắn điều gì gây ra vấn đề. Mỗi giây không cần thiết trong chế độ phát khi kiểm tra được tích lũy và độ lệch ban đầu của kiểm tra sự cố càng lớn, bạn càng không có khả năng kiểm tra sự cố, và bạn sẽ hy vọng rằng tất cả đều hoạt động tốt. Nhưng nó có lẽ sẽ không.
Sai lầm về sự thống nhất thường gặp # 9: Suy nghĩ Các plugin của cửa hàng tài sản Unity sẽ giải quyết tất cả các vấn đề của bạn
Tin tôi đi; họ sẽ không Khi làm việc với một số khách hàng, đôi khi tôi phải đối mặt với xu hướng hoặc dựa vào quá khứ sử dụng các plugin lưu trữ tài sản cho từng điều nhỏ nhặt. Tôi không có nghĩa là không có tiện ích mở rộng Unity hữu ích trên Unity Asset Store . Có rất nhiều trong số chúng, và đôi khi thật khó để quyết định chọn cái nào. Nhưng đối với mỗi dự án, điều quan trọng là duy trì tính nhất quán, có thể bị phá hủy bằng cách sử dụng không chính xác các phần khác nhau không phù hợp với nhau.
Mặt khác, đối với chức năng sẽ mất nhiều thời gian để bạn triển khai, việc sử dụng các sản phẩm được kiểm tra tốt từ Unity Asset Store luôn hữu ích, giúp bạn tiết kiệm rất nhiều thời gian phát triển. Tuy nhiên, hãy cẩn thận, sử dụng những lỗi đã được chứng minh sẽ không mang lại nhiều lỗi không thể kiểm soát và kỳ lạ cho sản phẩm cuối cùng của bạn. Đánh giá năm sao là một biện pháp tốt cho một sự khởi đầu.
Nếu chức năng mong muốn của bạn không khó thực hiện, chỉ cần thêm nó vào thư viện cá nhân (hoặc công ty) liên tục phát triển của bạn, có thể được sử dụng trong tất cả các dự án của bạn sau này. Bằng cách đó, bạn đang cải thiện kiến thức và bộ công cụ của mình cùng một lúc.
Sai lầm thống nhất thường gặp # 10: Không cần phải mở rộng chức năng cơ bản của Unity
Đôi khi có vẻ như môi trường Unity Editor khá đủ để thử nghiệm trò chơi cơ bản và thiết kế cấp độ, và việc mở rộng nó là một sự lãng phí thời gian. Nhưng tin tôi đi, không phải thế đâu. Tiềm năng mở rộng tuyệt vời của Unity đến từ việc có thể thích ứng nó với các vấn đề cụ thể cần được giải quyết trong các dự án khác nhau. Điều này có thể cải thiện trải nghiệm người dùng khi làm việc trong Unity hoặc tăng tốc đáng kể toàn bộ quy trình phát triển và thiết kế cấp độ. Thật đáng tiếc nếu không sử dụng các tính năng tích hợp sẵn, như Trình vẽ thuộc tính tích hợp hoặc tùy chỉnh, Trình vẽ trang trí, cài đặt trình kiểm tra thành phần tùy chỉnh hoặc thậm chí không xây dựng toàn bộ plugin bằng Windows Editor của chính nó.

 Hy vọng những chủ đề này sẽ hữu ích cho bạn khi bạn di chuyển các dự án Unity của mình hơn nữa. Có rất nhiều điều cụ thể theo dự án, vì vậy chúng không thể được áp dụng, nhưng luôn có ích khi có một số quy tắc cơ bản khi cố gắng giải quyết các vấn đề khó khăn và cụ thể hơn. Bạn có thể có ý kiến hoặc quy trình khác nhau về cách giải quyết những vấn đề này trong các dự án của bạn. Điều quan trọng nhất là giữ cho các thành ngữ của bạn nhất quán trong suốt dự án của bạn để bất kỳ ai trong nhóm của bạn có thể hiểu rõ cách thức tên miền cụ thể phải được giải quyết chính xác.

 

Share:

ĐỐI TÁC LIÊN KẾT TUYỂN DỤNG NHÂN SỰ CỦA IMIC TECHNOLOGY

IMIC Technology

IMIC Technology tự hào là doanh nghiệp đầu tiên tại Việt Nam triển khai các Chương trình Đào tạo chuyên môn dự án cho Học viên ngành CNTT/CNPM. Cũng là một trong những doanh nghiệp đạt được nhiều giải thưởng lớn trong lĩnh vực này. Góp phần phát triển mạnh ngành CNTT/CNPM tại nước ta hiện nay.