Xác định xem ngôn ngữ / khung / công nghệ có phải là 'Bằng chứng trong tương lai' không


10

Tôi là một nhà phát triển PHP và gần đây tôi đã bắt đầu làm việc với CodeIgniter. Dường như bất cứ khi nào tôi tìm kiếm một cái gì đó liên quan đến CodeIgniter, các bài đăng trên blog và những thứ không thường là từ '09 hoặc '10, vì vậy tôi có nghĩ rằng, CodeIgniter vẫn còn liên quan và nó sẽ có trong tương lai không? Có một khuôn khổ khác đang diễn ra không?

Điều tương tự cũng xảy ra với các ngôn ngữ và khung khác. Tại thời điểm nào bạn từ bỏ việc học các ngôn ngữ hoặc khung nhất định? Có cách nào dễ dàng để tìm thấy những thứ đang nổi lên và đáng để chọn không?


15
Hãy để tôi tham khảo quả cầu pha lê của tôi ...
Thất vọngWithFormsDesigner

1
@MactorKyle Một tìm kiếm nhanh đã mang lại cho tôi điều này ... tiobe.com/index.php/content/apersinfo/tpci/index.html không chắc điều này có hữu ích không nhưng nó thú vị không kém.
Ominus

3
@MactorKyle Tôi nghĩ vấn đề tiềm ẩn (và tôi phải chịu đựng điều này) là "Điều tôi đã chọn để học có xứng đáng với thời gian / công sức tôi sắp bỏ ra không?". Với rất nhiều lựa chọn, có thể là quá sức để tìm ra cách tốt nhất để đầu tư thời gian / năng lượng cho phần thưởng lớn nhất trong dòng công việc đã chọn của chúng tôi.
Ominus

1
Đó là những gì tôi đã nghĩ trong đầu. Quá tệ, họ không có khung được liệt kê!
Kyle

3
COBOL là một trong những công nghệ chứng minh tương lai nhất hiện có. Các cơ sở được cài đặt COBOL rất khó có thể biến mất. Bạn có thể muốn nghĩ về điều đó có nghĩa là gì.
dùng16764

Câu trả lời:


17

Đây không phải là một khoa học chính xác, vì vậy đừng hy vọng có thể dự đoán xu hướng trong tương lai trong bối cảnh công nghệ hơn 5 năm nữa với bất kỳ sự chắc chắn nào.

Nhưng tôi sẽ tìm tất cả những điều sau đây:

  • Cơ sở được cài đặt - một cơ sở được cài đặt lớn hơn có nghĩa là nhiều công ty sẽ tham gia đầu tư vào công nghệ và bảo trì, điều đó có nghĩa là các nhà phát triển sẽ cần thiết để làm việc với công nghệ. Chu kỳ tích cực xảy ra. Ví dụ Java, như COBOL trước nó, sẽ không biến mất trong một thời gian rất dài.
  • Hỗ trợ công nghiệp rộng rãi - có nhiều người chơi ngành công nghiệp tên tuổi lớn ủng hộ công nghệ? Chỉ có một người ủng hộ cam kết là một dấu hiệu cảnh báo - nó có thể bị hủy hoặc bị loại bỏ bất cứ lúc nào với một thay đổi chiến lược duy nhất.
  • Nguồn mở - các sản phẩm nguồn mở chính đã được chứng minh là cược dài hạn cực kỳ tốt (ví dụ, hãy xem Linux, Apache, Red Hat, JBoss, Eclipse ....). Mặt khác, các sản phẩm độc quyền có phần bất chợt của một nhà cung cấp duy nhất mà bạn có nguy cơ ngừng / tăng giá / cố gắng buộc phải chuyển sang "điều lớn tiếp theo" của họ.
  • Chất lượng - sản phẩm chất lượng cao đơn giản sẽ sống lâu hơn vì mọi người sẽ muốn sử dụng chúng hơn là chuyển sang thứ khác. Ngược lại, các sản phẩm chất lượng thấp sẽ bị bỏ rơi ngay khi có thứ gì đó tốt hơn xuất hiện.
  • Đổi mới - là công nghệ hướng tới sự tiên tiến của đổi mới? Nếu vậy, nó có khả năng nhận được sự chấp nhận và hỗ trợ giữa các công ty và người dùng sáng tạo hơn. Điều này cuối cùng sẽ bắt đầu trở thành xu hướng (ví dụ, tôi muốn nói các ngôn ngữ mới như Scala và Clojure nằm trong danh mục này)
  • Cộng đồng - đó có một cộng đồng tích cực, cởi mở, thực dụng, tận tâm, hữu ích xung quanh công nghệ không? Đây là những người cuối cùng sẽ đảm bảo tương lai của nó .....

3
Vậy làm thế nào để bạn giải thích VB6? ;-)
sdg

4
Ma thuật đen .....?
mikera

1
-1, vì hầu hết các điểm không được chứng minh. Ví dụ, bạn đang nói về nguồn mở là cược dài hạn. Vậy MacOS, Windows, Visual Studio và hàng ngàn sản phẩm phổ biến nhất không phải là cược dài hạn? Đổi mới: bạn muốn thể hiện điều gì ở đây? Tất cả các sản phẩm chúng tôi sử dụng là sáng tạo trước khi trở thành chủ đạo. Chất lượng: xác định nó. Hầu hết các khung và thư viện phổ biến PHP được viết bằng mã spaghetti khủng khiếp, nhưng vẫn phổ biến.
Arseni Mourzenko

1
@MainMa: Vì nguồn mở đang ngày càng phổ biến và Windows đang trở nên phổ biến, có vẻ như có bằng chứng. "Hàng ngàn sản phẩm phổ biến nhất không phải là cược dài hạn" Đúng. Rất nhiều và rất nhiều sản phẩm sẽ không tồn tại trong vòng năm năm. "mã spaghetti khủng khiếp, nhưng vẫn còn phổ biến." Bạn đã đọc câu trả lời? "[Cho đến khi] một cái gì đó tốt hơn đi cùng". Không có gì tốt hơn cho PHP? Vì thế. Di sản vẫn còn tại chỗ.
S.Lott

3
Phần mềm mã nguồn mở @MainMa không đảm bảo với bạn rằng dự án sẽ không bị từ bỏ. Nhưng nó đảm bảo với bạn rằng bạn sẽ có khả năng duy trì nó nếu đội ban đầu không. Nếu sản phẩm không được phát triển bởi một công cụ khổng lồ và thành công, bạn luôn có nguy cơ bị mắc kẹt với một khuôn khổ lỗi thời / không thể mở rộng khi nó là nguồn đóng.
Simon Bergot

14

Không có cách nào để biết nếu một cái gì đó sẽ là bằng chứng trong tương lai, tôi muốn tập trung vào công nghệ giúp tôi giải quyết vấn đề tôi có ngày hôm nay. Bạn sẽ từ bỏ việc học một ngôn ngữ hoặc khuôn khổ nhất định khi nó không còn hoạt động để giải quyết vấn đề của bạn.

Tham gia vào cộng đồng đại diện cho những gì bạn đang làm và bạn có thể hiểu rõ về những gì sắp tới năm hoặc hai kể từ bây giờ


7
Vì tương lai rất khó để thấy trước, thật khó để hiểu "bằng chứng trong tương lai" có thể có nghĩa gì. "'Tôi nghĩ rằng có một thị trường thế giới cho khoảng năm máy tính' MạnhRemark do Thomas J. Watson (Chủ tịch Hội đồng quản trị của các máy kinh doanh quốc tế), 1943".
S.Lott

7

Không có cách nào để xác định dứt khoát liệu một cái gì đó là bằng chứng trong tương lai. Cách gần nhất mà bạn có thể đến là xác định mức độ hoạt động xung quanh một ngôn ngữ hoặc khung cụ thể - nếu có nhiều hoạt động của nhà phát triển, thì đó thường là một dấu hiệu tốt cho thấy ngôn ngữ / khung đang có xu hướng phổ biến và sẽ tồn tại trong một thời gian . Nghịch đảo chỉ ra rằng có ít hứng thú hơn và sự hỗ trợ (thông qua các diễn đàn dành cho nhà phát triển) có thể khó đến hơn.

Miễn là ngôn ngữ / khung lựa chọn của bạn giải quyết được vấn đề mà bạn đang cố gắng giải quyết, bạn không cần phải lo lắng về việc chứng minh trong tương lai, trừ khi bạn rõ ràng đang làm việc với công nghệ sắp chết. Công nghệ liên tục thay đổi - một điều bạn có thể làm là theo dõi các xu hướng của ngành. Học các ngôn ngữ / khung lập trình mới, như đã lưu ý trong chủ đề này , có thể giúp bạn bắt kịp xu hướng và cho bạn cơ hội để liên tục đánh giá các công cụ mới.


5

"Futureproof-iness" cũng nhiều về sức mạnh ý chí và sự bướng bỉnh cũng như về những mối quan tâm thực dụng hơn.

Một ví dụ cực đoan là đây . Bộ lọc Sparkle VẪN CHẠY máy tính IBM 402 từ cuối thập niên 40 làm hệ thống kế toán của họ. Đây là một máy được lập trình bằng cách sử dụng bảng cắm điện thay vì "tập tin".

Cá nhân tôi đã có kinh nghiệm với một công ty vẫn duy trì các máy dựa trên MS-DOS bên trong các thiết bị chuyên dụng được thiết kế để hoạt động trong nhiều thập kỷ. Tôi thậm chí đã loại bỏ một PDP hoạt động vào cuối năm 1997.

Tôi muốn nói rằng nếu công ty của bạn nhận được một chuyến viếng thăm từ bảo tàng lịch sử máy tính, như Sparkle Filter đã làm, đó sẽ là một dấu hiệu cho thấy bạn (hoặc tổ tiên của bạn) đã "chứng minh thành công" hệ thống!


Từ này phải là 'được chứng minh trong tương lai', có lẽ :)
9000

5

Tôi có thể trả lời liệu một công nghệ cụ thể có phải là bằng chứng trong tương lai hay không - câu trả lời gần như chắc chắn là không, vì bạn đã không đặt thời gian cho việc này.

Để làm cho câu hỏi này có thể trả lời được, bạn sẽ cần thêm một số chi tiết cho các yêu cầu. Ví dụ:

  • Chúng ta đang nói về khoảng thời gian nào - 1 năm, 3 năm, hơn 5 năm?
  • Chi phí để chọn một cái gì đó không có trong khoảng 5 năm là gì?
  • Những lợi ích nào bạn sẽ nhận được từ việc lựa chọn một lựa chọn ít "an toàn" hơn và làm những lợi ích đó vượt xa rủi ro?

Sự lựa chọn ngôn ngữ / khung / công nghệ thực sự là một phần của quản lý rủi ro trong dự án. Như với tất cả các rủi ro, bạn sẽ cần xem xét một số yếu tố (tôi đang cố gắng duy trì điều này) và sau đó thực hiện các bước để giảm nó xuống mức phù hợp với tình huống trong tay.

Giống như với hầu hết mọi thứ trong cuộc sống, hoạt động liên quan đến rủi ro thấp nhất có thể không thực sự là lựa chọn tốt nhất.

Nói tóm lại, bạn đã chuẩn bị bao nhiêu sự không chắc chắn để sống cùng với những lợi ích bạn sẽ gặt hái được từ việc sử dụng trong suốt thời gian dự kiến ​​của dự án.

Bạn muốn nhìn vào tương lai càng lâu, thì càng ít chắc chắn. Ví dụ, nếu bạn hài lòng với việc chỉ lo lắng về 2 năm tiếp theo, sự lựa chọn của bạn sẽ dễ dàng hơn rất nhiều (và để lại nhiều lựa chọn hơn cho bạn) hơn là chọn một thứ gì đó cần có trong 10 năm tới.


3

Có rất nhiều yếu tố để tôi nói rằng nó không thể. Trong số những điều có thể đi sai là: -

  • Thời trang. Mọi người mất hứng thú và chuyển sự chú ý sang một nền tảng mới đẹp hơn. Perl đã gần như độc quyền các ứng dụng web vào khoảng năm 2000. Nó hầu như không được đề cập đến bây giờ.
  • Nhà cung cấp thị phần. khoảng năm 2000 bạn sẽ có mặc dù C ++ / Sun Solaris vẫn tốt cho đến năm 3000.
  • Shenanigans doanh nghiệp. Một vài năm trước tôi đã chọn Java làm nền tảng chứng minh trong tương lai. Với ORACLE bản quyền API, v.v. Tôi nghĩ rằng sẽ thấy một sự chuyển hướng sang một số khung ngôn ngữ khác, tôi chỉ ước tôi biết cái nào.
  • Cuối đường. Tôi đang nghĩ về những thứ như Visual Basic mà sau một lịch sử lâu dài và danh dự không thể kéo dài thêm nữa để phù hợp với suy nghĩ mới nhất trong phát triển phần mềm.
  • Người thua cuộc thắng cuộc. PHP (mà tôi thích) sẽ không và chưa bao giờ chiến thắng bất kỳ cuộc thi sắc đẹp nào giữa các nhà phát triển, nhưng nó đã nổi lên như một vị vua không thể tranh cãi của web. Khi tôi lần đầu tiên viết một số php vào năm 2004, tôi sẽ không bao giờ ủng hộ nó như là ngôn ngữ chung của sự phát triển web.
  • Những con vịt xấu xí. Javascript mà không thay đổi một đoạn cú pháp hoặc thêm một API, đột nhiên xuất phát từ ngôn ngữ kịch bản lệnh hokey mà biểu ngữ gây phiền nhiễu hoạt hình thêm vào phần trung tâm của WEB 2.0.

Cuối cùng, điều đó không thành vấn đề. CodeIgniter làm việc cho bạn và cung cấp những gì bạn muốn. Không có gì bạn làm sẽ ngừng hoạt động vì các bài đăng trên blog đã cũ hoặc tốc độ phát hành đã chậm lại. Vì vậy, lời khuyên của tôi sẽ là sử dụng những gì hoạt động ngay bây giờ, và, đối phó với tương lai khi nó đến.


2

Một khung công tác PHP, Symfony, đã giải thích điều này một cách hoàn hảo tại trang web của họ .

10 tiêu chí để chọn đúng khung

Bạn đang tiến bộ và đó là một điều tốt! Bạn đã biết rằng bạn sẽ sử dụng một khung để phát triển trang web hoặc ứng dụng của bạn. Nhưng cái nào? Dưới đây là danh sách kiểm tra mà bạn có thể sử dụng để tránh mắc lỗi:

1. Phổ biến và quy mô cộng đồng

Khung càng nổi tiếng và được công nhận thì sẽ càng có nhiều người sống, phát triển và hoàn thiện: các ý tưởng mới, số lượng và chất lượng của các trình cắm, v.v.

2. Triết học

Đây là bản chất của khuôn khổ: nó là một tiêu chí cơ bản để đảm bảo rằng nó sẽ đáp ứng nhu cầu của bạn. Một công cụ được phát triển bởi các chuyên gia cho nhu cầu của riêng họ rõ ràng sẽ đáp ứng nhu cầu của các chuyên gia khác.

3. Bền vững

Trước khi chọn một khung, hãy chắc chắn rằng nó sẽ có thể theo kịp bạn trong suốt thời gian. Điều này giúp đơn giản hóa cả việc bảo trì và nâng cấp các ứng dụng của bạn.

4. Hỗ trợ

Một tiêu chí khác không nên bỏ qua là dễ dàng tìm câu trả lời cho câu hỏi của bạn và nhận trợ giúp. Xác định hỗ trợ có sẵn: từ nhà xuất bản. Từ một cộng đồng (danh sách gửi thư, IRC, v.v.)? Từ các công ty dịch vụ (phát triển, hỗ trợ, đào tạo)?

5. Kỹ thuật

Để tránh bị mắc kẹt trong một mê cung, tốt nhất là luôn chọn giải pháp tương tác; một trong đó tôn trọng các thực tiễn tốt nhất về phát triển (mẫu thiết kế)

6. An toàn

Bất kỳ ứng dụng có khả năng dễ bị tổn thương. Để giảm thiểu rủi ro, tốt hơn hết là chọn một khung có khả năng đảm bảo các chức năng bảo mật (ví dụ như quản lý XSS).

7. Tài liệu

Đó là một điều cần thiết tuyệt đối để đánh giá bản chất, khối lượng và chất lượng của tài liệu hiện có về một khung: một công cụ tài liệu tốt vừa dễ sử dụng hơn vừa có thể nâng cấp hơn.

8.License

Giấy phép rất quan trọng đơn giản vì chúng có thể có tác động đáng kể đến các ứng dụng của bạn. Ví dụ, một ứng dụng được phát triển sử dụng khung được cấp phép GPL sẽ nhất thiết phải tuân theo GPL. Mặt khác, đây không phải là trường hợp đối với khuôn khổ được MIT cấp phép.

9. Khả năng sẵn có của các nguồn lực trên thị trường

Có lẽ bạn sẽ muốn có một đội ngũ kỹ thuật bao quanh bạn trong giai đoạn phát triển hoặc về lâu dài, cho cả bảo trì và nâng cấp. Nói cách khác, đảm bảo rằng các kỹ năng cần thiết cho công cụ mà bạn đang sử dụng có sẵn trên thị trường mở.

10. Hãy thử nó ra!

Đó là chìa khóa! Đừng hài lòng với việc đọc các nhận xét, bình luận và tin đồn, tốt hay xấu, trên Internet. Bằng cách thử nghiệm nó, bạn sẽ có thể tự quyết định và đảm bảo rằng bạn hoàn toàn thoải mái với công cụ này.


1

Chìa khóa là sự kiên nhẫn. Kiên nhẫn, kiên nhẫn, kiên nhẫn. Không có cách nào chắc chắn để dự đoán tương lai. . .

Vì vậy, khi NextNewThing (tm) xuất hiện, hãy thoải mái nhảy vào bandwagon ... chỉ không cho bất cứ điều gì quan trọng trong vài năm đầu tiên.


0

Mikeras trả lời là khá tốt đẹp. Tôi sẽ thêm rằng bằng chứng trong tương lai là một loại quản lý rủi ro hoặc bảo mật thực sự. Nó thường yêu cầu bạn từ bỏ một số tiện ích nhất định và lợi ích chi phí / năng suất ngay bây giờ để tránh các vấn đề sau này. Tôi đã làm công nghệ gần như trong tương lai khá lâu rồi. Có một số mẫu nhất định có thể giúp đỡ. Đây là một vài.

  1. Dữ liệu nên được lưu trữ ở định dạng mở, dễ dàng trích xuất hoặc chuyển đổi sau này. Các định dạng tệp lẻ là một kỹ thuật khóa & bẫy lớn nói chung. Ngoài ra, thích các cách tiếp cận đơn giản hơn như CSV, ASN.1 hoặc JSON hơn các crap phức tạp như XML hoặc định dạng Word 97;). Ý tưởng là nó đủ đơn giản để tự mình ném một trình phân tích cú pháp và trình phân tích cú pháp định dạng cấp thấp có thể sử dụng lại trên các ứng dụng của bạn.

  2. Các ứng dụng lý tưởng nên có các giao diện trung lập với nhà cung cấp và công nghệ được tích hợp vào chúng, cộng với một mô tả chính xác về những gì chúng làm. Bạn nên thiết kế những thứ mà bạn có thể thay đổi hoặc vứt bỏ việc thực hiện mà không phá vỡ bất cứ điều gì. Ngoài ra, việc chuyển sang một nền tảng mới rất dễ dàng nếu phương pháp gọi thủ tục hoặc xử lý dữ liệu của bạn hoạt động trên các nền tảng. Vì vậy, các giao diện là hầu hết điều quan trọng để có được chính xác. Phương pháp thực hiện giao diện càng đơn giản, nhanh hơn và mở càng tốt.

  3. Ngăn xếp phải là nguồn mở hoàn toàn và miễn phí để sửa đổi. Giấy phép GPL, LGPL, BSD, MIT, v.v đều ổn ở góc độ này. Ý tưởng là, nếu cộng đồng bắt đầu tàn lụi, thì ngăn xếp có thể cần phải được chuyển sang [phần cứng / hệ điều hành / giao thức / vv] mới. Và bạn cần mã để làm điều đó.

  4. Thiết kế của ngăn xếp phải cực kỳ mô-đun với mỗi người có thể hiểu được. Điều này giúp một nhóm mới dễ dàng lấy nó hơn và duy trì nó. Thậm chí có các mức thấp nhất của thời gian chạy, các thư viện và trình biên dịch được trang bị độc đáo có thể có một khoản tiền rất lớn nếu nó cần được chuyển. Thông thường, chỉ một phần có thể được chuyển và tất cả mã cũ của bạn sẽ hoạt động.

  5. Ứng dụng của bạn nên được thực hiện theo cách mô đun hóa các yếu tố chi tiết nền tảng để giảm thiểu việc làm lại trong khu vực đó. Nó giúp cấu trúc các chức năng thành các khối đầu vào / xử lý / đầu ra nếu có thể. Điều này có thể hỗ trợ phân tích những gì sẽ bị ảnh hưởng bởi một cổng (và phân tích tính chính xác nói chung theo phương pháp phòng sạch). Nền tảng tiếp cận rủi ro thấp nhất là sử dụng các tính năng mẫu số chung thấp nhất được hỗ trợ phổ biến với một giao diện cho phép bạn sử dụng chúng, tiếp tục giảm việc chuyển. (Tôi đã nói rằng bạn sẽ mất một cái gì đó ...)

  6. Gõ động, suy luận kiểu hoặc cách tiếp cận gõ linh hoạt khác giúp. Một cổng đến một nền tảng mới có thể thay đổi định nghĩa của các loại cơ sở. Ngôn ngữ gõ mạnh trong nội bộ có nghĩa là bạn bớt lo lắng với công cụ này.

  7. Giữ mô hình tương tranh đơn giản. Theo hướng sự kiện, thông điệp truyền qua các giao diện rõ ràng có thể di chuyển đến ... về cơ bản mọi thứ. Ngoài ra còn có coroutines. Bạn chỉ muốn tránh các tuyến đường dễ xảy ra cả lỗi và sự cố di động.

  8. Nhìn vào thời gian chạy di động của Mozilla và Apache. Họ đưa ra nhiều vấn đề cụ thể về nền tảng với các lựa chọn triển khai và giao diện nhất định. Họ có thể gợi ý cho bạn về những điều cần lo lắng, cùng với việc cung cấp các giải pháp tốt cho nhiều vấn đề.

Ví dụ hoàn hảo: Tcl. Tôi biết, rất nhiều người ghét nó và tôi hiếm khi sử dụng nó cho mình. Tuy nhiên, Tcl là một ngôn ngữ cực kỳ dễ hiểu, thực hiện (12 quy tắc chính) và mã. Nó nhỏ, đủ nhanh, tích hợp với các máy chủ Web, nhúng trong các ứng dụng gốc, đã được chuyển sang hàng tấn công cụ, có các tính năng an toàn nhất định và đã được cập nhật thường xuyên từ những năm 80 khi nó được thực hiện. Bạn hoặc tôi có thể thực hiện toàn bộ thời gian chạy TCL trong thời gian ngắn cho ngôn ngữ cốt lõi. Nếu chúng ta phải chuyển thư viện chuẩn, nó sẽ dễ dàng hơn việc chuyển .NET hoặc Java. Và có khá nhiều mã hữu ích được viết cho nó. Và nó đã được sử dụng trong công nghệ web từ thời "đại lý di động" mà cơn sốt Java cũng nhắm đến. Chẳng hạn, khung web OpenACS quay trở lại năm 1998 với máy chủ cũ hơn thế.

Các ví dụ khác: BASIC, COBOL và LISP (Scheme hoặc CL). Các ngôn ngữ này đều quay trở lại khoảng 50 hoặc 60 giây. Chúng đủ đơn giản để dễ hiểu, thực hiện và dịch cơ học. Tuy nhiên, bạn có thể xây dựng công cụ hữu ích với họ. COBOL vẫn hỗ trợ hầu hết quá trình xử lý giao dịch của thế giới, đã được cập nhật một vài lần và thậm chí chạy trên .NET. Các ứng dụng QBasic / QuickBASIC cũ vẫn chạy cho đến ngày nay với các công cụ mở / miễn phí trên các nền tảng hiện đại, cùng với khả năng chuyển sang các công cụ tốt hơn như GAMBAS hoặc RealBASIC. Các lập trình viên LISP tự nhiên làm cho hệ thống của họ trở thành mô-đun và chức năng, dễ dàng chuyển. Đã có một loạt các triển khai ổn định cho nó trong nhiều thập kỷ, mở và thương mại.

Vì vậy, giao diện, tính mở, đơn giản, mô đun và kiến ​​trúc / thiết kế / mã hóa trung lập nền tảng. THESE sẽ giúp bạn có được bằng chứng trong tương lai mà bạn yêu cầu. Phần lớn thời gian, dù thế nào đi chăng nữa.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.