Thực tế là chúng ta không được học cách phát triển phần mềm chất lượng cao
(florianbellmann.com)- Nhiều dự án trì hoãn các biện pháp QA đến phía sau rồi phụ thuộc vào một đợt QA sprint lớn ngay trước khi phát hành, và lặp lại cùng một sự hỗn loạn ở chu kỳ tiếp theo
- Giáo dục khoa học máy tính dành thời gian cho thuật toán, ngôn ngữ và quản lý dự án, nhưng trong nhiều trường hợp không xử lý đảm bảo chất lượng phần mềm ở mức độ thực tiễn
- Trong công ty, khi thiếu ngân sách, chậm phát triển hoặc phạm vi tăng lên, QA là phần bị cắt giảm đầu tiên, và phần mềm mong manh chỉ qua mức kiểm thử tối thiểu, không có cấu trúc vẫn được triển khai
- Để thuyết phục về QA, thay vì những cách diễn đạt trừu tượng như “ổn định hơn”, cần nói về chi phí của việc không làm dưới dạng chi phí phát triển tăng hoặc thời gian ổn định bản phát hành kéo dài
- Thay vì xây toàn bộ hệ thống chất lượng cùng lúc, cách thực tế hơn là bảo vệ chức năng cốt lõi gắn trực tiếp với giá trị khách hàng trước, và viết test cho tính năng mới ngay tại thời điểm triển khai
QA bị đẩy lùi đến sát ngày phát hành
- Ở nhiều dự án, quá trình phát triển vẫn diễn ra dù thiếu các biện pháp đảm bảo chất lượng quan trọng
- Dù biết là cần thiết, việc thực hiện thực tế trong nhiều trường hợp lại bị dồn vào một đợt QA sprint lớn ngay trước khi phát hành
- Cách làm này làm tăng căng thẳng và cuối cùng chỉ đưa phần mềm đến mức vừa đủ để chạy
- Ở chu kỳ phát hành tiếp theo, cùng một sự hỗn loạn lại lặp lại và khó dẫn đến cải thiện có cấu trúc
Khoảng trống chất lượng giữa giáo dục và thực tiễn
- Chương trình khoa học máy tính chủ yếu tập trung vào thuật toán, nguyên lý hoạt động của máy tính, lịch sử và khái niệm của ngôn ngữ
- Có thể có học kỳ dạy về phương pháp quản lý dự án hoặc Scrum, nhưng QA đôi khi bị bỏ qua hoàn toàn
- Hơn 90% sinh viên tốt nghiệp sẽ làm việc trong bối cảnh công ty, vì vậy họ cần khả năng bàn giao phần mềm không lỗi trong thời gian đã định
- Việc xem nhẹ QA trong giáo dục không phù hợp với yêu cầu thực tế của công việc
Cấu trúc khiến QA bị cắt giảm đầu tiên trong công ty
- Khi dự án gặp vấn đề ngân sách, tiêu chuẩn và biện pháp QA thường là phần bị loại bỏ đầu tiên
- QA thường được bố trí ở cuối dự án, nên khi thời gian phát triển kéo dài hoặc scope tăng lên thì không còn đủ thời gian để đảm bảo chất lượng
- Kết quả là chỉ thực hiện mức kiểm thử tối thiểu, không có cấu trúc rồi triển khai phần mềm với cấu trúc mong manh
- Một số đội có tiêu chuẩn QA, nhưng thường là theo cách thành viên senior ép phần còn lại của nhóm phải tuân theo
- Ngay cả khi có tiêu chuẩn, nếu nhóm viết test chỉ để đạt các chỉ số quản lý dự án thì cũng khó dẫn đến đảm bảo chất lượng đầy đủ
Bước đầu tiên để chấm dứt các vấn đề chất lượng lặp đi lặp lại
- Để chỉ ra rằng các biện pháp QA đang bị thiếu cần có kinh nghiệm và sự tự tin
- Giai đoạn crunch trước phát hành, hệ thống production gặp sự cố, và việc thiếu monitoring cuối cùng đều trở thành gánh nặng cho cả nhóm
- Những cải thiện không hiện ra trực tiếp trước mắt quản lý như refactoring vốn đã khó thuyết phục, và QA có thể còn mơ hồ hơn nếu chưa từng làm đúng cách
- Cần lặp đi lặp lại việc nêu vấn đề và khơi lại thảo luận thì mới tạo được bước khởi đầu
Giải thích QA bằng ngôn ngữ của tiền
- Những câu như “phần mềm sẽ ổn định hơn” hay “dễ bảo trì hơn” khó tạo cảm giác cụ thể với những người không làm việc trực tiếp trên codebase
- Developer cần nói về chi phí của việc không làm QA
- Một số cách diễn đạt ví dụ như sau
- Nếu không làm ngay bây giờ, sau 4 tháng nỗ lực phát triển và chi phí sẽ tăng 15%
- Nếu không thêm unit test cho mọi tính năng, giai đoạn ổn định bản phát hành sẽ kéo dài hơn mỗi lần
- Càng có nhiều tính năng mới, càng phải test thủ công tác dụng phụ mỗi lần, nên tiến độ sẽ giảm dần qua từng bản phát hành
- Đây là kiểu ngôn ngữ dễ truyền đạt hơn với business và quản lý
- Cuối cùng, các biện pháp QA có thể giúp cuộc sống của cả developer lẫn quản lý tốt hơn
Bắt đầu với dung lượng hiệu quả tối thiểu
- Nếu thiết kế QA như một khoản đầu tư ban đầu quá lớn, nó sẽ cản trở tiến độ dự án và khó nhận được sự đồng thuận từ các bên liên quan
- Điểm khởi đầu thực tế là tìm ra phần quan trọng nhất của ứng dụng
- Thường sẽ có một use case, tính năng hoặc hành vi cốt lõi mà toàn bộ ứng dụng phụ thuộc vào
- Cần test trước chức năng cốt lõi là phần bắt buộc phải hoạt động đúng để mang lại giá trị cho khách hàng
- Dung lượng hiệu quả tối thiểu (MED) là dung lượng nhỏ nhất tạo ra kết quả mong muốn
- Trong QA, MED có thể là một trong các lựa chọn sau
- Kế hoạch test thủ công
- Test tự động trong pipeline
- Hoặc các biện pháp khác để đảm bảo hành vi cốt lõi
- Sau khi đảm bảo được chức năng cốt lõi, có thể mở rộng độ ổn định dần dần
- Với mỗi tính năng mới, nên thêm unit test và cũng cần xác thực cả những thông tin không thể kiểm soát như API bên ngoài hoặc đầu vào từ người dùng
- QA cũng cần được cải thiện theo hướng lặp lại và tăng dần
Những câu hỏi QA cần kiểm tra ở một dự án mới
- Khi bắt đầu hoặc tham gia một dự án mới, cần xác nhận xem có khái niệm QA nào đó dù ở mức nhỏ hay không
- Nhóm nên suy nghĩ về các câu hỏi sau
- Chúng ta đang phát hành cái gì
- Điều gì bắt buộc phải hoạt động
- Chúng ta đảm bảo điều đó như thế nào
- Chúng ta cố ý không làm những biện pháp nào, và lý do là gì
- Nếu ghi lại những nội dung này thành tài liệu và bổ sung kế hoạch test, đó sẽ là nền tảng tốt để phần mềm tiếp tục phát triển
- Cách tiếp cận đã chọn nên được rà soát định kỳ, ví dụ theo từng quý
Viết test cùng lúc với triển khai
- Ngay cả khi không dùng TDD, vẫn nên viết test trong lúc phát triển phần mềm
- Thời điểm triển khai tính năng chính là thời điểm tốt để viết test
- Khi viết test đồng thời với triển khai, cấu trúc code sẽ buộc phải trở nên thực sự có thể test được
- Nếu gắn test vào phần mềm hiện có về sau, thường sẽ lộ ra rằng code phụ thuộc lẫn nhau quá mức hoặc đã vi phạm nguyên tắc trách nhiệm đơn nhất
- Test là lời giải thích rằng bạn đã hiểu hành vi mong muốn và đã xác nhận nó hoạt động như kỳ vọng, đồng thời cũng hoạt động như một dạng tài liệu của code
Tác động quay trở lại với dự án và cá nhân
- Nếu chủ động nêu ra thảo luận về chất lượng và đề xuất các giải pháp khả thi, xung quanh sẽ thấy rằng bạn thực sự quan tâm đến dự án
- Thảo luận về chất lượng có thể mở rộng phạm vi ảnh hưởng của bạn với tư cách developer
- Chất lượng cuộc sống của developer và quản lý cũng có thể được cải thiện
- Dự án có thể tăng trưởng với tốc độ lành mạnh khi có các biện pháp QA
- Không phải ai cũng cần trở thành đại sứ QA, nhưng có thể bắt đầu từ MED nhỏ và cho cả nhóm thấy một cách làm tốt hơn
1 bình luận
Các ý kiến trên Hacker News
Những nội dung như vậy đang được giảng dạy. Chỉ là chúng không nằm trong các môn khoa học máy tính cốt lõi, mà thường ở các môn tự chọn như kỹ nghệ phần mềm.
CMU thậm chí có cả chương trình thạc sĩ và tiến sĩ về kỹ nghệ phần mềm, bao phủ những gì bài blog nói đến và còn hơn thế nữa. Có một khoảng cách lớn giữa CS và SE, nhưng không đến mức “không ai dạy cách tạo ra phần mềm chất lượng cao”.
Trớ trêu là khi còn là sinh viên, tôi ghét nhất các môn kỹ nghệ phần mềm. Môn design pattern tuân thủ UML nghiêm ngặt trông có vẻ lỗi thời, còn môn QA dạy TDD và công cụ trong hệ sinh thái Java thì cũng nhàm chán. Vài năm sau, khi tôi tham gia một đội xây dựng workflow kiểm thử và công cụ cho phần mềm có yêu cầu bảo mật cao, đồng nghiệp đã ngạc nhiên vì tôi đã biết sẵn những việc cần làm.
Ngay cả khi có dạy, thường nội dung cũng lỗi thời hoặc nghiêng về những thứ rất sát nghĩa như viết ứng dụng web. Nếu từng có một môn tập trung vào triển khai, làm việc nhóm và xây dựng hệ thống phức tạp, tôi thật sự đã rất muốn học.
Không nên để những nội dung này là môn tự chọn hoặc chương trình thạc sĩ; cần có chương trình kỹ nghệ phần mềm bậc cử nhân, và 90% sinh viên CS nên chuyển sang hướng đó.
Codebase là một dịch vụ đơn giản cung cấp quét virus/malware, và được thiết kế để luôn có thêm việc phải làm, bao gồm scanner và signature. Đó là ý tưởng từ hơn 15 năm trước, nhưng nó có thể đã trở thành một môn học tuyệt vời được duy trì liên tục; thật tiếc là không thuyết phục được khoa.
Dù không hẳn là môn học định hình toàn bộ thời đại học của tôi, nhưng cũng khá gần như vậy; và việc phần lớn những người thiết kế hệ thống lại không biết những nội dung này khiến tôi vừa phẫn nộ vừa thấy sợ hãi mang tính hiện sinh.
Lý do làm việc với những người có bằng CS dễ hơn là ít phải thuyết phục họ về nhu cầu của thuật toán tốt, hoặc rằng không nên tự triển khai parser hay mật mã.
Ngược lại, trong kỹ nghệ phần mềm, không có bằng cấp nào đủ đáng tin để cho thấy sự ngây thơ về chất lượng, làm việc nhóm và hợp tác với các đội khác đã được mài giũa tương tự. Có những người được tôi luyện bằng kinh nghiệm nhanh chóng viết ra mã chưa kiểm chứng tệ hại rồi rời đi trước khi vấn đề nổ ra; ban lãnh đạo thích những người như vậy và coi thường những người ở lại dọn đống đổ nát.
Các giao thức dựa trên chuỗi có dấu phân cách rõ ràng thường rất dễ parse, và tùy use case có thể chỉ cần xử lý một phần. Tất nhiên vẫn phải cân nhắc kiểm thử và yêu cầu tính năng. Nếu đang tạo ra một ngôn ngữ thì lời khuyên có thể khác.
Người mới thì tự làm; lập trình viên trung cấp và dự án quy mô vừa dùng parser generator; còn những người duy trì các parser tinh vi nhất cũng chuộng tự viết. GCC trước đây từng dùng parser bison, nhưng đã chuyển sang parser recursive descent viết tay để có thông báo lỗi tốt hơn, và Clang cũng dùng recursive descent.
Ngoại lệ mà cá nhân tôi biết chỉ có jq, và vì vậy trong phần triển khai jq, việc tạo thông báo lỗi cú pháp hữu ích là khó.
Viết parser có thể đơn giản đến mức nằm gọn trong một bài tập, và mã parser viết tay rốt cuộc trông giống ngữ pháp LL. Parsing là phần dễ nhất trong việc viết compiler hoặc công cụ ngôn ngữ, nên nếu một parser viết tay là tiêu chuẩn quá cao đối với đội thì cả dự án có thể đáng nghi. Tôi không nói là tuyệt đối không dùng parser generator, nhưng tôi muốn làm việc trong một dự án có parser viết tay được kiểm thử tốt hơn là một dự án làm build phức tạp thêm bằng công cụ bổ sung hoặc dùng các công cụ cũ như Bison/ANTLR.
Dù vậy, tiêu chuẩn chung có vẻ đã cao hơn 20 năm trước. Ví dụ, quản lý mã nguồn, unit test và CI/CD không còn là những thứ gây tranh cãi nữa.
Tiền đề “phải cung cấp phần mềm không có bug đúng hạn” là một điểm khởi đầu khá tệ cho một bài viết về phần mềm chất lượng
Nếu bạn tin rằng mình có thể triển khai code không có bug, đã đến lúc đổi nghề
Dù đã làm đủ unit test, integration test và user acceptance test, một thay đổi code vẫn đồng nghĩa với khả năng có bug mới. Khi một lập trình viên nói “tôi tuyệt đối không deploy code có bug”, người ta sẽ muốn hỏi kỹ hơn ý đó là gì
Khi đã vượt qua các mức “đã viết hàm”, “đã test hàm”, “đã test cả hàm được gọi qua mạng”, bạn sẽ nhận ra rằng dù bắt edge case tốt đến đâu và QA kỹ đến đâu, trên một cấu hình cụ thể, phần cứng cụ thể, kernel cụ thể nào đó vẫn luôn còn hành vi không xác định kiểu 0-day. Ta chỉ có thể nói rằng vì đã qua test, mắt người và review nên gần như bảo đảm ít bug, rồi cuối cùng cũng chỉ còn biết cầu may
Nếu mất một tuần để sửa nhưng chỉ một số ít người dùng gặp trong tình huống rất hiếm, có thể không cần sửa
Có các chương trình khoa học máy tính, và cũng có các trường đại học nhấn mạnh thực tập và thực hành. Nhưng khoa CS ở nhiều trường đại học xuất phát từ khoa toán nên thiên về lý thuyết
Tôi nghĩ điều đó vẫn ổn, cũng như hóa học không phải là kỹ thuật hóa học. Đại học không chỉ là trường dạy nghề; mục đích của gần như mọi bằng cấp là rèn luyện tư duy và chứng minh năng lực tiếp thu nội dung phức tạp
Một nền giáo dục đại học thuần túy không xét đến tính hữu dụng trong thực tế là có hại cho giáo dục, nhưng đào tạo nghề thuần túy chỉ dạy cách làm mà không dạy sự thấu hiểu cũng không hữu ích. Dù vậy, các trường nghề thực tế cũng không hoàn toàn như thế; họ thường vẫn đem lại hiểu biết sâu về những thứ quan trọng, dù có thể bỏ qua các phần khó
Dù sao thì đó vẫn là cách tốt để nhìn thoáng qua thế giới phần mềm chuyên nghiệp
Những điều này được học trong tổ chức phát triển tốt. Khoảng 10–15 năm trước thì đại khái là FAANG, còn hiện nay những nơi như TailScale là ví dụ
Hoàn toàn có thể không chất đống những microservice vô ích và nhiều lớp Docker, các tầng serialize/deserialize JSON, cả đống unit test chỉ để lấy coverage trong khi phớt lờ QuickCheck, Hypothesis và fuzzing. Hoàn toàn có thể làm các bó thay đổi dạng stacked, luân phiên on-call trong chính đội viết code, giảm thiểu lỗi do liên kết động và dependency không được ép buộc, thiết kế phù hợp với runtime của ngôn ngữ quản lý, và yêu cầu cú pháp văn xuôi dễ đọc của ngôn ngữ như một tiêu chí “dễ đọc”. Dù liên tục bị phớt lờ, cách triển khai phần mềm chất lượng là tri thức công khai
Có thể người viết có suy nghĩ về phần mềm chất lượng, nhưng bình luận này khó hiểu
Cần nhìn vào điều gì, và có sách hay khóa học nào đáng khuyến nghị không
Rất khó đạt được các chỉ số đo lường đủ hợp lệ để hậu thuẫn cho những tuyên bố kiểu “nếu không làm bây giờ, sau 4 tháng nỗ lực và chi phí phát triển sẽ tăng 15%”
Có lần ở một startup, hai nhà sáng lập nói “đừng viết unit test”. Tôi không tranh luận, và hiểu ý thật sự của câu đó là chúng tôi quá chậm nên hãy deploy nhanh nhất có thể. Tôi đã deploy nhanh, vẫn giữ chất lượng, và cũng viết unit test. Họ không cần biết; họ chỉ cần kết quả. Trọng tâm ẩn của các cuộc thảo luận kiểu này là phần lớn tổ chức phần mềm không biết cách vừa nhanh vừa triển khai có chất lượng. Không có công thức ma thuật; cần tay nghề cá nhân, và đây cũng là môn thể thao đồng đội. Tình huống mỗi nơi mỗi khác, nên một quy trình nhẹ có thể hữu dụng phần nào, nhưng hiệu quả có giới hạn. Cuối cùng cần một đội tốt, có kinh nghiệm, giá trị quan đúng đắn và sự khôn ngoan tập trung vào việc chuyển giao giá trị
Tiền đề rằng đại học dạy cách làm phần mềm trong ngành là một tuyên bố khá táo bạo
Hơn nữa bài này trông giống một bài từ thập niên 90, thời phần mềm còn được phân phối bằng CD hoặc đĩa mềm. Ngày nay, do các pipeline triển khai liên tục, khái niệm “release” trong nhiều trường hợp đã trở nên mờ nhạt, và điều đó được xem là một thực hành tốt. Trong bối cảnh đó, việc một bộ phận QA bảo đảm thủ công rằng bản release không có bug trông khá lỗi thời
Cũng có những người viết code được đưa lên các thiết bị không dễ nâng cấp
Nếu cần sự phê duyệt của ai đó, bạn phải giải thích cho người đó vì sao đó là ý tưởng tốt
Những câu như “ổn định hơn” hay “dễ bảo trì hơn” không chạm tới người không trực tiếp làm việc trên codebase. Lập trình viên cần nói bằng chi phí khi không làm QA, tức là bằng ngôn ngữ của tiền bạc. Dù “nhưng đây mới là cách đúng mà!” có vẻ như một lập luận không thể phản bác, người phê duyệt có thể không quan tâm đến tính đúng đắn đó. Nguyên lý này áp dụng không chỉ cho việc sửa phần mềm cho đúng, mà còn cho gần như mọi việc ở nơi làm việc
Nếu bạn phải giải thích vì sao chất lượng quan trọng, thì họ ít nhất cũng thiếu hiểu biết ngang bạn, thậm chí có thể hơn. Những tổ chức như vậy phải chấp nhận số phận của mình. Ngược lại, ở các công ty trưởng thành, bạn được tưởng thưởng nhiều hơn và nhanh hơn, đồng thời cũng phát triển nhanh hơn cảm giác về cách một doanh nghiệp nên vận hành. Tất nhiên, bạn phải tự chứng minh lời hứa rằng thời gian bỏ ra sẽ dẫn tới cải thiện thực sự, và đó không được là một xung động kiểu Don Quixote của dân nghiệp dư
Trong số chất lượng, thời gian ngắn, độ phức tạp giao tiếp thấp và ít tiền, về cơ bản bạn chỉ có thể có khoảng ba yếu tố; trong đó thời gian gần như là biến phụ thuộc
Mọi người cố áp dụng các quy trình và cấu trúc kiểu nhà máy vào phần mềm, vốn là một môn thể thao đồng đội đồng thời là một lĩnh vực kỹ thuật. Giống như ta không dạy hay xây dựng một đội bóng rổ bằng cách chia nhỏ thành các thủ tục và checklist theo từng giai đoạn tấn công, cần giảm thiểu giao tiếp và khiến cả đội di chuyển như một thể thống nhất. Đây không phải là việc xây dựng quy trình, mà là xây dựng đội ngũ và từng cá nhân. Hãy lập kế hoạch, nhưng như Moltke nói, không có kế hoạch tác chiến nào còn chắc chắn sau lần tiếp xúc đầu tiên với kẻ địch. Thế nhưng tư duy kinh doanh lại tin rằng vì kế hoạch không diễn ra như dự kiến nên phải thêm nhiều quy trình hơn, và đến lần thất bại tiếp theo thì nhà quản lý có thể đổ lỗi cho cá nhân. Quy trình có vai trò trong việc bảo đảm công việc diễn ra trong khuôn khổ pháp lý và đạo đức, cũng như giảm các điều kiện bất lợi như vô tình đặt cược toàn bộ tiền của quỹ phòng hộ trong lúc thử nghiệm. Nhưng ở hầu hết startup và doanh nghiệp, quy trình được dùng theo cách không đặt đội ngũ làm trung tâm
Ta không hét vào mặt một kiến trúc sư truyền thống để hỏi khi nào xong. Thường thì nó kết thúc khi khách hàng hài lòng hoặc đưa ra quyết định. Nhiều công việc phát triển cũng tương tự như vậy
Tôi nghi ngờ liệu có hoạt động nào của con người dạy thành công thuộc tính gọi là chất lượng hay không
Theo kinh nghiệm, khả năng tạo ra thứ gì đó có chất lượng chỉ có được nhờ luyện tập, luyện tập và luyện tập
Ngược lại, tiêu đề chỉ có nghĩa là lập trình không phải là một thực hành công nghiệp. Với những ai đã chú ý quan sát thì điều này hẳn phải hiển nhiên, nhưng một số người nhất quyết không chịu nhìn đến cùng
Chỉ nhìn vào viết lách thôi cũng thấy nhiều người học được cách nâng cao chất lượng. Đó là hướng dẫn họ nên thử viết gì, và quan trọng hơn là hướng dẫn họ cách nhìn lại chất lượng của bài vừa viết và cải thiện nó
Luyện tập luôn có ích, nhưng chất lượng cũng là thứ mà nhiều người học và rèn được
Khi học bay, ta học các tiêu chuẩn, nhưng theo thời gian ta được dạy phải thu hẹp biên độ cho phép. Ví dụ, nếu tiêu chuẩn độ cao khi vòng gấp là ±100 feet thì đó chỉ là mức tối thiểu; mục tiêu phải là 50 feet, 20 feet, thậm chí là đến mức kim gần như không nhúc nhích. Mục tiêu là “tốt hơn, luôn tốt hơn, mình có thể làm gì tốt hơn nữa?”, và trong bay, bạn chỉ đạt khi mọi hạng mục đều đạt yêu cầu chứ không phải dựa trên mức trung bình tổng thể. Về mặt văn hóa, “đạt yêu cầu” không phải là điểm kết thúc mà là điểm bắt đầu
Tôi cảm thấy thái độ này tạo ra một mô hình hợp tác hơn rất nhiều. Trong hàng không, mọi người thật lòng muốn tất cả cùng thành công, và nếu ai đó thất bại thì bản thân mình cũng có một phần trách nhiệm. Khi mắc lỗi, văn hóa ở đó là phải tìm cách giảm khả năng mắc lỗi trong tương lai; ở các hãng hàng không, chương trình Bảo đảm chất lượng khai thác bay (FOQA) cũng đóng vai trò lớn. Ở các tổ chức khai thác nhỏ tại vùng hẻo lánh thì điều này không chính thức hơn, nhưng phần lớn gần với văn hóa “không đổ lỗi”, và trọng tâm là “làm thế nào để tốt hơn?”
Chất lượng, ra quyết định và “làm điều đúng” là cốt lõi của văn hóa hàng không. Với một đơn vị vận hành có uy tín, nếu đánh giá rằng thời tiết quá xấu để có thể thực hiện an toàn thì điều đó đồng nghĩa với việc dừng khai thác, chứ không cố cất cánh chỉ để hoàn thành việc. Ngành công nghệ mà tôi mới bước vào lại có cảm giác ngược hẳn. Bản thân khái niệm sản phẩm khả dụng tối thiểu đã cho thấy vấn đề. Nó không nên là “khả dụng tối thiểu”, mà phải là “sản phẩm có chất lượng tối thiểu có thể chấp nhận làm điểm xuất phát”. Không nên lấy mức tối thiểu làm mục tiêu; mức tối thiểu chỉ là điểm bắt đầu
Nếu chỉ luyện tập tạo ra rác, bạn chỉ trở nên giỏi trong việc tạo ra rác. Thực tế cũng có những người không quan tâm đến chất lượng, và trong trường hợp đó thì toàn bộ tiền đề sụp đổ