Kiến trúc sư phần mềm, anh là ai? Hệ thống hay chức năng?

Trong bài viết về "Các vai trò trong dự án CNTT" đã có đề cập đến "Kiến trúc sư" (Architect). Trong bài viết này, chúng cùng thử làm rõ thêm để định hướng xem có cần thiết cho ADG không nhé.

Chúng ta thường va chạm và hiểu lầm về khái niệm: "kiến trúc sư phần mềm". Nhiều Team dự án không sử dụng vai trò này hoặc sử dụng không đúng cách. Trong bài viết này, tác giả sẽ cố gắng tiết lộ vai trò của kiến trúc sư và tầm quan trọng trong quá trình thiết kế cũng như phát triển phần mềm. Tất cả đều dựa trên kinh nghiệm của tác giả (hơn 15 năm) cũng như việc nghiên cứu các bài viết về chủ đề này từ các đồng nghiệp và tham khảo ý kiến của các Team Leader lớn.

Trước tiên, xin được chia sẻ một chút về lý do viết bài:

1. Những hiểu lầm khi phỏng vấn:

Không hiểu rõ về vai trò và giá trị của vị trí này.

Khó hiểu trong việc phân chia hạng mục công việc cũng như phân chia trách nhiệm.

Không có phân cấp quản lý rõ ràng trong dự án.

2. Các vướng mắc về dự án:

Lựa chọn sai người thực thi nhiệm vụ.

Còn tồn đọng các vấn đề do làm chắp vá.

Mê hoặc khách hàng thay vì hoàn thành dự án một cách toàn vẹn.

3. Dự án vì dự án:

Kiến trúc "lạ" theo các bài toán cần giải quyết.

Khó khăn trong việc bảo trì/cập nhật.

Không tìm thấy điểm giới hạn trong các bài toán.

Tất cả những vấn đề này dẫn đến một thực tế là trong các dự án, cả trong và sau quá trình thực hiện đều là một MỚ HỖN ĐỘN. Mục đích của bài viết này là giúp các Team như vậy hợp lý hóa quy trình phát triển phần mềm, từ đó cải thiện chất lượng công việc của dự án.

Bài viết này sẽ làm rõ các câu hỏi sau:

Kiến trúc sư là ai?

Kiến trúc sư thực hiện những công việc gì?

Kiến trúc sư KHÔNG thực hiện những nhiệm vụ nào?

Có thể làm mà không cần có kiến trúc sư?

Sự khác biệt giữa kiến trúc sư hệ thống và kiến trúc sư chức năng?

Ai là người phụ trách: PM hay SA? Team dự án chịu sự quản lý của ai?

Kiến trúc sư là ai?

Để trả lời câu hỏi này, trước tiên, chúng ta cần có định nghĩa về kiến trúc.

Kiến trúc phần mềm là một tập hợp các giải pháp quan trọng về việc tổ chức của hệ thống phần mềm. Kiến trúc bao gồm:

Lựa chọn các yếu tố cấu trúc và giao diện mà sẽ cấu thành hệ thống cũng các hành vi trong khuôn khổ tương tác các thành phần.

Các cách để kết nối các yếu tố được chọn trong cấu trúc hình thành với các hệ thống lớn hơn.

Có phong cách định hướng cho tất cả các yếu tố, giao diện, tương tác và kết nối.

Định nghĩa này có thể được tìm thấy trên mạng. Cùng biên dịch nó sang cách nói của 1C:

Kiến trúc sư xác định thành phần và cấu trúc của các đối tượng Metadata và mối quan hệ giữa tất cả các đối tượng Metadata trong mỗi phân hệ.

Mỗi giải pháp bao gồm các phân hệ. Thành phần của mỗi phân hệ và sự tương tác giữa các phân hệ được xác định bởi kiến trúc sư.

Kiến trúc sư xác định xem bằng các đối tượng Metadata nào để giải quyết một vấn đề cụ thể, mức độ cần thiết để tùy chỉnh giải pháp chuẩn, những đối tượng Metadata nào cần tạo mới.

Xác định cách thức để phát triển giao diện.

Xác định các kịch bản cho từng đối tượng Metadata.

Như có thể thấy từ định nghĩa và theo cách nói của 1C, kiến trúc sư chịu trách nhiệm:

Cấu trúc Metadata.

Chức năng của hệ thống.

Khả năng chịu lỗi hệ thống.

Dễ dàng sử dụng hệ thống.

Hiệu năng của hệ thống.

Thuận tiện trong việc bảo trì.

Nhiệm vụ của một kiến trúc sư là gì?

Sau khi đã hiểu kiến trúc sư là ai, chúng ta có thể nghĩ về nhiệm vụ của kiến trúc sư.

Nhiệm vụ chính của kiến trúc sư là (trong khía cạnh xác định bài toán): nghiên cứu thông tin và thiết kế.

Nghiên cứu thông tin:

Nghiên cứu tài liệu. Nhiều quy trình kinh doanh được mô tả rõ ràng trong các văn pháp pháp chế của công ty.

Nghiên cứu quy trình. Chúng ta nghiên cứu các quy trình kinh doanh mà không cần gắn với các phần mềm đang sử dụng. Lý do là nhiều giai đoạn trong quy trình kinh doanh hiện tại thường diễn ra bên ngoài phần mềm và cần phải tự động hóa.

Cấu hình mẫu: Không thể thiết kế chính xác một hệ thống mà không nghiên cứu các kịch bản và cấu trúc của một cấu hình mẫu sẵn có.

Phần mềm hiện tại. Ở giai đoạn này, cần phát hiện ra các bài toán mà cần lưu ý đặc biệt. Ngoài ra, cũng có thể xem lỗi của các Team trước đây và tránh không mắc lại.

Thiết kế:

Thành phần Metadata. Đưa ra quyết định xem các đối tượng Metadata nào sẽ dùng để giải quyết bài toán.

Định nghĩa cấu trúc Metadata nói chung và từng đối tượng Metadata nói riêng.

Xác định tương tác Metadata. Xác định mối quan hệ giữa các đối tượng Metadata.

Bổ sung kịch bản. Bổ sung cho hệ thống bằng các kịch bản mới.

Để hoàn thành công việc đúng thời hạn và chất lượng yêu cầu, kiến trúc sư thực hiện các công việc sau (trong phần hỗ trợ và nghiệm thu):

Hỗ trợ triển khai:

Giải thích bài toán và kịch bản cho người thực thi. Không nên nghĩ rằng, chỉ cần URD là người thực thi sẽ tự giải quyết. Có thể giảm thời gian và thảo luận về bài toán trước khi bắt đầu công việc. Điều này cho phép tất cả mọi người, người ra đề bài và người thực thi, đều có cách hiểu giống nhau.

Thảo luận về phương pháp thực hiện. Cần thảo luận trước về điểm này để không phải làm lại.

Xem xét thiết kế (Design Review). Giai đoạn này diễn ra khi thực hiện được 30-40% khối lượng công việc. Cần phải đảm bảo rằng con đường mà kiến trúc sư đã chọn là chính xác. Ở cùng một giai đoạn, có thể tìm thấy các kịch bản bổ sung yêu cầu tự động hóa.

Kiểm tra thực hiện:

Kiểm tra thực hiện (Code Review).

Tổ chức kiểm thử nội bộ (Alpha-Beta test). Kiểm tra biên bản thử nghiệm.

Đưa các phần làm thêm vào bản phát hành.

Các nhiệm vụ dự án khác:

Tham gia phỏng vấn để đánh giá kiến thức trong lĩnh vực ứng dụng và kỹ năng lập trình.

Thảo luận về các nhiệm vụ với chuyên viên phương pháp luận và khách hàng.

Đánh giá sơ bộ về thời gian thực hiện các nhiệm vụ.

Tham gia phân tích nguyên nhân sự cố.

Tham gia xây dựng quy chế làm việc nhóm (vai trò phối hợp).

Tham gia xây dựng tài liệu kỹ thuật (vai trò phối hợp).

Kiến trúc sư KHÔNG nên làm gì?

Thường trong nhiều dự án, kiến trúc sư được giao những nhiệm vụ không thuộc chức năng của mình:

Chức năng quản lý:

Kiểm soát thời gian thực hiện các nhiệm vụ.

Lập kế hoạch dự án (toàn bộ dự án, kế hoạch tuần, kế hoạch tháng).

Giải quyết các vấn đề liên quan đến tiền bạc, ngân sách, lương, thưởng.

Thống nhất về ngày lễ, ngày nghỉ, nghỉ bù, trực…

Kiểm soát đi muộn về sớm.

Ký biên bản, bảng chấm công.

Thủ tục giấy tờ:

Viết hướng dẫn cho người dùng.

Mô tả kiến trúc máy chủ.

Bảo mật thông tin.

Tài liệu yêu cầu và tài liệu dự án.

Quy chế nội bộ.

Các nhiệm vụ khác:

Team building.

Đào tạo và phát triển nhân viên.

Thuyết phục đồng nghiệp và cấp quản lý về tính đúng đắn của giải pháp kiến trúc.

Bàn giao sản phẩm cho khách hàng.

Tư vấn người dùng.

Thuyết phục đồng nghiệp sửa sai.

Truy tìm người dùng sai.

Nói dối khách hàng là sau này sẽ sửa.

Thiết lập và quản trị máy chủ cũng như các phần mềm khác.

Có thể triển khai dự án mà không có kiến trúc sư?

Để trả lời câu hỏi này, cần phải phân tích từng nhiệm vụ của kiến trúc sư và tìm người thực hiện nó. Điểm mấu chốt là đảm bảo kết quả thực hiện nhiệm vụ này có c hất lượng tương đương giống như có một kiến trúc sư!

Làm rõ các yêu cầu. Thường thì nhiệm vụ này được giao cho BA hoặc Consultant. Một trong những bài viết sau đây sẽ mô tả năng lực của các thành viên trong nhóm. Để làm rõ các yêu cầu, bạn cần biết kiến trúc hiện tại của giải pháp cũng như các kịch bản và tính năng triển khai. Một BA/Consultant không có năng lực như vậy. Đối với một số tác vụ, cần tổ chức lại quy trình nghiệp vụ để giảm bớt sự phức tạp trong quá trình phát triển. Để làm được điều này, cần đặt các câu hỏi theo quan điểm phù hợp.

Định nghĩa cấu trúc Metadata. Nhiệm vụ này thường được giao cho BA hoặc Developer. Trong trường hợp đầu tiên, BA không phải là Developer, điều đó có nghĩa là anh ta không thể thiết kế giải pháp một cách chính xác! Trong trường hợp thứ hai, Developer sẽ tìm cách giải quyết vấn đề ngắn nhất. Anh ta có thể tính đến tất cả các tình huống, nhưng chỉ những tình huống rõ ràng đối với anh ta. Developer thường không làm việc với dữ liệu và không nhận thức đầy đủ về các quy trình kinh doanh đang diễn ra trong công ty.

Định nghĩa các kết nối giữa các đối tượng. Nhiệm vụ này cũng được giao cho BA hoặc Developer. Mỗi BA và Developer riêng lẻ không nhận thức được toàn bộ nhóm nhiệm vụ. Hậu quả của việc này là việc sàng lọc những đối tượng không thể hoàn thiện hoặc cần có một cách khác để giải quyết vấn đề. Điều này dồn hết trách nhiệm cho một quyết định sai lầm từ người này sang người khác. Kết quả là không ai chịu trách nhiệm về những sai sót đã phát sinh, và quan trọng nhất là không ai lường trước được để tránh sai sót.

Bổ sung cho hệ thống với các kịch bản mới. Thông thường, các kịch bản thử nghiệm xuất hiện sau khi quá trình phát triển hoàn tất. Người viết kịch bản thường là một Consultant. Đây là một sai lầm khủng khiếp!!! Bởi vì phần mềm nên được thực hiện theo các kịch bản cụ thể! Ở giai đoạn ban đầu, cần phải tính đến tất cả các kịch bản và suy nghĩ về tính toàn vẹn của giải pháp.

Thảo luận về phương pháp thực hiện. Thông thường giai đoạn này diễn ra trước khi viết yêu cầu kỹ thuật. Tất cả mọi người đều cần tham gia vào các cuộc họp như vậy. Mọi người đang cố gắng tìm ra cách giải quyết vấn đề bằng những nỗ lực chung. Nghĩa là, khi bắt đầu thảo luận thì không có một ai biết cách đi đúng hướng. Nó giống như bị lạc trong rừng và mọi người hò hét để định hướng, thay vì mang theo người hướng đạo và thiết bị GPS. Design review là một giai đoạn mà mục đích của nó là tìm hiểu xem Developer có hiểu đúng tuyên bố vấn đề hay không, liệu có bắt đầu đúng vị trí cần sửa trong mã nguồn hay không. Developer có sử dụng API hay không. Như bạn có thể thấy từ phần mô tả, yêu cầu đã được viết! Và có một người biết cách giải quyết các vấn đề một cách chính xác!

Kiểm tra việc thực hiện. Trong hầu hết các dự án mà tôi đã thấy khi “từ bên ngoài”, giai đoạn này hoàn toàn không có hoặc được giao phó cho Developer. Nghĩa là một Developer kiểm tra việc thực hiện của một Developer khác. Điều gì đang xảy ra? Mỗi Developer chỉ biết nhiệm vụ của mình. Để kiểm tra vấn đề, bạn cần tìm hiểu sâu về nó! Bởi vì các mốc thời gian lập trình luôn chặt chẽ và trình độ của các Developer là khác nhau, cho nên việc kiểm tra chất lượng như vậy chỉ mang tính hình thức. Nhiều người không tuân theo các tiêu chuẩn lập trình, viết mã dưới mức tối ưu hoặc không thể đọc được, không biết cách tối ưu hóa các truy vấn và nói chung là viết rất nhiều mã không cần thiết. Chỉ cần đánh dấu đã hoàn thành trong Jire. Cách kiểm tra này cũng tốt, nhưng sẽ không có kết quả tốt từ nó!

Kiểm tra biên bản thử nghiệm. Thông thường, trong quá trình kiểm thử có thể xuất hiện thêm các kịch bản mới (do khách hàng hoặc một trong các thành viên trong nhóm đưa vào). Có thể cần phải thiết kế lại cho các kịch bản mới. Những nhược điểm của việc thiết kế bởi các Consultant và Developer đã được mô tả ở trên.

Đưa các cải tiến vào bản phát hành. Mọi người có lẽ không lạ với tình huống khi ai đó xóa sạch những cải tiến của người khác? Đây là kết quả của việc tất cả mọi người đều tham gia vào việc đóng gói bản phát hành.

Nếu bạn đọc kỹ tất cả các nhiệm vụ được mô tả của một kiến trúc sư thì rõ ràng rằng chỉ một người có nhiều kiến thức và kinh nghiệm – một kiến trúc sư – mới có thể thực hiện / kiểm soát các nhiệm vụ này một cách chính xác! Không thể thay thế chất lượng một kiến trúc sư!

Mỗi thành viên trong nhóm phải thực hiện công việc của mình:

Kiến trúc sư: đặt mục tiêu, kiểm tra kết quả và tạo bản phát hành.

BA: soạn thảo hướng dẫn, kịch bản, giao công việc cho khách hàng.

Consultant: thử nghiệm cải tiến, hỗ trợ người dùng.

Developer: thực hiện công việc theo các tuyên bố đã được kiến trúc sư phê duyệt.

PM: công việc hành chính, theo dõi thời hạn, quản lý ngân sách dự án, đàm phán với khách hàng.

Nhược điểm khi không có kiến trúc sư:

Không có ai chịu trách nhiệm. Không ai chịu trách nhiệm về các quyết định tập thể.

Không có sự liên kết các nhiệm vụ. Các nhiệm vụ phát triển được ban hành không liên kết với nhau hoặc phá vỡ lẫn nhau.

Thiếu bức tranh dữ liệu toàn cảnh. Dữ liệu không đầy đủ ở giai đoạn khảo sát.

Cấu trúc Metadata không phù hợp. Có vấn đề khi cập nhật cấu hình mới.

Thuật toán không tối ưu. Khó khăn trong việc phát triển các thuật toán phức tạp, giải pháp không tối ưu.

Vấn đề khi phát hành. Luôn vấn đề khi xây dựng bản phát hành. Vườn bách thú mã nguồn.

Sự khác biệt giữa kiến trúc sư hệ thống và kiến trúc sư chức năng là gì?

Gần đây, việc sử dụng từ kiến trúc sư gắn kèm với cụm từ “chức năng” và “hệ thống” đã trở thành mốt. Cùng xem họ là ai, và quan trọng nhất là có cần 2 kiến trúc sư không?

Có thể thấy, kiến trúc sư chức năng chịu trách nhiệm về chức năng của hệ thống, về nội dung kịch bản của các phân hệ. Thôngvthường đây KHÔNG phải là người có khả năng lập trình. Người này biết rõ cách giải quyết các nhiệm vụ khác nhau bằng các chức năng mẫu trong giải pháp.

Năng lực của một chuyên gia như vậy bao gồm:

Kiến thức về tất cả các phân hệ của phần mềm đang triển khai.

Kiến thức về nội dung kịch bản của các đối tượng.

Kiến thức về cài đặt phần mềm hiện có.

Kỹ năng làm việc với lượng dữ liệu lớn, cách sửa các lỗi thường gặp.

Kỹ năng thu thập và hệ thống hóa thông tin từ người dùng.

Kiến trúc sư hệ thống là ai? Đây chủ yếu là một chuyên gia kỹ thuật và Developer. Năng lực của một chuyên gia như vậy bao gồm:

Kiến thức về tất cả các phân hệ của phần mềm đang triển khai.Kiến thức về nội dung kịch bản của các đối tượng.

Kiến thức về cài đặt phần mềm hiện có.

Kỹ năng làm việc với lượng dữ liệu lớn, cách sửa các lỗi thường gặp.

Kỹ năng thu thập và hệ thống hóa thông tin từ người dùng.

Kiến thức về các đối tượng Metadata, quy tắc sử dụng chúng.

Kiến thức về xây dựng các đối tượng Metadata từ góc nhìn mã nguồn.

Kiến thức về cách tối ưu hóa truy vấn và mã nguồn nói chung.

Kiến thức về các tiêu chuẩn lập trình.

Kiến thức về kiến trúc máy chủ (không bắt buộc).

Kiến thức về thiết lập SQL, quản trị cơ sở dữ liệu (không bắt buộc).

Như bạn có thể thấy từ phần mô tả, kiến trúc sư chức năng khác với kiến trúc sư hệ thống chỉ là không có kiến thức trong lĩnh vực lập trình! Nếu cả hai chuyên gia làm việc trong dự án thì sẽ phát sinh những một số nhược điểm:

Xung đột ý kiến liên tục. Đó là do kiến thức sâu sắc về kiến trúc của giải pháp "từ bên trong". Thông thường, khi thiết kế các giải pháp, một kiến trúc sư chức năng chỉ đơn giản là tìm kiếm con đường ngắn nhất với những sửa đổi tối thiểu. Kiến trúc sư hệ thống tìm kiếm cách phù hợp phù hợp chính xác với khái niệm giải pháp, sẽ hoạt động tối ưu về mặt hiệu suất và sẽ không làm gián đoạn khả năng nâng cấp của hệ thống.

Cả hai kiến trúc sư sẽ làm việc với một nửa sức mạnh. Thông thường đây là 2 chuyên gia được trả lương cao.

Không có trung tâm ra quyết định duy nhất. Có thể liên tục tìm kiếm người có lỗi, cả về phía người giao việc hoặc về phía người thực hiện.

Do đó, nếu có cái gọi là kiến trúc sư chức năng thì cần phải phục tùng kiến trúc sư hệ thống! Tuy nhiên, một chuyên gia như vậy có thể được ủy thác quản lý một nhóm BA và Consultant. Một kết hợp như vậy giúp loại bỏ xung đột về ý kiến. Mọi người đều tham gia vào nhiệm vụ của họ và cố gắng thực hiện nó với chất lượng cao nhất. Chất lượng là tiêu chí chính khi đưa ra quyết định về một dự án.

Ai phụ trách: PM hay kiến trúc sư? Team dự án trực thuộc ai?

Câu hỏi muôn thuở: "Team dự án trực thuộc ai?" Có phải vậy không? Có hay không sự thỏa hiệp về vấn đề này? Hãy thử tìm ra nó.

Để làm điều này, cùng thử xem các khu vực trách nhiệm của PM và của kiến trúc sư.

Trước tiên, PM có trách nhiệm:

Giao tiếp giữa Team dự án và khách hàng.

Theo dõi và ghi nhận các công việc đã thực hiện.

Xây dựng quy chế làm việc.

Kiểm soát thời hạn thực hiện các công việc.

Thúc đẩy các thành viên trong Team (trong đó bằng cả KPI).

Phát triển năng lực, đào tạo.

Báo cáo tình hình dự án cho khách hàng.

Thống nhất việc vắng mặt của thành viên trong Team.

Team building.

Quản lý ngân sách dự án (không bắt buộc).

Tiếp theo, kiến trúc sư chịu trách nhiệm về:

Kiến trúc của giải pháp.

Chất lượng mã nguồn.

Chất lượng và tính đầy đủ của các kịch bản công việc.

Tài liệu kỹ thuật.

Các cách để loại bỏ lỗi trong dữ liệu.

Thiết lập hệ thống.

Chỉ định người thực hiện công việc.

Trình tự thực hiện các công việc.

Đánh giá năng lực của các thành viên trong Team.

Như có thể thấy từ phần mô tả, PM không chịu bất kỳ trách nhiệm nào về chất lượng công việc được thực hiện. Vâng, tất nhiên, trước hết PM sẽ bị chỉ trích vì thiếu chất lượng. NHƯNG! Vai trò của PM chỉ đơn giản là mang về cho Team tất cả các khiếu nại, tìm ra ai và khi nào sẽ sửa lỗi. PM sẽ không ở bên cạnh Developer cho đến đêm lập trình hoặc gỡ lỗi người dùng.

Ở bên trên có mô tả phạm vi trách nhiệm của kiến trúc sư. Như chúng ta có thể thấy, chính kiến trúc sư sẽ là người chính giải quyết việc loại bỏ các lỗi.

Từ đó, chúng ta có thể kết luận rằng về các vấn đề hành chính, thông tin liên lạc… của Team đều phụ thuộc vào PM. Nhưng hoàn toàn không thể chấp nhận được khi PM giao việc cho cả Developer, thậm chí cho cả Consultant mà không được sự đồng ý của kiến trúc sư.

Từ đó chúng ta có thể rút ra kết luận thứ hai rằng, đối với các vấn đề kỹ thuật, Team sẽ báo cáo với kiến trúc sư. Nếu như kiến trúc sư chấp thuận hoặc từ chối phương án nào đó để giải quyết vấn đề thì không ai trong Team có quyền thay đổi quyết định đó. Ngay cả PM toàn năng cũng không có quyền làm vậy. Tác giả bài viết này cũng chưa thấy PM nào nói trực tiếp với khách hàng là: “Tôi đã bảo kiến trúc sư làm như vậy (thời hạn sắp hết hoặc dự án không có tiền cho việc này), và tất cả do tôi nên mới phát sinh vấn đề như vậy”.

Ngay cả khi giả định rằng PM đã nói như vậy thì cũng hoàn toàn sai trong việc đưa ra quyết định mà sẽ gây ra vấn đề. Chính kiến trúc sư là người chịu trách nhiệm đảm bảo rằng, sẽ không có vấn đề gì phát sinh.

Nhiệm vụ của PM có năng lực và kinh nghiệm là tìm hiểu xem cần bao nhiêu nguồn lực để giải quyết một nhiệm vụ kéo dài, tìm ra các lập luận cho khách hàng và truyền đạt tất cả thông tin này cho khách hàng. Trong những tình huống như vậy, việc đưa một kiến trúc sư đi cùng PM đến một cuộc họp là hoàn toàn hợp lý để kiến trúc sư giải thích cho khách hàng bằng ngôn ngữ kỹ thuật là tại sao lại như vậy chứ không phải là thế khác.

Từ bài viết, chúng ta có thể rút ra những kết luận đơn giản nhưng rất quyền năng:

Mọi người nên làm đúng việc của mình trong Team!
Phải có người giải quyết về chất lượng công việc. Chất lượng không tự nhiên hình thành!

Thuật ngữ và viết tắt:

PM – Project Manager (Quản lý dự án)

SA – System Architector (Kiến trúc sư hệ thống)

BA – Business Analytic (Phân tích nghiệp vụ)

URD - User Requirement Document (Tài liệu yêu cầu)

Team - Đội dự án

Developer - Lập trình viên

Consultant - Chuyên gia tư vấn

API - Giao diện lập trình ứng dụng

Code Review - Rà soát mã nguồn

Design Review - Rà soát thiết kế

KPI - Key Performance Indicator (Chỉ tiêu hiệu quả công việc)

Metadata - Đối tượng siêu dữ liệu trong hệ thống 1C

(Sưu tầm và biên dịch từ diễn đàn infostart.ru: Trần Thắng)

Tìm kiếm Blog này

Câu chuyện công nghệ