Tô Mỳ Minh Duy (CTTMMD)

Đào tạo Lập trình viên

Cách soạn thảo Truyện hệ

Nếu không biết cách viết truyện hệ của phương pháp lập trình cực độ thì bạn cũng chưa làm việc theo kiểu VietnamQA được. Nhân viên và cộng sự nhóm xây hệ web ta ai cũng phải biết cách làm việc theo kiểu VietnamQA: dùng Đại Việt Ngữ viết truyện hệ làm việc theo phương pháp Lập trình Cực độ, như được giải thích tận tượng dưới đây.

Lập trình cực độ, viết tắt là LTCĐ hoặc XP cho cụm từ extreme programming, là một phương thức công nghệ phần mềm, một phương thức nổi bật nhất trong số vài phương thức phát triển phần mềm lanh lợi. Làm như những phương thức lanh lợi khác, lập trình cực độ khác với các phương thức truyền thống trước hết qua việc đặt cao giá trị khả năng thích ứng hơn là khả năng dự đoán. Giới biện hộ LTCĐ coi các thay đổi yêu sách luôn diễn ra như là một khía cạnh tự nhiên, không tránh được và đáng khát khao của những dự án phát triển phần mềm. Họ tin rằng hiện là khả năng thích ứng tới việc cần thay đổi những yêu sách ở bất cứ thời điểm nào trong đời sống dự án là một phương sách thực tế hơn và tốt hơn là việc toan định nghĩa tất cả những đòi hỏi trước khi khởi đầu một dự án và rồi lại phải tiêu dùng công sức điều khiển các thay đổi cho những đòi hỏi đó.

LTCĐ kê đơn một bộ thông lệ thường ngày cho các quản lý gia và các nhà phát triển. Những thông lệ đó là để hiện thân và khuyến khích các giá trị đặc thù. Giới biện hộ tin rằng việc dùng những thông lệ này, tức là những thông lệ truyền thống của công nghệ phần mềm nhưng lại được đưa lên tới mức “cực độ”, sẽ dẫn một quá trình phát triển tới tình trạng sẵn sàng đáp ứng nhu cầu khách hàng (“lanh lợi”) nhiều hơn là các phương pháp truyền thống trong cùng một lúc tạo được phần mềm có chất lượng tốt hơn.

Nói một cách ngắn gọn, LTCĐ là một bộ các giá trị, nguyên lý và thông lệ dùng để phát triển hoặc khuếch trương tuyệt nhanh phần mềm có chất lượng cao nhằm chu cấp giá trị cao nhất cho khách hàng bằng con đường ngắn nhất. Sự cực độ trong LTCĐ có nghĩa là lấy 12 “thông lệ tốt nhất”, xem Hoàng Thanh, trong các phương sách phát triển phần mềm lừng danh rồi cùng một lúc thực hiện một cách tột đỉnh từng thông lệ một.

Như có nói trong bài viết, Triết Lý Lập Trình Cực Độ, vừa là một triết lý vừa là một phương thức, LTCĐ gồm có bốn đức hạnh, những giá trị mà được diễn đạt trong 12 thông lệ phát triển phần mềm. Bất cứ đội ngũ nào cũng sẽ làm việc như một đơn vị cố kết hơn nếu các đội viên chia sẻ cùng một số các giá trị. Phần lớn các đội chọn để cho các giá trị của họ mặc định, nhưng LTCĐ làm ra cho các giá trị tự phê chuẩn qua giấy tờ. Bốn giá trị chung để tất cả các đội LTCĐ là: thông tri, hồi tiếp, đơn giản và can đảm.

  • Thông tri: Thông tri tốt quan trọng trong mỗi dự án, và phần lớn các hiệp thất bại dự án có thể truy nguyên đến thông tri nghèo hoặc non, tức là không hợp thời. LTCĐ nỗ lực giữ dòng thông tri trôi chảy bằng cách thiết lập các thông lệ đòi hỏi thông tri.
  • Hoàng Thanh: XP chú trọng việc trao đổi thông tin một cách ‘trong suốt’ giữa các thành viên trong nhóm phát triển. Đề cao việc trao đổi trực tiếp, giảm việc trao đổi gián tiếp hay hinh thức thông qua các văn bản.
  • Hồi tiếp: Các đội LTCĐ cũng thiết lập thông lệ cho hồi tiếp là lệ thường. Hồi tiếp bao trùm cái độ chính xác của kế hoạch, hệ chức năng của cái hệ thống, và chất lượng của cả thiết kế lẫn mã nguồn. Hồi tiếp thường lệ cho phép một đội LTCĐ lèo lái dự án đi tới kết luận hiệu quả.
  • Hoàng Thanh: Phản hồi sớm và liên tục từ khách hàng cũng như từ nhóm phát triển giúp cho dự án luôn đi theo đúng hướng. XP đều đặn giao sản phẩm cho khách hàng để kiểm tra, theo đó khách hàng có thể ‘làm mịn’ và hoàn thiện yêu cầu sản phẩm dựa trên các kết quả cụ thể. Với sự trợ giúp của khách hàng, XP xây dựng một tập các phép thử phụ vụ cho việc kiểm định (acceptation test) một cách liên tục trong suốt quá trình phát triển phần mềm.
  • Đơn giản: LTCĐ yêu cầu chúng ta nhìn vào cái đơn giản nhất mà có thể làm được việc, và phải kháng cự sự quyến rũ của sự tổng quát hoá hấp tấp. Các đội LTCĐ tin rằng mà thông tri tốt và hồi tiếp tốt sẽ cho họ biết khi nào và nơi nào các giải quyết đơn giản của họ cần phải trở nên tinh vi hơn.
  • Hoàng Thanh: XP đảm bảo chỉ phát triển những chức năng mà khách hàng yêu cầu. Phần thiết kế và mã nguồn được thiết lập một cách đơn giản nhất, cho phép có được đặc tính ‘mở’ cao nhằm đáp ứng với các thay đổi liên tục và luôn duy trì được một tốc độ phát triển nhanh trong suốt quá trình phát triển phần mềm.
  • Dũng cảm: Trong một dự án LTCĐ, các đội viên đều được động viên để chỉ có làm mấy cái mà đem thêm giá trị đến với khách hàng, và chỉ làm những việc đó càng nhanh càng tốt. Nếu không có thông tri và hồi tiếp tốt thì nó chỉ là việc làm đốn đẽo mà thôi. Nếu không có một hệ thống khả thi đơn giản nhất thì nó chỉ là việc làm điên rồ. Nhưng trong văn cảnh có các giá trị khác, sự can đảm cho đội ngũ tối đa hoá cái giá trị của hệ thống chót.
  • Hoàng Thanh: XP cho rằng phải có lòng dũng cảm thì mỗi thành viên mới thực hiện được các nguyên tắc kể trên. Tuy XP không chỉ ra một cách rõ ràng, nhưng cũng cần phải nhấn mạnh rằng tính kỷ luật là yêu cầu quan trọng để thực hiện có hiệu quả phương pháp phát triển phần mềm XP.

Truyện hệ là gì?

Văn kiện nhỏ nhất trong LTCĐ gọi là truyện hệ. Không ai nhấn mạnh đầy đủ được tầm quan trọng của truyện hệ trong quá trình LTCĐ.

Một truyện hệ là một yêu sách hệ thống phần mềm có công thức ra một hoặc hai câu văn dùng ngôn ngữ thường ngày của người dùng. Các truyện hệ cùng với những bài cuộc trắc nghiệm chấp thuận chính là đặc tả của những yêu sách trong phương pháp lập trình cực độ. Mỗi truyện hệ thường được viết thành văn bản trên một thiếp giấy nhỏ để đảm bảo rằng nó sẽ không trở nên quá dài. Khách hàng nên là những người viết truyện hệ đó cho dự án và đó là phương tiện chính cho họ ảnh hưởng trực tiếp sự phát triển phần mềm.

Các truyện hệ là một cách xử lý yêu sách khách hàng nhanh mà không cần phải lo về một tài liệu yêu sách chính thức to lớn và các công tác chán ngắt liên quan đến việc vẫn phải tiếp tục duy trì tài liệu đó. Chủ ý là để có khả năng hưởng ứng nhanh hơn và với tốn ít tổng phí hơn tới những đòi hỏi ngoài đời thay đổi nhanh xiết.

Một truyện hệ là một lời tuyên bố thân mật của yêu sách. Khi một truyện hệ cần phải được thực hiện đầy đủ, khách hàng nên viết một văn bản định nghĩa cuộc trắc nghiệm chấp thuận để đảm bảo rằng sau này ai cũng có thể xác định xem những mục tiểu của truyện hệ đó đã được thực hiện y theo nguyện vọng khách hàng.

Các truyện hệ (user stories) phục vụ cùng một chủ tâm như các cảnh hệ (use cases) nhưng không cùng là một thứ. Không cần phải nói về cảnh hệ nhưng nó là một cách cho thấy đặc điểm hệ thống bằng cách trình diễn một phần của hệ chức năng. Mỗi cảnh hệ thành lập một tiến trình hoàn tất hành động do một diễn viên khởi xướng, và nó định rõ tương tác giữa diễn viên và hệ thống. Toàn bộ các cảnh hệ định rõ tất cả các cách dùng sẳn có của cái hệ thống.

Trở về truyện hệ, chúng ta dùng một truyện hệ để tạo ước lượng thời gian cho cuộc họp ra kế hoạch phóng thích sản phẩm nào đó. Chúng ta dùng truyện hệ thay vì một yêu sách to lớn chứa đầy những lời đòi hỏi phức tạp. Các truyện hệ là do các khách hàng viết ra thành văn bản cho biết cái hệ thống cần phải làm gì cho họ. Các truyện hệ có những điểm tương tự như các diễn xuất sử dụng (user scenarios), ngoại trừ rằng chúng không bị giới hạn chỉ diễn tả một giao diện người dùng nào đó mà thôi. Chúng nằm trong khuôn khổ có hai ba câu văn do khách hàng tự viết dùng thuật ngữ hệ của khách hàng và không có cú pháp kỹ thuật.

Các truyện hệ cũng thúc đẩy việc tạo các cuộc trắc nghiệm chấp thuận. Phải có một hoặc nhiều cuộc trắc nghiệm chấp thuận tự động để kiểm lại cho thấy truyện hệ đã được thực hiện đầy đủ và đúng tiêu chuẩn.

Một trong những nỗi hiểu lầm lớn nhất với các truyện hệ là cách chúng khác với các văn kiện yêu sách truyền thống. Sự khác biệt lớn nhất là ở cái mức độ chi tiết. Các truyện hệ chu cấp chỉ đủ chi tiết để đem nguy cơ xuống mức độ thấp phải chăng khi ước lượng cần phải có bao lầu để thực hiện đầy đủ câu truyện đó. Khi tới lúc thực hiện câu truyện các nhà phát triển truyện hệ sẽ đi tới đối diện với khách hàng nhận thêm chi tiết diện mạo của những đòi trong truyện hệ.

Các nhà phát triển ước lượng cần bao lâu để thực hiện đầy đủ các truyện hệ. Từng truyện một sẽ được ước lượng bằng thời gian phát triển lý tưởng: 1, 2 hoặc 3 tuần. Thời gian phát triển lý tưởng này là số giờ cần phải có để mã hoá đầy đủ truyện hệ nếu không bị làm lãng trí, không có các việc giao phó khác, và bạn đã biết xác đáng cần phải làm gì. Lâu hơn hơn là 3 tuần có nghĩa là bạn cần phải tách truyện đó ra thành nhiều truyện nhỏ hơn. Ít hơn một tuần thì bạn ở một mức độ quá đầy chi tiết, nên phối hợp với vài truyện khác. Độ chừng 80 truyện hệ cộng hoặc trừ 20 là một con số hoàn hảo để ra tạo một kế hoạch phóng thích trong thời kỳ đặt kế hoạch phóng thích.

Một sự khác biệt khác giữa các truyện hệ và một văn kiện yêu sách là tiêu điểm trên các điều thiết cần của người dùng. Bạn nên cố để tránh các chi tiết của công nghệ đặc điểm, cách dàn trận cơ sở dữ liệu, và các thuật toán. Bạn nên cố giữ các truyện hệ hội tụ vào các điều thiết cần của và các phúc lợi cho người dùng, trái ngược với việc định rõ cách dàn trận giao diện minh hoạ (GUI).

Cách soạn thảo Truyện hệ

Một truyện hệ tốt phải (a) chú tâm vào khách hàng, (b) bằng 100% tiếng Việt ngắn gọn dễ cho cha mẹ mình hiểu trong 60 giây hoặc dùng Đại Việt Ngữ, (c) không có quá lớn mà cũng không có quá nhỏ, và (d) kiểm duyệt lại được.

Nội dung truyện hệ không nên có dấu ngoặc nào cả, làm khó hiểu hơn. Nếu tác giả truyện hệ cảm thấy cần phải giải thích thêm cho người khác hiểu thì nội dung truyện hệ quá phức tạp và không dễ cho cha mẹ mình hiểu trong 60 giây.

Trong một cuộc chat, khi nào đề nghị nội dung mới cho bất kỳ một truyện hệ nào thì cũng phải đánh số độc đáo nhận diện nội dung đó nhằm làm dễ việc tham khảo. Ví dụ: th1a, th2b, th3c, v. v. Trong cùng một cuộc chat, không bao giờ sử dụng bất cứ một số nhận diện nào lần thứ hai cho nội dung mới.

Không bao giờ làm truyện hệ con trước khi nắm bắt được lời phê chuẩn của khách hàng về truyện hệ cha. Bằng không thì, nếu khách hàng không đồng ý với nội dung truyện hệ cha thì các truyện hệ con có thể trở thành việc mất công.

Hội Tụ Vào Khách Hàng
Làm cho truyện hệ hội tụ, chú tâm vào khách hàng. Cách dễ nhất để làm việc này là để cho khách hàng phát sinh truyện hệ. Nếu họ không thực hiện được thì bạn phải chơi trò đóng vai khách hàng. Một thí dụ truyện hệ hội tụ vào nhà phát triển là: xây thêm chức năng mới, bản mục lục loại tụm lại, vào cái bảng liệt kê các đơn đặt hàng. Truyện hệ như thế không có nghĩa lý gì nhiều đối với đại đa số các khách hàng, và một khách hàng thực sự (trừ phi họ là một nhà quản trị cơ sở dữ liệu), chắc không bao giờ viết một truyện hệ như vậy. Thay vì vậy, truyện hệ có nội dung như là, cải tiến sức năng phát sinh tường trình đơn mua, diễn đạt được cùng một thông tin, nhưng lại dễ hiểu cho mọi người trong đội ngũ.

Thân Thiện Cho Thang Máy
Một truyện hệ tốt nên là cái gì đó bạn có thể trên một cái thang máy trong vòng độ chừng 30 giây giải thích cho một đội viên khác hiểu, xem Nghệ Thuật Rao Thang Máy (Elevator Pitch). Đừng có viết tiểu thuyết. Nên nhớ, cái này chỉ là một cái giữ chỗ cho các đàm luận đầy chi tiết hơn, không phải là văn kiện định nghĩa hết những đòi hỏi hoặc các đặc điểm kỹ thuật.

Kích Thước Cho Phải Chăng
Không có quá lớn mà cũng không có quá nhỏ, có thể thực hiện được trong vòng 40 giờ lý tưởng (1 tuần lý tưởng) khi ước lượng dụng công. Các truyện nhỏ thường không là một vấn đề, nhưng nếu chúng nhỏ hơn một giờ bạn chắc muốn gom chúng lại thành một loạt. Các sai sót thường là các tuyển viên tốt để cho hàng loạt vào một truyện hệ đơn độc, miễn sao toàn bộ vẫn là nhỏ và dễ thực hiện đầy đủ.

Phải Kiểm Duyệt Lại Được
Một truyện hệ không thử được có lẽ như là, làm cho cái khung có đơn mua dễ dùng. Nghe có vẻ xinh đẹp, nhưng không một ai thực ra biết cái đó có nghĩa là gì, hoặc làm sao để kiểm lại nó một cách khách quan. Một cách diễn đạt tốt hơn có lẽ là như vầy: một người dùng mới tập việc có khả năng triệu hồi thông tin, cho dữ liệu vào, và đệ trình một cái đơn mua không quá 5 phút. À mà nó vẫn còn tỏ ra một chút đáng ngờ, nhưng mình chắc có thể viết một bài định nghĩa cuộc thử nghiệm chức năng đó như thế này: căn cứ vào một nhóm mẫu có 10 người thì hết 8 nên có khả năng hoàn tất một đơn mua một cuốn sách trong vòng 5 phút.

Trước khi Giao tiếp thêm

Thiếu chuyên nghiệp nhất là giao tiếp khách hàng trước khi tiêu hoá toàn bộ tất cả các thông tin sẳn có nhờ khách hàng đã đưa cho từ trước rồi. Có thể thông tin sẳn có chỉ có 5 lời viết và hình ảnh. Không nên coi thường uy lực các đồ hoạ. Một bức minh hoạ có thể gợi ý cho ta viết ra thêm được 10, 20 truyện hệ khác nhau dù có nhiều cái chưa hoàn tất được trước khi giao tiếp thêm với khách hàng.

Trước khi giao tiếp khách hàng nên gom góp lại tất cả các ý kiến sẳn có từ những lời viết cũng như các hình ảnh đã nhận được từ khách hàng rồi cho hết vào một văn kiện định nghĩa yêu sách hệ thống mong muốn, tức là ra một bài viết có danh sách liệt kê bộ truyện hệ tối thiểu dùng để diễn đạt toàn diện hệ thống khách hàng muốn chúng ta thực hiện cho họ. Trước khi giao tiếp khách hàng qua điện thoại hoặc chat nên cho khách hàng có cơ hội điền thêm vào văn kiện những gì chúng ta chưa thể nghĩ ra thêm cho họ được.

Nếu đại diện kinh doanh không có thời gian hoặc không thể viết ra hoàn chỉnh một truyện hệ dựa trên một món thực đơn nào đó trên minh hoạ sẳn có thì nên gợi ý cho khách hàng thấy truyện hệ cần phải làm. Ví dụ, viết dở một truyện hệ như sau:

TH123b. Khi nhấp chuột vào món ABC trên thực đơn đầu trang web XYZ thì cho người dùng chọn một trong những chức năng sau: (a) làm việc này, (b) làm việc kia, (c) đi đâu khác, v. v.

Chuẩn bị thêm một số truyện hệ mới trước khi tiếp tục giao tiếp với khách hàng là một trong những cách tốt nhất nhằm thể hiện sự chuyên nghiệp của một tổ chức chuyên xây và cải tiến các hệ thông tin cho khách hàng.

Dùng Đại Việt Ngữ

Đại Việt Ngữ là ngôn ngữ tiếng Việt tiêu chuẩn dùng để thể hiện hoàn chỉnh nhiều khái niệm tinh vi một cách dễ hiểu cho ngay cả học sinh tiểu học chưa biết ngoại ngữ. Đây là ba mục ví dụ trong từ điển Anh ngữ – Đại Việt Ngữ (ĐVN) trên web ta: chất lát (silicon), chất ống than phần tỉ (carbon nanotube), và chất huyết điệu (serotonin). Nếu chưa có trong từ điển ĐVN thì không nên dùng trong truyện hệ.

Không Nên Nên Dùng Lý Do
định nghĩa không nên sử dụng tiếng Việt ngoài từ điển phổ thông không phải Việt ngữ
sai chính tả, sai văn phạm phải có chính tả, văn phạm tốt thiếu chuyên nghiệp
kích vào nhấp vào dễ hiểu hơn
menu Các món trên thực đơn đầu trang tránh ngoại ngữ
Các nút trên thanh nằm ngang (nói trổng) chuẩn xác hơn
bạn và tôi nếu không quan trọng, không nói; nếu nói, nói nguyên câu một cách chính qui thừa
Lưu ý hoặc dùng ngoặc đơn thực đơn lưu ý và ngoặc đơn làm khó hiểu

 

 

Kế hoạch Chu trình

Một chu trình có thể coi như là một loại quy trình công tác. Các chu trình (iterations) trong văn cảnh một dự án nói về cái kỹ xảo của việc khuếch trương và giao hàng một cách gia tăng các thành phần cho hệ chức năng doanh nghiệp. Điều này hầu hết thường hay liên quan với sự phát triển phần mềm theo phong cách lanh lợi, nhưng có thể tiềm tàng áp dụng được vào bất cứ vật liệu nào khác. Các thành quả của một chu trình đơn độc có thể là các gói hàng nhỏ nhưng hoàn tất của việc làm dự án mà có thể cùng nhau trình diễn vài chức năng doanh nghiệp hữu hình. Thực hiện nhiều chu trình để tạo lập một sản phẩm tích hợp có đầy đủ tất cả các chức năng mong đợi. Cách này thường hay được so sánh với phương sách mô hình thác nước.

Nên gọi một cuộc hội họp nhằm ra kế hoạch chu trình vào lúc ban đầu của từng chu trình để ra kế hoạch cho các công việc lập trình trong chu trình đó. Mỗi chu trình dài từ một đến 3 tuần. Các truyện hệ đã được khách hàng tuyển chọn cho chu trình này từ cái kế hoạch phóng thích trong thứ tự truyện quý giá nhất đối với khách hàng nằm trước hết. Các cuộc trắc nghiệm chấp thuận bị hỏn cần phải được sửa chữa cũng được tuyển. Khách hàng lựa các truyện hệ với ước lượng tổng số lên đến vận tốc dự án từ chu trình vừa rồi.

Các truyện hệ và các cuộc trắc nghiệm đã hỏn được tách ra thành các công việc lập trình mà sẽ ủng hộ chúng. Các công việc được viết xuống thành văn bản vào mấy tấm thiếp như là các truyện hệ. Trong lúc các truyện hệ dùng ngôn ngữ khách hàng, các công việc viết bằng ngôn ngữ của nhà phát triển. Các công việc giống hệt nhau phải dẹp qua. Những tấm thiếp này sẽ là kế hoạch chi tiết cho chu trình đó.

Các nhà phát triển tự nhận làm các công việc và khi đó ước lượng bao lâu họ sẽ hoàn tất các công việc mình. Điều quan trọng là nhà phát triển chấp nhận một việc cũng là người ước lượng bao lâu nó sẽ kết thúc. Không hoán đổi con người được và người mà sẽ làm việc phải ước lượng công việc sẽ tốn bao lâu.

Mỗi việc nên ước lượng dài 1, 2, hoặc 3 ngày lập trình lý tưởng trong thời kỳ đó. Những ngày lập trình lý tưởng là thời gian cần phải có để hoàn tất công việc nếu không bị làm lãng trí. Các công việc ngắn hơn 1 ngày có thể nhập lại thành một nhóm với nhau. Các công việc lâu hơn 3 ngày nên tách ra nhỏ hơn nữa.

Bây giờ vận tốc dự án được dùng để xác định nếu chu trình thiếu giờ cho các việc tuyển hay không. Tổng cộng thời gian ước lượng bằng số ngày lập trình lý tưởng của các công việc, kết quả này phải không có trội hơn vận tốc dự án từ chu trình trước đó. Nếu chu trình này có quá nhiều việc rồi thì khách hàng phải chọn các truyện hệ cần phải đợi đến một chu trình sau (xúc tuyết).

Nếu chu trình có quá ít truyện thì cho thêm truyện khác vào. Vận tốc ngày việc (kế hoạch chu trình) quan trọng hơn vận tốc trong tuần truyện (kế hoạch phóng thích) vì nó đúng đắn hơn.

Người ta thường hay báo động khi thấy các truyện hệ bị xúc tuyết. Đừng có hốt hoảng. Nên nhớ điều quan trọng của việc trắc nghiệm đơn vị và tái hệ số (refactoring). Một món nợ trong những khu vực này sẽ làm chậm việc. Tránh cho thêm vào bất cứ hệ chức năng nào trước khi có thời biểu. Chỉ cho vào cái gì mà bạn cần cho hôm nay mà thôi. Đem gì ngoại đạo vào sẽ làm chậm việc.

Đừng bị cám dỗ vào thay đổi ước lượng việc và truyện mình. Quá trình ra kế hoạch dựa vào thực tại lạnh lùng của ước lượng kiên định, làm giả dối để cho thấy thấp hơn một chút tạo nhiều vấn đề hơn.

Giữ một con mắt trên vận tốc dự án và việc xúc tuyết. Có thể cần phải tái ước lượng tất cả cái các truyện và tái đàm phán kế hoạch phóng thích mỗi ba đến năm chu trình, là việc bình thường. Miễn sao luôn trước hết thực hiện đầy đủ các truyện hệ quý giá nhất thì sẽ luôn làm càng nhiều càng tốt các việc khả thi cho đám khách hàng và ban quản lý của mình.

Một phong cách phát triển theo chu trình có thể đem sự lanh lợi vào quá trinh phát triển của mình. Chỉ cần ra kế hoạch kịp thời bằng cách không ra kế hoạch các công việc lập trình đặc biệt sớm hơn dự liệu của chu trình đương thời.

One comment on “Cách soạn thảo Truyện hệ

  1. Pingback: Mục lục Tập truyện Hành trình Tony Minh « Tô Mỳ Minh Duy (CTTMMD)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Information

This entry was posted on 04-12-2012 by in Minh Duy.
%d bloggers like this: