Software architecture!
Bài viết này mình cóp nhặt được (ở đâu thì quên rồi). Nói chung cũng học hỏi được nhiều.
Đây là 1 câu hỏi khá hay. Tôi thấy ít nguời chịu tìm hiểu có lẽ vì vậy một số nguời khi diễn giải hay nhầm lẫn giữa architecture (kiến trúc) và framework (nền tảng).
1) Software Architecture hay tạm dịch bên tiếng Việt Kiến trúc phần mềm. Đúng với cái nghĩa kiến trúc, software architecture bao gồm các bộ phận phần mềm liên quan mật thiết với nhau trong 1 hệ thống. Tạm muợn khái niệm về kiến trúc phần mềm của Ian Sommerville (Software Engineering 6th Edition) thì trong quá trình phát triển, một hệ thống lớn thuờng đuợc chia ra thành nhiều hệ thống nhỏ (sub-system). Những hệ thống nhỏ này sẽ cung cấp những dịch vụ (set of services) có liên quan với nhau. Quá trình (process) nhận dạng, phân chia, và thiết kế các hệ thống nhỏ naỳ, cùng với việc tạo dựng 1 nền tảng (framework) cho chúng cũng như sự liên lạc giữa các hệ thống nhỏ này đuợc gọi là architectural design và kết quả của quá trình trình thường nằm trong 1 bản thảo (documentation) đuợc mô tả như là software architecture. Môt vài ví dụ của software architecture như là: client-server (rất phổ biến), 3-tier hay n-tier, distributed-computing, service-oriented và 1 số khác ít phổ biến hơn (plug,etc).
2) Bây giờ nói về Framework. Như giải thích ở phần trên framework là 1 thành phần nhỏ trong quá trình kiến trúc phần mềm. Nếu tạm dùng danh từ "Nền Tảng" để diễn giải Framework thì chúng ta có thể hiểu nó như là 1 cấu trúc hổ trợ trong việc phát triển và tạo lập các phần mềm khác(nên nhớ bản thân Framework cũng là 1 phần mềm). Có lẽ chúng ta nghe nhiều về MS .Net Framework hay là Microsoft Application Framework (afx... remember those famous MS library functions in MFC!!!). Tóm lại framework là 1 công trình phần mềm đuợc xây dựng như 1 mốt nền tảng để dựa trên đó chúng ta có thể phát triển các phần mềm khác. Muốn thiết kế một framework đòi hỏi bạn phải hiểu rõ truớc hết framework này sẽ hổ trợ cho những gì bạn sẽ phát triển. Về kỹ thuật đa số framework sử dụng thiết kế và phát triển huớng đối tuợng do đó kiến thức về OO là cần thiết. Tôi lấy 1 ví dụ trong quá trình xây dựng 1 framework cho 1 phần mềm thu thập tin tức chứng khoán, cổ phiếu sang nhuợng (trades, positions) từ các ngân hàng của Đức, và Hoà Lan tôi lập ra một tập hợp của các dịch vụ (set of services) và một giao diện (not GUI, set of interfaces có thể hiểu như là 1 tập hợp của các hàm) dùng để sàng lọc các thông tin này theo đối tuợng của ngân hàng, đơn vị tiền tệ, và giá của cổ phiếu lúc mua và lúc thanh toán (settlement). Các chuơng trình hoặc libraries này không những đuợc dùng để phát triển chuơng trình thu thập dữ kiện mua bán cổ phiếu qua được giải quyết qua Clearing Firms của ngân hàng Đức hoặc Hoà Lan mà còn có thể đuợc tái xử dụng nếu như 1 ngày nào đó chúng tôi làm business với ngân hàng Pháp hoặc các ngân hàng ngoại quốc khác. Vậy việc hiểu rõ nền tảng của mình sẽ phục vụ cho cái gì rất quan trọng và cái thứ hai là sau khi có nền tảng nên tiếp tục refactoring (cải biến) để nền tảng của mình càng thêm hữu dụng cho nhiều ứng dụng phần mềm khác. Có 1 điều đáng chú ý nữa đó là MFC (hay Microsoft Foundation Class) không phải là 1 nền tảng tồi. Các bạn có lẽ sẽ ngạc nhiên bởi vì có rất nhiều phần mềm nền tảng của các cơ sở thành công trên đất Mỹ vẫn sử dụng MFC. Chúng ta không ngạc nhiên vì ngay cả trong Windows system directories của Windows 2000/XP chúng ta vẫn còn các file mfc40.dll hoặc các file mfc khác. Tôi đã từng dùng MFC trong việc phát triển GUI và thú thực it is not bad at all.
Hy vọng làm sáng tỏ 1 vài điều.
Thân.
1) Vào khoảng 3, 4 năm gần đây câu hỏi này đã đuợc truyền miệng đi lại rất nhiều trong dân gian IT ít nhất là ở Mỹ 
Có 1 số câu trả lời trên web (google is your friend!) cho câu hỏi này, phần nhiều là từ tập đoàn kỹ sư dùng Java, và các công cụ như Python, Perl, và cũng có 1 số ít từ MS Windows. Về phần tôi, như ví dụ tôi mô tả trong bài truớc (có thể nói không rõ), nhưng Framework là 1 nền tảng bao gồm tập hợp của giao diện và hàm (interface, and methods) có liên quan mật thiết với nhau để cho phép sự mở rộng của chuơng trình cho các yêu cầu mới sử dụng những tính năng có sẵn trong Framework. Để ý danh từ "mở rộng". Đó là ý chính Framework có thể gọi chuơng trình và xử lý (run) chuơng trình. Trong ví dụ truớc, Framework của tôi sẽ cho phép gọi 1 DLL dùng giải quyết các cổ phiếu giao dịch với thị truờng Châu Âu (EUREX), hoặc DLL dùng giải quyết thị truờng cổ phiếu giao dịch ở Mỹ. Sau đó, nó sẽ tiếp tục phân loại, sàng lọc nếu cổ phiếu thuộc loại Comodity, hay là Fixed-Income. Sau này nếu như có thị truờng Châu Á, chẳng hạn như VN, tôi chỉ cần viết thêm 1 DLL nữa để load vào Framework. Nên nhớ các DLL này đuợc coi như là services. Khi tôi nói tập hợp các dịch vụ đó có nghĩa là 1 tập hợp của các services (service có thể là Dll hoặc exe). Các services này (dll, exe) đuợc đặt trến 1 server hoặc nhiều server (load balancing). Đó là ý nghĩa của Framework. Library là gì? Library chỉ là tập hợp của 1 số lớp. Nếu bạn Vĩ "google" library có lẽ có hàng ngàn định nghĩa, khái niệm của library. Tuy nhiên theo tôi nó chỉ là 1 tập hợp của class, và interface. Library hoàn toàn vô dụng nếu nó không đuợc tích hợp vào một Framework nhất định hổ trợ cho một application (Đó cũng là lý do có từ Application Framework). Có lẽ 1 ví dụ rõ ràng hơn nữa đó là chúng ta có thể nhìn vào MS .Net Framework. Cái Framework này bao gồm 2 thành phần:
The Common Language Runtime và .Net Framework Library.
Hiểu được MS .Net Framework bạn Vĩ sẽ thấy 1 điều sau đây:
Library là cái mà chuơng trình gọi đến, ra lệnh để sử lý nhưng Library chưa bao giờ gọi chuơng trình.
2) Tôi không hiểu rõ mục đích của câu hỏi này cho lắm nhưng xin cố gắng trả lời. Tôi xin cho 1 biết 1 thông tin: tôi đã làm việc với .Net từ lúc MS cho ra Beta version. Tức là khoảng gần cuối năm 2001. Tuy nhiên cho đến nay ngoài việc sử dụng .Net tôi vẫn lập trình VS 6.0 tức là dùng ATL và MFC. Tuy không làm nhiều như cách đây 5, 6 năm nhưng tôi vẫn sử dụng chúng. Lý do đơn giản, các khách giàu sụ của chúng tôi vẫn có những nhu cầu cho các chuơng trình phát triển dùng các công cụ này. Nắm vững MFC, ATL và MS C++ nói chung giúp chúng tôi kiếm rất nhiều tiền. Như vậy đối với tôi là điều tốt nhất hạn khi các công ty tư vấn khác không có nguời làm đuợc MFC vì đối với họ rất khó học và phức tạp khi sử dụng. Thông thuờng những nguời này có 1 quan niệm chung khi họ không nắm vững thì cho công cụ đó là tồi hay lỗi thời. Nên nhớ trung bình 1 sv ra truờng bên Mỹ chỉ học 1 tuần là có thể lập trình trên C#. Học MFC may ra vài tháng nhiều khi còn lẫn lộn. Do đó học đuợc cái khó thì khi tới cái dễ mình sẽ có lợi thế hơn. Còn nói tiêu biểu hay không tiêu biểu tôi chưa có vị trí đó để phán đoán. Tôi nghĩ Bill Gates cũng chưa chắc nói đuợc. Tuy nhiên học đuợc cái nào tốt cái đó.
Thứ nhất câu hai tôi trả lời như vậy (có chừng mực) vì nếu nói sâu và thẳng tôi e có thể gây hiểu lầm cho 1 vài nguời (offending). Nói như vậy là chi tiết lắm rồi. Tôi không hiểu với Topic này Vĩ muốn chứng minh cái gì (What do try to prove?). Phải chăng Vĩ muốn tôi xác nhận quan điểm MFC là tồi hay nói nó là không tồi. Nên nhớ MFC, ATL, STL, .Net, Java, UML, hay bất cứ những ngôn ngữ khác đều là công cụ. Công cụ trong IT có "timeline" (có giới hạn của nó trong từng thời điểm). Đó là lý do tại sao chúng (kỹ thuật, khái niệm thay đổi liên tục). Cái bất khả thi ở thời điểm 5, 10 năm truớc thì bây giờ khả thi. Cái khả hợp thì tùy theo thời gian và hoàn cảnh. Nếu như bạn Cuờng có thể học và hiểu đuoc MFC tôi có thể nói bạn đó là 1 nguời khá thông minh vì nó không dễ tự học hay ngay khi tham gia 1 truờng lớp nào. MFC là 1 công cụ khá phổ biến ở 1 thời điểm truớc. Nhưng khi business phát triển, nhu cầu đòi hỏi cao hơn (Web, EDI) và khái niệm mới về kiến trúc cũng như sự cải biến của hardware thì các công cụ mới cũng ra đời để đáp ứng cho các nhu cầu mới (new projects). MS .Net trong 1 thời điểm trong tuơng lai cũng có thể bị coi là "tồi" khi có các công cụ khác thay thế nó. Tuy nhiên, như đã nói công cụ là Tool nó không khó học. Ý niệm đằng sau nó là cái quan trọng. Bên Mỹ khi họ thu nhận nhân viên thuờng không chỉ hỏi sử dụng công cụ nào mà là trí thông minh, sự ham học hỏi và khả năng học hỏi nhanh chóng. Chúng tôi đã từng thu nhận những nguời có background bên Java, Unix để làm việc trong môi truờng .Net, C# và Windows. Những nguời biết MFC thì khỏi phải qua 1 kỳ thi tuyển nào cả mà có thể vào thẳng làm việc bên C#. Tại sao? Vì chúng tôi biết 1 nguời có thể master C++, MFC thì việc học C# không thành vấn đề với họ. Trong rất nhiều truờng hợp họ lại là những nguời có "solid code" hơn những nguời chỉ biết mỗi C#. Theo đuổi ứng dụng công cụ là tốt nhưng công cụ như đã nói chỉ là Tool; chúng ta không nên lạc vào những ý tuởng như "Java vs C#", "MFC vs .Net" mà nên tập trung vào giải pháp "solution" cho nguời dùng. Chúng ta chỉ cung ứng IT Solution chúng ta không quyết định Business Decision. Nếu như chúng ta vào 1 xí nghiệp mà sản phẩm của họ dựa trên MFC/VC++ mà MFC là tồi hãy chuyển lên .Net vậy thì chúng ta phải chắc là cái business benefit (cái lợi ích) của sự chuyển đổi đó có lớn hơn cái rủi ro khi chuyển đổi phần mềm. Khi làm new project có thể họ sẽ dùng .Net hay Java. Nhưng nên nhớ lợi nhuận của công ty là từ sản phẩm đang sử dụng; còn rủi ro của công ty là từ new project, sản phẩm đang nghiên cứu. Đó là những ý tuởng cần học và theo đuổi. Còn công cụ thì quá dễ. Công cụ càng ngày càng dễ học ngay cả như MFC. Thử tuởng tuợng khi tôi ra truờng năm 1989 tôi viết IBM Assembler 370/390. Rất khó học và khó sử dụng. Vậy mà American Airlines, Sears Credits và các hãng credit cards vẫn còn đang sử dụng nó. Một nguời có thể dùng đuợc các công cụ này có thể làm trên 120,000 US 1 năm là chuyện bình thuờng. Tôi khuyên các bạn giống như mục đích của diễn đàn này (VietRose) nên tập trung vào khái niệm, và học hỏi các ý tuởng mới về thiết kế bởi vì thiết kế không có time-line. Các ý tuởng của thiết kế có thể áp dụng vào các giải pháp hầu như không lệ thuộc vào công cụ. Bạn muốn dùng MFC, hay .Net, hay JDK hay là cái gì đi nữa thì tùy bạn.
Còn câu hỏi kế tiếp của Vĩ tôi không trả lời. Bởi vì tôi nghĩ đây là 1 câu hỏi "INSULT". Tôi nhờ bạn Cuờng trả lời hộ. Bên Mỹ khi giao tiếp hoặc khi phỏng vấn những nguời có trình độ chúng tôi rất lịch sự trong việc hỏi câu hỏi để tránh sự sĩ nhục đến những nguời chúng tôi có ý muốn thâu nhận. Cũng giống như hỏi nguời học Đại Học vậy 1 + 1 bằng bao nhiêu. Đó là 1 cái kinh nghiệm nữa đấy nhé. Một lần nữa tôi vẫn chưa biết Vĩ muốn chứng minh điều gì ở đây.
) MFC nói riêng, VS 4.0, 5.0, 6.0 nói chung là 1 công cụ khá phổ biến hổ trợ cho khái niệm kiến trúc Distributed Computing. Nên nhớ COM, DCOM mà kết quả của chúng là các file như *.ocx, *.dll, *.exe đã đuợc sử dụng như 1 giải pháp thích đáng cách đây 10 năm ít nhất là trong bối cảnh khi chúng là các sự chọn lựa khả thi cho phát triển dự án. MFC tuy ngày nay không phải là sự chọn lựa thích hợp cho các NEW PROJECT nhưng hiểu khái niệm của nó và nắm vững nó giúp rất nhiều không những trong công việc mà còn cho việc học của .Net Framework. Chúng ta thấy phần COM Interoperable của .Net rất quan trọng. Hiểu đuợc COM dll, COM ocx, hay COM exe (DCOM) chúng ta hiểu đuợc 1 trong những ứng dụng quan trọng trong Framework và kiến trúc. Lấy ví dụ trong VS2003, khi các bạn muốn tích hợp 1 chuơng trình .Net (C#, VB.Net) trong MS Excel, các bạn có thể phải tạo 1 COM dll trong .Net. Nếu có sự lựa chọn thì có lẽ dùng MFC hay ATL có lẽ dễ dàng hơn. Còn nhiều truờng hợp khác nữa tuy nhiên 1 cái hiển nhiên hơn nữa (no brainer) đó là khi chúng ta làm việc chúng ta thuờng gặp truờng hợp phải tích hợp giữa nhiều chuơng trình. Chiến luợc của MS cũng có nói (ít nhất cho những ai có MCAD/MCSD) khách hàng của chúng ta có thể có 1 lô MFC OCX, MFC EXE hay DLL. Những chuơng trình này nếu phải viết lại rất tốn kém và có nhiều rủi ro sai lầm, từ .Net thông thuờng cho new project họ muốn chúng ta phải tích hợp vào dự án mới. Hiểu đuợc Framework của MFC và cách thức làm việc của nó là 1 lợi thế quý báu để làm việc.
2) Chúng ta nên tránh tuyên truyền tư tuờng 1 chiều chẳng hạn như VB V.S C++, VB.Net V.S. C#, MFC V.S. JDK, UML V.S. XP hay bất cứ cái gì khác. Chúng ta nên học hết để biết cái ưu điểm và nhuợc điểm của từng cái. Không nên nghe truyền miệng từ những nguời chưa học hoặc cảm thấy khó học và khó làm nên cho rằng 1 công cụ "nổi tiếng" tồi hay là hay mà không có 1 bằng chứng cụ thể. Nên nhớ biết cả 2 thứ hay và tồi giúp chúng ta hữu hiệu hơn trong việc phục vụ khách hàng và áp dụng đúng công cụ cho từng truờng hợp. Tôi lấy ví dụ tôi là nguời practice XP một thời gian, tôi đã nghe và thấy cái hay và dở của XP (tôi đã từng làm việc và thọ giáo với Robert Martin khoảng 1 tháng www.objectmentor.com cho 1 dự án quan trọng). Tuy nhiên tùy nguời và tùy truờng hợp tôi sẽ promote XP hay là không nên promote XP nhưng chưa bao giờ nói nó là 1 phương pháp tồi. Cũng như nói ah đừng học XP mà học UML hay Feature Driven Development, hay Method 1, ...,ETC.
3) Framework, Library, Architecture mấy danh từ sáo rỗng (buzzwords) này muốn diễn giải phải làm nhiều Architecture, lập nhiều Framework, và tạo nhiều Library thì sẽ hiểu. Practice, Practice and Practice. Đa số những nguời quay cuồng trong các danh từ này là những nguời mới học, và thuờng ít cơ hội hoặc không muốn thực tập khái niệm này trong công việc. Đọc sách, hoặc lên internet là điều tốt tuy nhiên phải cẩn thận với thông tin mà chúng ta thu thập. Quan điểm trên .Net hay ngay cả từ sách và tác giả chưa hẳn là đúng và chính xác cho mọi truờng hợp. Lấy ví dụ NUnit (since you mention it), khi Robert Martin tuyên truyền TDD vào công ty của tôi và ý tuởng TDD vào các GUI đã trở thành 1 thất bại nặng nề. Ngay cả việc Pair Programming và bỏ qua documentation (hay it documentation) đã gây thiệt hại đến project bởi vì nó áp dụng không đúng chỗ và đúng lúc. Ngay cả Ken Beck khi dùng XP cho project C3 chúng ta cũng không biết kết quả của nó vì project này bị hủy bỏ giữa chừng (cancellation). Do đó phải cẩn thân trong lời khuyên nhất hạn khi chúng ta chưa bao giờ sử dụng nó.
Thứ nhất tôi chưa từng tức giận hay mất bình tĩnh. Từ lúc tôi tham gia nên giờ Vĩ là đối tác duy nhất của tôi trong việc tham khảo, sao lại tức giận nguời muốn nói chuyện với mình khi diễn đàn gần 400 nguời không có ai tham gia. Tuy nhiên sống ở Mỹ đã lâu và nhất hạn làm trong nghành tư vấn tôi đã luợm lặt đuợc rất nhiều kinh nghiệm trong giao tiếp ("engagement"). Do đó khi viết khi nói một cách có thể hiểu lầm là "offending" cũng giống như khi đưa ra thông tin cho một vấn đề nguời đối diện có thể lầm tuởng mình coi thuờng họ. Tôi muốn không những chỉ thông tin về kiến thức kỹ thuật nhưng cả kinh nghiệm về giao tiếp với khách hàng nuớc ngoài (đa số là nhũng nguời có high credentials và lịch lãm trong nghành). Do đó đừng hiểu lầm là tôi giận. Tôi nghĩ chúng ta có thể còn có nhiều "Culture Shock" trong tuơng lai nhưng điểm chính yếu nếu chúng ta đặt vấn đế "học hỏi" làm đầu thì không có vấn đề gì cả.
1) Muốn quyết định giữa 2 cái cái nào thích ứng cho công việc hay giảng dạy thì truớc hết phải hiểu biết tuờng tận cả 2 cái; mà hiểu biết tuờng tận trong IT không cách nào khác là phải học và làm việc với nó. Như tôi đã nói đừng bao giờ nghe "tin đồn" hoặc nghe tuyên truyền từ mấy tên Evangelist (1 trong những bạn học cùng truờng của tôi là Microsoft Evangelist).
2) Phần 2 đi hơi xa vấn đề nhưng không viết ra không chịu đuợc:
Học, bồi duỡng kiến thức từ xưa nay là cái nhất thiết cho mọi tầng lớp lao động trí óc nhất hạn là những nguời làm IT. Nếu Vĩ lái câu hỏi của mình sang môi truờng học đuờng thì chúng ta có lẽ đi quá xa câu hỏi của Cuờng. Đề tài là "thắc mắc trong thiết kế" Vĩ muốn hỏi truờng mà anh bạn Vĩ dạy muốn dạy C++ hay C# hay Java. Tôi không có ý kiến về về quyết định của 1 truờng nào. Theo tôi tất cả chúng đều đáng đuợc dạy trong môi truờng học đuờng. Tôi có 1 số học trò online (in VN) có nhờ tôi giảng về mấy cái project họ làm bên Visual C# và VS C++, MFC. Có 1 số thì học Java. Tôi nêu ra 1 điểm ở đây vì các truờng đại học ở VN nên đặt nặng vào kinh nghiệm thực tế và đào tạo sinh viên có khả năng lý luận, sáng tạo thay vì bài bản hoặc chạy đua theo công cụ. Một lần nữa "chạy đua theo công cụ" thay vì "ứng dụng công cụ". Những sinh viên của các truờng đại học kỹ thuật lớn bên này (U OF I Champaign), (ITT - Illinois Institute of Technology), (MIT) mà tôi tham gia phỏng vấn họ chỉ học C, C++, và Java trong môi truờng Unix. That's it. Đơn giản. Tuy nhiên nguời viết ra cái web browser mà chúng ta dùng đến bây giờ xuất thân từ U OF I lúc đó chỉ học C, C++, Unix trong truờng thôi nhé. Cả những nguời lập ra google. Còn những nguời mới ra truờng chúng tôi đem vào làm việc có nguời chỉ học Programming in C trong Unix. Tuy nhiên tất cả những nguời này đều có 1 ưu điểm đó là óc sáng tạo, ham học hỏi và họ chứng tỏ khả năng thu thập thông tin chi tiết. Điều đó đã chứng minh khi tôi (as their mentor) chỉ cho họ không hơn 1 tuần thì tất cả đều có thể bắt tay vào công việc. Chúng tôi dùng rất nhiều công cụ: Linux, Unix, Windows (2000/2003/XP), MS SQLServer, MySQL, Poet, XML Spy (Altova), ComponentOne, C++, C#, VB.Net, MFC, ATL, COM, TIBCO, ELVIN, MS Application Blocks, NUnit, Docxygen, UML, XP, DataJunction, ASP.Net, và nhiều API đem lại từ các đối tác chúng tôi làm việc như Bloomberg, Reuters, CME, Eurex vân và vân. Làm sao tìm đuợc nguời có thể biết hết những cái này. Chỉ có thể tìm đuợc nguời có khái niệm căn bản, hoặc kinh nghiệm với khả năng học hỏi nhanh chóng để có thể làm việc. Do đó tôi nhấn mạnh vấn đề "Khả năng học hỏi". Nên tập trung vào việc đào tạo nhân sự với đầu óc sáng tạo, tự lập thay vì bài bản cứng nhắc. Tôi có 1 học trò (online) học ở 1 truờng DH ở VN. Khi tôi hỏi về ADO.Net nguời này trả lời đúng hết nào là bao gồm 2 thành phần DataSet và Data Provider vân vân và vân vân. Tuy nhiên đến lúc viết chuơng trình thì sai hết và không ứng dụng đuợc. Không phải chỉ có nguời này mà 1 vài nguời khác tôi biết cũng có vấn đề tuơng tự. Tôi thấy đó là vần đề với học khái niệm 1 cách bài bản.
3) Một điều nữa tôi không mấy "comfortable" với cái danh từ "Định Nghĩa". Tôi nghĩ nên dùng "khái niệm" cho Framework, Architecture, hoặc Library bởi vì nó có thể khác đi trong nhiều bối cảnh (interchangeable). Định nghĩa khi nào nó có ý nghĩa duy nhất trong mọi truờng hợp hoặc bối cảnh.
4) Mấy cái khái niệm Vĩ "list" ra ở đây lấy từ đâu ra vậy. Sách nào hay là trên Web Google? Tôi khuyên Vĩ nếu có thì giờ hãy thử vào IDE của VS 6.0 tạo 1 COM bằng MFC (.ocx) sau đó tạo 1 COM bằng ATL (.dll). Sau đó đọc 2 file .odl và .idl của 2 chuơng trình của mình. Còn MS .Net Framework Vĩ lên forum của MS viết 1 lá thư cho MS .Net Team và hỏi họ có phải MS .Net thực sự là 1 framework hay không? Nếu Vĩ có nhã hứng với các buzzwords hay jargons này tôi đề nghị cho thêm 1 chữ nữa "Environment".
No comments:
Post a Comment