Hướng dẫn dành cho nhà phát triển Java trong tương lai. Doanh nghiệp - phần 1

“Đừng quá tự hào về những thành tựu công nghệ mà bạn đã xây dựng được. Khả năng phá hủy một hành tinh chẳng là gì so với sức mạnh của Thần lực." - Darth Vader trên Ngôi sao chết.

giới thiệu

Có lẽ, hai phần tiếp theo của loạt bài được nhiều người mong đợi nhất và có lý do chính đáng. Có gì ở đó, ngoài chân trời, ngoài Java thuần túy? Các nhà phát triển Java hít thở điều gì trong mỗi dự án? Hãy coi đây là một hướng dẫn tự học thực sự, đầy đủ dành cho bất kỳ kỹ sư back-end trung bình nào có ngôn ngữ lập trình chính là Java. Tôi dự định đề cập đến mức trung bình của bệnh viện nhiều nhất có thể và mô tả không chỉ các khuôn khổ phổ biến nhất mà còn cả các giải pháp được coi là phù hợp vào thời điểm hiện tại. Đương nhiên, có rất nhiều công cụ và việc hiểu được công cụ nào quan trọng nhất và tốt nhất là con đường dẫn đến hư không. Mỗi người trong số các bạn đã xem phần “Việc làm” trên DOU và tìm thấy một loạt công nghệ được lặp lại liên tục từ vị trí tuyển dụng này sang vị trí tuyển dụng khác. Tôi hiểu rằng không thể mô tả hết mọi thứ, nhưng đưa ra một khuôn khổ chung cũng được, vì vậy chúng ta hãy thử đi theo hướng này. Bằng cách nào đó trong quá khứ, tại một trong những dự án, một sự bối rối khá thú vị đã xảy ra, theo tôi, điều này đã và đang lặp đi lặp lại liên tục đối với nhiều người ở khu vực này hay khu vực khác. Nhiệm vụ được đặt là đính kèm bản kết xuất của một trang HTML vào chức năng đã hoàn thiện chỉ để hiển thị trạng thái của từng thực thể. Do đó, đồng nghiệp của tôi đã quyết định đính kèm spring thymeleaf, nó kéo theo một phần phụ thuộc cốt lõi của chính Spring, khi không ai sử dụng Spring. Và đây là tất cả cho một trang thông thường, chỉ hiển thị trạng thái của 2-3 thực thể. "Tôi chưa bao giờ thấy việc sử dụng hai thanh kiếm ánh sáng có ích lợi gì...theo quan điểm của tôi đó là sự phô trương" - Obi-Wan Kenobi. Một mặt, nhà phát triển đã giải quyết vấn đề nhanh nhất có thể, cài đặt một khung mà anh ta có kinh nghiệm sử dụng và tích hợp nó vào dự án trong vài giờ. Nhưng mặt khác, chương trình của chúng tôi đã phát triển về quy mô, vì vậy câu hỏi đơn giản trở thành: liệu anh ấy có làm đúng không? Đối với các tác vụ nguyên tử như vậy, khi bạn biết chắc chắn rằng thymeleaf/Spring MVC, v.v. này sẽ lớn hơn. Nó sẽ không được sử dụng ở bất cứ đâu, tốt hơn hết là không nên sử dụng nó. Tôi luôn ngạc nhiên trước những câu như “Ồ! Có, chúng tôi đã sử dụng Hibernate ở đây! Hãy nhìn xem, mọi thứ đều tuyệt vời, ORM!”, và khi được hỏi câu hỏi hợp lý liệu có thể tiếp tục với JDBC thông thường ở đây hay không, họ nhún vai. Có những kiến ​​trúc thông thường, cần phải đơn giản, cần phải xử lý một cách thận trọng, không nên lộn xộn với những khuôn khổ thời thượng và siêu hiện đại. Như Obi-Wan đã nói ở trên, điều này không gì khác hơn là khoe khoang, mặc dù cần phải biết cách sử dụng chúng. Theo tôi, người theo chủ nghĩa Java trẻ tuổi là người kém may mắn nhất - có quá nhiều thông số kỹ thuật, quá nhiều thư viện cần được nghiên cứu. Chỉ riêng Java EE đã có tài liệu xuyên suốt. Câu hỏi đặt ra là người mới bắt đầu nên học gì, nên học gì tiếp theo, nên làm gì sau Horstmann? Câu trả lời đơn giản: thật không may, gặp rất nhiều người. Và chúng ta sẽ bắt đầu không phải với các khuôn khổ kinh doanh mà với những thứ cần thiết trần tục hơn.

Các hệ điều hành

Linux

Ngoài Windows và/hoặc Yosemite ấm cúng, bạn cần phải mỉm cười vươn tay tới Linux. Đối với một số dự án, chỉ cần trở thành người dùng và biết cách sử dụng dòng lệnh là đủ, đối với những dự án khác - còn hơn thế nữa. Phương pháp nào là tốt nhất? Đơn giản là có rất nhiều sách/hướng dẫn trên Internet. Bắt đầu bằng cách cài đặt Ubuntu hoặc bất kỳ bản phân phối nào khác mà bạn thích và thử sử dụng nó làm hệ điều hành chính trong một hoặc hai tháng tới. Sẽ tốt hơn nhiều nếu bạn bắt đầu học Java bên trong Linux bằng cách biên dịch và thao tác các tệp bằng thiết bị đầu cuối. Dòng lệnh Linux của William Shotts . Đọc cuốn sách này không phải như một cuốn tiểu thuyết “50 sắc thái”, mà như một khóa học tương tác đầy đủ - mở một thiết bị đầu cuối và lặp lại theo tác giả. Bạn có muốn những điều cơ bản và Linux hoạt động như thế nào không? Chúng ta đừng tham gia khóa học Khoa học Máy tính và hệ điều hành - đó là phần tiếp theo. Hãy truy cập edx.org và thử khóa học Giới thiệu về Linux đơn giản . Ngoài ra còn có một cuốn sách trong bộ sách How Linux Works: What Every Superuser Should Know của Brian Ward đã đề cập ở trên . Một ấn phẩm khá minh họa chú ý đến mạng, thiết bị và quản lý tài nguyên. Tiếp tục nhé? Có một cuốn sách rất hay, nhân tiện, tôi có đâu đó ở đây... ừ (phủi bụi)... nó đây rồi! Unix và Linux: Hướng dẫn dành cho quản trị viên hệ thống. Evi Nemeth. Sách hướng dẫn khá lớn, dịch tốt. Thành thật mà nói, cá nhân tôi không nắm vững nó, nhưng tôi thực sự thích những điều cơ bản về quản trị (phần đầu tiên). Đương nhiên, bạn không thể bỏ qua Shell scripting. Tốt hơn hết bạn nên thử tất cả những điều này trong thực tế, nhưng từ sách, bạn có thể xem Học cách bash Shell: Lập trình Unix Shell của Cameron Newham. Không thể trình bày hết một lượng tài liệu khổng lồ về Linux/Unix như vậy, đặc biệt là trong bài viết này, nơi Linux được làm nền. Đồng nghiệp của tôi tại nơi làm việc, người đã rất khó chịu trong vấn đề này, đã khuyên một điều khá thiết thực: Hãy tải xuống ArchLinux và thử khởi động nó. Trong quá trình đó bạn sẽ học được nhiều điều mà tôi không muốn nhất!

các cửa sổ

Trong sơ yếu lý lịch của các lập trình viên có một cột: “Kinh nghiệm sử dụng Windows hơn 10 năm”. Tất nhiên, tôi chúc mừng bạn vì bạn đã chơi trò chơi phản công từ khi 10 tuổi trên Windows, nhưng tôi yêu cầu bạn đừng đào hố trước trong cuộc phỏng vấn, bởi vì trong một dự án mà bạn đang làm việc chặt chẽ với IIS, batch/powershell, God Forbid, việc đăng ký, cuộc phỏng vấn sẽ không thực sự khó khăn, và bên cạnh đó là nụ cười toe toét đối diện với người ngồi. Lida bạn cũng sẽ phải nhận một sự sỉ nhục. Có phải bạn cần điều này? Câu trả lời tự gợi ý. Đặt Windows lậu của bạn sang một bên khỏi torrent và thử cài đặt nó trên một số loại máy ảo Windows Server. Nghiên cứu nó không chỉ từ phía người dùng và cài đặt JAVA_HOME. Về vấn đề này, có một hướng dẫn gần như đầy đủ dưới dạng cuốn sách Làm chủ Windows Server 2012 R2 của Mark Minasi . Ví dụ: nếu bạn sử dụng PowerShell, hãy xem cuốn sách xuất sắc Windows PowerShell in Action by Manning của Bruce Payette . Tôi hiểu rằng không thể đọc hết 1000 trang nhưng ít nhất bạn có thể giữ nó bên mình để tham khảo. Không có gì khác là cần thiết, tôi nghĩ. Do đó, hãy chú ý đến những lỗ hổng kiến ​​thức sử dụng Windows của bạn và tìm kiếm những thông tin bạn quan tâm trên Internet.

Công cụ xây dựng

Maven

Điều quan trọng nhất cần hiểu ở Maven là gì? Dưới đây là các bước và nhiệm vụ đầu tiên:

1. Tìm hiểu những gì Maven làm trong từng giai đoạn, thậm chí bạn có thể ghi nhớ nó. Điều này gần như thành công 80% và sẽ cho bạn một bức tranh rõ ràng.
2. Tạo cục bộ các dự án hộp cát của riêng bạn bằng hệ thống nhiều mô-đun, có tính năng quản lý phụ thuộc rõ ràng. Hãy thử đính kèm các thư viện của bên thứ ba, cố gắng tạo ra thứ gì đó bằng cách sử dụng chúng.
3. Chơi xung quanh với hồ sơ
4. Hiểu cách quản lý plugin và nghiên cứu danh sách các plugin phổ biến nhất trên trang web chính thức.
5. Khám phá cách bạn có thể sử dụng maven tốt nhất trong dự án của mình. Ví dụ: các bản dựng song song có thể giảm đáng kể thời gian xây dựng.

Để tìm hiểu nhanh, hãy truy cập phiên bản tiếng Nga của trang web Apache Maven , tìm kiếm một số hướng dẫn trên Google. Tuy nhiên, ấn bản thứ ba của một trong những cuốn sách chính về Maven sẽ không được phát hành. Cho đến nay đây là ấn bản thứ hai của Sonatype's Maven: The Definitive Guide . Đối với trình độ nâng cao, việc tạo plugin của riêng bạn là phù hợp. Đừng lo lắng về loại plugin bạn cần tạo, vì đã có rất nhiều plugin! Cố gắng tạo ra một số loại tương tự, nghiên cứu các giai đoạn thành hai và hai.

CON KIẾN

Công cụ này trông dễ dàng hơn nhiều nên không có nhiều điều để tìm hiểu ở đây. Vẫn có những dự án mà ANT là công cụ xây dựng duy nhất. Điều này là hoàn toàn bình thường: ANT đã chứng tỏ mình là một công cụ xây dựng đơn giản và dễ hiểu trong bối cảnh quản lý các tác vụ nguyên tử nhỏ (tác vụ kiến). Tất nhiên ở đây có rất nhiều plugin, giống như Maven. Để bắt đầu với ANT, hãy làm như sau:

• Hãy thử thao tác với tập tin và thư mục
• Thực hiện các lệnh khác nhau để thực hiện nhiệm vụ. Dựa trên điều này, hãy tìm hiểu sự phụ thuộc và mức độ ưu tiên của các nhiệm vụ trong ANT.
• Giải nén và/hoặc lưu trữ zip. Trong các tác vụ, hãy thử chơi với nội dung của kho lưu trữ, v.v.

Không cần phải cung cấp nhiều tài nguyên để học ANT. Để tìm hiểu sâu hơn hoặc ít hơn, trang Apache Ant chính thức là đủ. ( ant.apache.org ) và sách Ant in Action của Steve Loughran .

Lớp

Đối với tôi, Gradle gần với ANT hơn là Maven nhưng hoàn toàn có thể gọi nó là anh em cùng cha khác mẹ của hai anh chàng này. Nó có vòng đời tương tự như Maven và tính linh hoạt của các nhiệm vụ tương tự như ANT. Chà, điều quan trọng nhất là Gradle không sử dụng XML và hơn nữa, bạn có thể làm bất cứ điều gì bạn muốn với nó nếu bạn ít nhiều quen thuộc với Groovy. Nói chung là khá ngon. Đừng ngại sử dụng Ant/Maven/Gradle trong ngữ cảnh IDE của bạn. Các công cụ này được tích hợp chặt chẽ vào Eclipse/IDEA và việc sử dụng các công cụ này trong ngữ cảnh của IDE khá thoải mái.

Hội nhập liên tục

Lý thuyết

Đây là những chương trình thiên thần bảo vệ bạn khỏi bị sa thải. Nói tóm lại, đây là phần mềm theo dõi các thay đổi trong mã, xây dựng và chạy các bài kiểm tra được viết cho bạn. Nếu mọi thứ đều ổn sau mỗi lần xác nhận/hợp nhất thì công trình sẽ phát sáng với ánh sáng xanh lục/xanh dương dễ chịu. Ngay khi bạn làm vỡ thứ gì đó, hệ thống CI sẽ báo cáo ngay lập tức. Tuy nhiên, một chút lý thuyết - đây là điều cổ điển! Tích hợp liên tục: Cải thiện chất lượng phần mềm và giảm rủi ro của Paul Duvall . (hay còn gọi là “Tích hợp liên tục” trong tiếng Nga) Cuốn sách này thậm chí còn thảo luận về việc tạo hệ thống CI của riêng bạn. Hãy xem xét hai giải pháp phổ biến nhất trong lĩnh vực này.

Jenkins

Jenkins, hay còn gọi là Hudson. Ứng dụng cởi mở, thân thiện, dễ sử dụng. Để làm quen hơn với Jenkins, hãy thử làm như sau:

1. Tải nó về máy tính của bạn. Cài đặt và định cấu hình JDK, Maven, ANT và mọi thứ bạn cần cho dự án.
2. Tạo Công việc đầu tiên và chỉ định vị trí dự án của bạn, ví dụ: pom.xml chính. Chạy nó, đảm bảo bạn có một số loại thử nghiệm để nó hiển thị rõ ràng.
3. Tìm hiểu cách chạy dự án của bạn với các cài đặt và tùy chọn khác nhau.
4. Đính kèm các plugin khác nhau và xem cách chúng hoạt động cùng với dự án của bạn.
5. Xây dựng các kích hoạt cho các công việc khác nhau. Tạo một đường ống nhỏ.
6. Khám phá DSL và thử tích hợp nó với Jenkins.
7. Thiết lập máy phụ từ một máy tính khác và/hoặc biến nó thành máy thông thường để chạy các bản dựng.
8. Tạo các bản dựng hàng đêm.

Từ sách, chỉ cần đọc Jenkins: The Definite Guide của John Ferguson Smart . Hướng dẫn rõ ràng với nhiều ảnh chụp màn hình.

ĐộiThành Phố

Đúng, TeamCity không miễn phí, nhưng hãy xem nó được tích hợp tốt như thế nào vào hệ sinh thái sản phẩm JetBrains. Intellij Idea và TeamCity là một sự kết hợp tuyệt vời. Nhìn chung, nếu bạn đã quen thuộc với Jenkins, TeamCity sẽ không phải là khu rừng tối tăm đối với bạn và ngược lại. Thay vì nô lệ - tác nhân, các tác nhân tương tự, v.v. Nhưng không giống như Jenkins, TeamCity tự hào có những tính năng tuyệt vời như chạy từ xa, còn được gọi là cam kết được thử nghiệm trước, nhiều số liệu thống kê trực quan hơn và nhiều hơn thế nữa. Tôi rất thích hướng dẫn sử dụng trên YouTube do chính JetBrains thực hiện ( Hướng dẫn sử dụng TeamCity (Phần 1/9) - Giới thiệu ). Tôi thấy TeamCity rất trực quan và tài liệu đạt tiêu chuẩn cao. Nhưng nếu bạn nghĩ có cuốn sách nào đáng xem thì hãy để lại ở phần bình luận. Tất nhiên, tôi chỉ liệt kê một phần nhỏ của các hệ thống CI này, nhưng chúng tôi giới hạn mọi thứ trong phạm vi. Có lẽ hướng dẫn tốt nhất để học là thực hành. Tôi đã cài đặt nó trên máy tính của mình, khởi chạy nó, làm hỏng/khôi phục các bản dựng và đi ngủ. Và sau đó bạn có thể yên tâm mang sổ ghi chép cho tôi (nếu bạn muốn :).

Hệ thống kiểm soát phiên bản

Không có ích gì khi nói nhiều về VCS. Đó chỉ là thứ nên có, và nếu không có nó thì việc quản lý dự án sẽ giống như kỷ nguyên Mesozoi. Tương tự như các hệ thống CI, hãy xem xét hai giải pháp phổ biến nhất: Git và SVN.

Git

Git của chúng tôi đã chứng tỏ mình là một hệ thống kiểm soát phiên bản phân tán ổn định. Bắt đầu học từ đây và xem qua tất cả các chương đã được cấu hình với Git. Sau đó là một loạt hướng dẫn tương tác tuyệt vời từ Code School. Ngoài ra còn có một hướng dẫn ngắn từ họ có tên Try Git: Code School . Từ sách, tôi có thể giới thiệu Kiểm soát phiên bản bằng Git của Jon Loeliger Nếu bạn đã quá quen với con rùa (TortoiseSVN, ghi chú của tác giả) và sợ bảng điều khiển, tất nhiên, bạn có thể tải xuống TortoiseGit tương tự của nó, nhưng, theo ý kiến ​​​​của tôi, dễ chịu và thẩm mỹ hơn nhiều Giải pháp là một sản phẩm từ Atlassian - SourceTreeApp. Bạn có thể thực hành với các kho lưu trữ từ xa vì có đủ dịch vụ lưu trữ trên Internet. Nếu bạn muốn, hãy đào tạo tại địa phương. KHÔNG? Sau đó, tạo một tài khoản trên GitHub và làm việc ở chế độ đầy đủ: thực hiện một vài cam kết, phân nhánh một số dự án nguồn mở, thực hiện một số thao tác hợp nhất giữa các nhánh, v.v.

SVN

Một VCS phổ biến không kém khác là SVN. Hệ thống này không thể tự hào về khả năng phân phối. Mỗi người trong số họ có cách tiếp cận riêng, ưu và nhược điểm riêng. Hãy nhớ đọc cuộc trò chuyện thú vị giữa người mới và người dùng SVN . Có một cuốn sách miễn phí từ read-bean.com với bản dịch tiếng Nga. Một khóa học nhỏ từ TutorialsPoint cũng sẽ cực kỳ hữu ích . Đừng bỏ lỡ trang web chính thức của Apache subversion.apache.org . Khách hàng thú vị nhất đối với tôi là TortoiseSVN đã nói ở trên. Trong số các cuốn sách, có thể nêu bật: Kiểm soát phiên bản bằng Subversion của Michael Pilato . Tôi thích nó vì nó chú ý đến việc quản trị máy chủ SVN. Tôi hy vọng tôi đã không bỏ lỡ những điểm chính.

Công cụ kiểm tra

Sẽ là một ý tưởng hay nếu bạn hiểu rõ các thử nghiệm đơn vị, thử nghiệm tích hợp và thử nghiệm hồi quy trong các dự án hộp cát nhỏ của mình. JUnit Lý thuyết về bài kiểm tra đơn vị được mô tả rõ ràng trong các cuốn sách của bài viết trước. Đặc biệt, Clean Code thậm chí còn mô tả junit là một trong những thư viện phổ biến trong lĩnh vực này. Nhưng khi nói cụ thể đến JUnit, có một cuốn sách nhỏ tuyệt vời tên là Kiểm tra đơn vị thực tế với JUnit và Mockito của Tomek Kaszanowski. Tất nhiên, có nhiều thứ hơn là chỉ JUnit và Mockito. Ở đây tác giả giới thiệu Matchers, đưa ra các ví dụ về các bài kiểm tra được tham số hóa và giới thiệu ngắn gọn về TDD. Ngoài ra còn có một cuốn sách được xuất bản khá gần đây. Đây là Bài kiểm thử đơn vị thực dụng trong Java 8 của Jeff Langr. Tác giả giới thiệu Hamcrest, mô tả các Thực tiễn tốt nhất và tất nhiên là cả Java 8. Bạn có thể yên tâm đọc cuốn sách của Tomek. Nhân tiện, liên quan đến TDD. Tôi không muốn nêu lên quan điểm về việc liệu nó có đáng sử dụng hay không, nó tốt hay xấu, liệu khách hàng có cần chúng hay không. Chỉ cần nhớ: làm việc trong TDD không phải là điều mới lạ và nhiều dự án sử dụng phương pháp này và đối với nhiều người, đó là quy tắc duy nhất và không thể chối cãi. Về lý thuyết, bạn có thể đọc kinh điển. Kent Beck - Phát triển dựa trên thử nghiệm: Bằng ví dụ . Điều tôi thích nhất là phần về các mẫu TDD. Đáng ngạc nhiên là có một khóa học dành cho người đầu tiên rất hay - Hãy phát TDD (200 video!) Trên Youtube. Không kém phần thú vị là cuộc thảo luận của riêng Fowler về việc liệu nó có đáng sử dụng TDD hay không, liệu nó có làm hỏng thiết kế hay không và những thứ tương tự. Chỉ cần nhớ điều này một lần và mãi mãi: TDD không tạo ra thiết kế tồi, bạn tạo ra nó. Nếu bạn sử dụng BDD nhiều hơn (cái này không ảnh hưởng đến cái kia) và ví dụ: sử dụng Cucumber trong một dự án, thì đây là một mặt phẳng hơi khác. Một cuốn sách hay về vấn đề này là Manning BDD in Action: Phát triển theo hướng hành vi cho toàn bộ vòng đời phần mềm của John Ferguson Smart . Nhân tiện, John Ferguson Smart đang tích cực quảng bá chủ đề này đến với đại chúng. Nếu bạn là Scrum Master hoặc PM, người cuối cùng không bị đau mắt nhưng thích xem các bài kiểm tra khi nào thì nếu thì thì hãy nhớ theo dõi John trên Twitter . Về Cucumber, hãy xem cách triển khai Java trên trang web chính thức và đọc cuốn sách The Cucumber Book: Behavior-Driven Development của Matt Wayne .

Thư viện của bên thứ 3

Điều quan trọng là có thể sử dụng các thư viện phổ biến khi cần thiết - chúng đơn giản hóa cuộc sống hàng ngày của mọi nhà phát triển Java. Các giải pháp phổ biến bao gồm: Joda Time. Đề nghị thay thế hoàn toàn Ngày và Giờ gốc bất tiện bằng JodaTime thuận tiện hơn. Đây là một tài liệu tham khảo tốt . Xin lưu ý rằng nếu bạn đã sử dụng Java 8 thì JodaTime sẽ không giúp ích nhiều. Thực tế là API DateTime mới đã thay thế hoàn toàn thư viện này và ở một số chỗ, nó thậm chí còn được sao chép và dán một cách khéo léo. Theo bài viết của chính tác giả , mọi lớp Joda đều có thể được thay thế một cách thuận tiện bằng một lớp tương tự từ java.time. Google Ổi. Theo nhiều cách, Java 8 thậm chí còn thay thế Guava. Các Đối tượng tương tự, API luồng, Dự đoán Java và nhiều thứ khác đề xuất thay thế nó và hoàn toàn không sử dụng nó. Tôi nhắc lại, nếu bạn không có Java 8 thì không có gì tốt hơn hướng dẫn này và bàn tay trực tiếp của bạn.

Apache Commons

Loại bỏ con quái vật này không dễ dàng như vậy: khoảng 40 thư viện cho mọi trường hợp, từ xác thực commons.lang đến xml nổi tiếng, từ DBUtils đến commons.io . Đương nhiên, bạn không cần phải làm quen với mọi thứ, nhưng những cuốn sách và hướng dẫn về Sách dạy nấu ăn sẽ rất hữu ích khi mang theo bên mình. Ví dụ: để hiểu Apache Commons là gì, bạn có thể xem qua Sách dạy nấu ăn Jakarta Commons của Timothy O'Brein

Phần kết luận

Doanh nghiệp rộng lớn đến mức sẽ thật ngu ngốc khi bắt đầu thảo luận về JavaEE và các khung công tác khác mà không có mọi thứ xung quanh Doanh nghiệp này. Do đó, trong phần thứ hai, chúng ta sẽ tập trung vào từng lớp của kiến ​​trúc đa tầng, xem xét các dịch vụ, v.v. Cảm ơn bạn rất nhiều sự chú ý của bạn. Kết thúc phần đầu tiên. Các phần trước của loạt bài:

1. Hướng dẫn dành cho nhà phát triển Java trong tương lai. Java cơ bản
2. Hướng dẫn dành cho nhà phát triển Java trong tương lai. Mã thanh lịch

Bản gốc với DOU