1% cuối cùng của mỗi dự án GitHub: Niêm phong nó đúng các...

Mục lục

Giới thiệu

Bạn đang ngồi ở bàn làm việc đầy phấn khích, thiếu ngủ nhưng vẫn thực sự hạnh phúc.

Sau nhiều tuần, thậm chí có thể là nhiều tháng miệt mài, cuối cùng bạn cũng đã sẵn sàng giới thiệu dự án của mình với thế giới hoặc nhóm của mình.

Đây chính là khoảnh khắc mà bạn đã chờ đợi bấy lâu nay.
Đã đến lúc xuất bản, chia sẻ và cảm thấy tự hào về những gì bạn đã xây dựng.

Nhưng hãy chờ đã trên

Có thể bạn vẫn chưa hoàn thành.

Có 1% cuối cùng bạn cần quan tâm trước khi nghĩ đến việc kết thúc mọi thứ - phần mà bạn thực sự đóng dấu dự án của mình.

Bởi vì "xong" thường chỉ có nghĩa là mã hoạt động.

❓ Nhưng nó đã được phiên bản chưa?
❓ Người khác có thể hiểu được không?
❓ Triển khai có an toàn không?
❓ Liệu bản thân tương lai của bạn có thể quay lại với nó mà không đau đớn?

1% cuối cùng đó không phải là viết thêm mã.
Đó là việc chuẩn bị cho dự án của bạn sẵn sàng cho thế giới thực.

Và đó chính xác là điều mà hầu hết các nhà phát triển đều bỏ qua.

Việc “đóng dấu” một dự án có ý nghĩa gì?

Tôi gọi nó là vậy nhưng nó không thực sự nói về toàn bộ kho lưu trữ. Đó là về từng phiên bản sản phẩm của bạn.

Mỗi khi bạn phát hành một thứ gì đó, bạn không chỉ vận chuyển mã mà còn vận chuyển một đơn vị hoàn chỉnh. Một phiên bản phải tự đứng vững: có thể triển khai, thử nghiệm và có đầy đủ chức năng.

Nhưng đó chỉ là thông tin cơ bản.

Phiên bản được "niêm phong" đúng cách cũng là:

Được ghi chép đầy đủ
Phiên bản rõ ràng
Được đóng gói đúng cách
Dễ hiểu và dễ sử dụng
Trình bày theo cách mà những người khác (hoặc bản thân bạn trong tương lai) có thể tin tưởng

Bạn cần phải xem qua một danh sách kiểm tra được xác định rõ ràng trước khi có thể coi là xong. Chúng ta hãy đi qua từng cái một.

Danh sách kiểm tra phát hành

Đây không phải là danh sách chính xác, đây là cách tiếp cận của cá nhân tôi. Bạn có thể thấy nó hữu ích nhưng mỗi người đều có cách riêng để hoàn thiện dự án hoặc kho lưu trữ một cách hợp lý.

ĐỌC TÔI

Ồ, phải không?

Nghe có vẻ hiển nhiên nhưng bạn sẽ ngạc nhiên khi biết bao nhiêu kho lưu trữ hoàn toàn không có README hoặc có một kho lưu trữ hầu như không nói gì hữu ích.

README của bạn phải là điểm truy cập chính vào dự án của bạn.
Nếu ai đó không thể hiểu, thiết lập hoặc sử dụng dự án của bạn từ dự án đó mà không gặp rắc rối nào thì điều đó là chưa đủ.

README vững chắc sẽ trả lời được các câu hỏi cơ bản:

❓ Dự án này là gì?
❓ Tại sao nó tồn tại?
❓ Làm cách nào để chạy nó?
❓ Làm cách nào để sử dụng nó?

Và nhiều câu hỏi quan trọng khác.

Tôi sẽ viết một bài viết riêng về cách tạo một README hiệu quả và thực sự hữu ích vì nó xứng đáng được chú ý ở mức độ đó.

Nhưng hiện tại, chỉ cần nhớ điều này:
README không bao giờ là tùy chọn, đây là một trong những phần thiết yếu nhất trong dự án.

Phần "Giới thiệu"

Phần Giới thiệu là một trong những phần quan trọng nhất của kho lưu trữ. Nó cung cấp cái nhìn tổng quan nhanh chóng, cấp cao về dự án và giúp người khác dễ dàng hiểu ngay nội dung của dự án hơn.

Nó có thể bao gồm mô tả ngắn gọn về kho lưu trữ, bản demo hoặc liên kết trực tiếp và các tài nguyên truy cập nhanh khác như tài liệu hoặc trang web. Nó cũng hiển thị siêu dữ liệu chính của kho lưu trữ như sao, nhánh và người theo dõi, cung cấp bối cảnh tức thì về mức độ phổ biến và hoạt động của dự án.

Ngoài ra, phần Giới thiệu cho phép bạn bật hoặc tắt các tính năng khác nhau của kho lưu trữ và các thành phần hiển thị, giúp bạn kiểm soát thông tin nào được đánh dấu trên trang kho lưu trữ.

Một trong những điều tuyệt vời nhất tính năng mạnh mẽ là thẻ (chủ đề). Thẻ cải thiện khả năng tìm kiếm và khám phá bằng cách giúp kho lưu trữ của bạn xuất hiện trong các tìm kiếm có liên quan và duyệt dựa trên chủ đề. Họ cũng cung cấp thông tin nhanh về nhóm công nghệ và miền dự án của bạn.

Khi được sử dụng đúng cách, phần Giới thiệu sẽ trở thành một "bảng điều khiển" nhỏ gọn giúp nhận dạng, hiển thị và phát hiện kho lưu trữ của bạn.

Vệ sinh chi nhánh

Khi viết mã, bạn thường tạo một số nhánh tạm thời như feature, sửa lỗi, tài liệu, refactor, v.v.

Một số nhà phát triển duy trì kỷ luật và dọn dẹp chúng ngay sau khi chúng được sáp nhập vào các nhánh cố định như main, develop hoặc release. Tuy nhiên, những người khác lại bỏ chúng lại, nơi chúng dần dần tích lũy trong kho lưu trữ mà không có mục đích thực sự nào.

Điều đó không để lại ấn tượng tốt cho người khám phá dự án của bạn hoặc đang cân nhắc đóng góp. Nó giống như việc bạn bước vào nhà một ai đó và nhìn thấy những lon nước ngọt rỗng, hộp bánh pizza và giấy gói đồ ăn nhẹ hết hạn, rỗng nằm rải rác khắp phòng khách và nhà bếp, bạn ngay lập tức cảm thấy rằng mọi thứ không được bảo quản đúng cách.

Quan trọng hơn, theo thời gian, nó tạo ra sự nhầm lẫn trong nội bộ. Cuối cùng bạn sẽ tự hỏi: "Chúng ta có còn cần chi nhánh này không? Tại sao nó vẫn ở đây?" Trong nhiều trường hợp, nó chỉ bị quên chứ không cố ý giữ lại.

Giữ danh sách nhánh của bạn sạch sẽ là một thói quen nhỏ nhưng nó giúp cải thiện sự rõ ràng, giảm tải nhận thức và giúp việc bảo trì kho lưu trữ về lâu dài dễ dàng hơn nhiều.

Sau khi công việc phát triển hoàn tất và sáp nhập, hãy tạo thói quen loại bỏ các nhánh tạm thời và chỉ giữ lại những nhánh tồn tại lâu dài như chính, phát triển và phát hành (không giới hạn ở ba nhánh này, có thể có nhiều nhánh hơn).

Một kho lưu trữ sạch không chỉ liên quan đến mã mà còn liên quan đến kỷ luật và sự rõ ràng.

Thẻ phát hành

Thẻ phát hành là một trong những phần quan trọng nhất nhưng thường bị bỏ qua trong quá trình niêm phong đúng cách một dự án.

Thẻ đánh dấu một điểm cụ thể trong lịch sử kho lưu trữ của bạn dưới dạng phiên bản có ý nghĩa, chẳng hạn như v1.0.1, v1.2.3 hoặc v2.0.0. Không giống như các nhánh, thẻ là bất biến - chúng trỏ vĩnh viễn đến một cam kết cụ thể. Điều này khiến chúng trở nên lý tưởng để thể hiện các bản phát hành chính thức.

Không có thẻ, việc theo dõi phiên bản nào đã được triển khai, so sánh các thay đổi giữa các bản phát hành hoặc khôi phục một cách đáng tin cậy nếu có sự cố sẽ trở nên khó khăn hơn. Với việc gắn thẻ phiên bản phù hợp, mọi bản phát hành đều trở thành ảnh chụp nhanh rõ ràng và có thể tái tạo về dự án của bạn.

Hầu hết các nhóm tuân theo cách tạo phiên bản ngữ nghĩa (MAJOR.MINOR.PATCH), cách này truyền đạt bản chất của các thay đổi:

CHỦ YẾU: những thay đổi đáng chú ý
NHỎ: tính năng mới, tương thích ngược
VÁ: lỗi sửa lỗi

Trong quy trình làm việc của riêng mình, đôi khi tôi tiến thêm một bước nữa. Bên cạnh thẻ phát hành như 1.0.1, tôi cũng tạo một nhánh tương ứng như release/1.0.1. Tôi coi nó như một điểm tham chiếu bất biến phản ánh cam kết được gắn thẻ.

Đây là cách tiếp cận của cá nhân tôi và không phải là cách duy nhất để xử lý các bản phát hành. Nhiều nhà phát triển hoặc nhóm chỉ dựa vào thẻ, trong khi những người khác sử dụng các nhánh phát hành để ổn định, quy trình làm việc CI/CD hoặc bảo trì dài hạn.

Thẻ thường là đủ, nhưng trong một số quy trình công việc nhất định, việc kết hợp chúng với các nhánh phát hành có thể tăng thêm tính linh hoạt và rõ ràng.

Tóm lại, thẻ phát hành mang lại cho bạn một tham chiếu ổn định. Cách bạn cấu trúc xung quanh nó tùy thuộc vào quy trình làm việc của bạn và tùy chọn nhóm.

Bộ quy tắc nhánh và thẻ

GitHub cung cấp các bộ quy tắc (trong cài đặt kho lưu trữ → quy tắc) cho phép bạn xác định và thực thi các chính sách cho cả nhánh và thẻ. Đây là phần quan trọng nhưng thường bị bỏ qua trong quá trình "niêm phong" dự án đúng cách.

Bộ quy tắc cho phép bạn kiểm soát những gì được phép và những gì bị hạn chế trong kho lưu trữ của mình. Đối với các nhánh, bạn có thể thực thi những việc như yêu cầu yêu cầu kéo trước khi hợp nhất, yêu cầu kiểm tra trạng thái để vượt qua, chặn đẩy lực và hạn chế cam kết trực tiếp đối với các nhánh quan trọng như main, develop hoặc release/*.

Đối với thẻ, bộ quy tắc cũng quan trọng không kém. Bạn có thể kiểm soát ai được phép tạo hoặc sửa đổi thẻ, thực thi các mẫu đặt tên (chẳng hạn như cách đặt phiên bản ngữ nghĩa như v1.2.3) và ngăn việc tạo các bản phát hành vô tình hoặc trái phép.

Các bộ quy tắc nhánh và thẻ cùng nhau giúp đảm bảo rằng kho lưu trữ của bạn tuân theo quy trình làm việc an toàn và có thể dự đoán được. Chúng ngăn chặn những thay đổi vô tình đối với các nhánh quan trọng và bảo vệ tính toàn vẹn của bản phát hành bằng cách đảm bảo rằng các phiên bản được tạo theo cách nhất quán và được kiểm soát.

Trong thực tế, tôi sử dụng các bộ quy tắc này để thực thi kỷ luật trong quy trình làm việc của mình. Ví dụ: tôi hạn chế việc đẩy trực tiếp vào chính, yêu cầu xem xét yêu cầu kéo và đảm bảo rằng thẻ phát hành tuân theo định dạng phiên bản nghiêm ngặt. Điều này giúp giữ cho kho lưu trữ sạch sẽ, có thể dự đoán và sẵn sàng sản xuất.

Điều đó nói lên rằng, các bộ quy tắc rất linh hoạt và phụ thuộc nhiều vào nhóm. Các dự án khác nhau sẽ có mức độ nghiêm ngặt khác nhau tùy thuộc vào quy mô, chiến lược triển khai và mô hình cộng tác của chúng.

Ở cấp độ cao, bộ quy tắc là thứ biến kho lưu trữ từ "chỉ mã" thành một hệ thống được kiểm soát với cấu trúc và độ tin cậy được thực thi. Tôi sẽ thảo luận thêm về các phương pháp hay nhất của bộ quy tắc trong một bài viết riêng.

Ghi chú phát hành và phát hành mới

Phiên bản dự án chưa thực sự hoàn chỉnh cho đến khi nó được xuất bản dưới dạng bản phát hành chính thức.

Theo thuật ngữ của GitHub, điều này có nghĩa là tạo một bản phát hành gắn với một thẻ cụ thể, đánh dấu sự ổn định và ảnh chụp nhanh có ý nghĩa về cơ sở mã của bạn. Tuy nhiên, bản phát hành chỉ là một nửa câu chuyện.

Bản phát hành sẽ không hoàn chỉnh cho đến khi có kèm theo ghi chú phát hành thích hợp mô tả những gì đã thay đổi kể từ phiên bản trước.

Ghi chú phát hành không phải là thứ "có thì tốt", chúng rất quan trọng. Chúng là cách chính để người dùng, người tiêu dùng, cộng tác viên và nhóm/nhà phát triển phụ thuộc thực hiện hiểu điều gì đã thay đổi, tại sao nó thay đổi và điều đó có thể ảnh hưởng đến họ như thế nào.

Ghi chú phát hành hay thường bao gồm:

Đã thêm các tính năng mới
Sửa lỗi
Các thay đổi đáng chú ý
Cải tiến nội bộ hoặc tái cấu trúc
Ghi chú di chuyển hoặc bắt buộc hành động

Điều đó có nghĩa là không phải mọi thứ trong danh sách này đều có thể áp dụng được cho mọi bản phát hành.

Không có bối cảnh này, ngay cả bản phát hành có phiên bản tốt cũng khó sử dụng một cách an toàn. Mọi người phải đoán xem điều gì đã thay đổi, điều này làm tăng nguy cơ xảy ra sự cố tích hợp và hiểu lầm.

Ghi chú phát hành được viết tốt cũng cải thiện khả năng cộng tác. Nó hoạt động như một lớp giao tiếp giữa quá trình phát triển và việc sử dụng, đảm bảo rằng các thay đổi là minh bạch và có thể theo dõi được.

Dưới đây là ví dụ đơn giản về ghi chú phát hành v1.0.0 cho dự án Metal Birds Watch:

Chuyển tất cả nhiệm vụ sang hoàn thành

Một phần thường bị bỏ qua đúng cách hoàn thành một dự án đồng nghĩa với việc dọn dẹp hệ thống theo dõi nhiệm vụ của bạn, đặc biệt là trong Dự án GitHub.

Trước khi xem xét một phiên bản thực sự hoàn chỉnh, tất cả nhiệm vụ liên quan phải được hoàn thành, đóng hoặc chuyển sang trạng thái "Xong" cuối cùng. Điều này đảm bảo rằng bảng dự án phản ánh chính xác trạng thái thực tế của công việc.

Việc rời khỏi nhiệm vụ ở trạng thái "Đang tiến hành" hoặc "Việc cần làm" sau khi phát hành sẽ tạo ra sự nhầm lẫn. Không rõ liệu thứ gì đó đã bị lãng quên, bị trì hoãn hay đơn giản là không được theo dõi đúng cách. Theo thời gian, điều này làm giảm sự tin cậy vào việc lập kế hoạch và tài liệu của dự án.

Một bảng dự án sạch sẽ cũng có tác động tâm lý. Nó mang lại cảm giác kết thúc rõ ràng và giúp cả người đóng góp lẫn người bảo trì hiểu rằng chu kỳ phát hành đã được hoàn thành đầy đủ.

Ngoài ra, Dự án GitHub có thể hoạt động như một bản ghi lịch sử về công việc. Giữ nó sạch sẽ và đóng đúng cách giúp dễ dàng xem lại các chu kỳ phát triển trước đây và hiểu nội dung được cung cấp trong mỗi bản phát hành.

Vì vậy, trước khi bạn xem xét một phiên bản được "niêm phong" hoàn toàn, hãy đảm bảo rằng tác phẩm không chỉ được hợp nhất mà còn được phản ánh chính xác trong bảng dự án của bạn. Mọi thứ nên được hoàn thành, kết thúc hoặc được cố ý chuyển sang lần lặp tiếp theo.

Chọn giấy phép cho dự án của bạn

Một trong những phần thường bị bỏ qua nhất khi hoàn thiện dự án là thêm giấy phép phù hợp.

Giấy phép xác định cách người khác được phép sử dụng mã của bạn, liệu họ có thể sửa đổi, phân phối, sử dụng mã đó cho mục đích thương mại hay không xây dựng trên đó. Nếu không có giấy phép, dự án của bạn được "bảo lưu mọi quyền" về mặt kỹ thuật theo mặc định, nghĩa là những người khác thực sự không có quyền hợp pháp để sử dụng dự án đó trong hầu hết các bối cảnh.

Điều này đặc biệt quan trọng nếu kho lưu trữ của bạn ở chế độ công khai. Mọi người có thể quan tâm đến việc học hỏi từ công việc của bạn, đóng góp cho nó hoặc sử dụng nó như một sự phụ thuộc. Nếu không có giấy phép rõ ràng, bạn đang tạo ra sự không chắc chắn về những gì được phép và không được phép.

Việc chọn giấy phép không cần phải phức tạp. Nhiều dự án sử dụng các tùy chọn tiêu chuẩn như MIT, Apache 2.0 hoặc GPL, tùy thuộc vào mức độ cho phép hoặc hạn chế mà họ muốn. Điều quan trọng không phải là bạn chọn giấy phép nào mà là bạn chọn một cách có chủ ý.

Thêm giấy phép là một bước nhỏ nhưng nó hoàn thành một phần thiết yếu trong "hợp đồng" của dự án với người dùng.

Dự án không có giấy phép sẽ chưa hoàn thành theo một cách khác. Dự án có thể hoạt động về mặt kỹ thuật nhưng chưa hoàn toàn sẵn sàng để sử dụng trong thực tế.

Trạng thái CI/CD & Tình trạng đường ống

Dự án không thực sự "hoàn thành" nếu quy trình CI/CD của bạn bị hỏng hoặc không đáng tin cậy.

Trước khi xem xét hoàn tất bản phát hành, bạn phải luôn đảm bảo rằng quy trình tự động hóa của mình ở trạng thái tốt. Điều này bao gồm việc đảm bảo rằng các bản dựng chạy thành công, các bài kiểm tra vượt qua một cách nhất quán và quy trình triển khai hoạt động như mong đợi.

CI/CD thường là thứ đầu tiên bị hỏng một cách âm thầm theo thời gian. Một thay đổi nhỏ về phần phụ thuộc, cấu hình hoặc thiết lập môi trường có thể dễ dàng dẫn đến lỗi quy trình, ngay cả khi bản thân ứng dụng có vẻ ổn ở cục bộ.

Đó là lý do tại sao tình trạng đường ống là một phần trong 1% cuối cùng của quá trình hoàn thành dự án. Nó đảm bảo rằng mã của bạn không chỉ hoạt động trên máy mà còn được xác thực và triển khai một cách đáng tin cậy trong môi trường tự động.

Một dự án được niêm phong đúng cách cần có:

✅ Trạng thái xây dựng xanh trên tất cả các nhánh bắt buộc
✅ Vượt qua các bài kiểm tra đơn vị và tích hợp
✅ Quy trình làm việc ổn định và lặp lại
✅ Không có Tác vụ GitHub nào bị lỗi hoặc lỗi thời (hoặc tương đương đường ống)

Nếu quy trình của bạn bị hỏng thì bản phát hành của bạn không thực sự an toàn, cho dù mã có vẻ tốt đến đâu.

Phiên bản được tạo phiên bản & Cấu phần phần mềm

Một phần quan trọng khác trong việc hoàn thiện dự án đúng cách là đảm bảo rằng các bản dựng và tạo phẩm của bạn được tạo phiên bản và có thể tái tạo.

Bản phát hành không chỉ tồn tại trong mã nguồn mà còn phải tồn tại dưới dạng đầu ra cụ thể, có thể nhận dạng được, có thể được xây dựng, lưu trữ và truy xuất bất kỳ lúc nào.

Bản dựng có phiên bản đảm bảo rằng mọi bản phát hành đều tương ứng chính xác với trạng thái cụ thể của cơ sở mã của bạn. Cho dù đó là tệp nhị phân được biên dịch, hình ảnh Docker, gói NuGet hay bất kỳ tạo phẩm nào khác, nó phải luôn có thể truy nguyên được về thẻ hoặc cam kết cụ thể.

Không có điều này, việc triển khai sẽ không đáng tin cậy. Bạn có thể gặp phải những tình huống:

Bạn không thể sao chép phiên bản cũ hơn của ứng dụng
Môi trường khác nhau tạo ra kết quả đầu ra khác nhau
Việc quay lại trở nên khó khăn hoặc không thể thực hiện được

Dự án được niêm phong đúng cách sẽ đảm bảo rằng:

Mỗi bản phát hành đều gắn liền với một cấu phần phần mềm được phiên bản
Cấu tạo được lưu trữ trong sổ đăng ký hoặc kho lưu trữ nhất quán
Có thể sao chép các bản dựng từ nguồn bất kỳ lúc nào
Thẻ, phiên bản và cấu phần phần mềm được căn chỉnh

Trong các hệ thống trưởng thành, việc này thường được tự động hóa thông qua quy trình CI/CD, trong đó mọi thẻ hoặc bản phát hành đều tự động tạo ra một cấu phần phần mềm bản dựng được phiên bản.

Tóm lại, nếu bạn không thể xây dựng lại và truy xuất một phiên bản cụ thể dự án của bạn thì bản phát hành chưa thực sự hoàn chỉnh, nó chỉ được niêm phong một phần.

Tùy chọn: Viết bài hoặc quay video demo

Bước này là tùy chọn và đúng như vậy. Không phải ai cũng cần đi xa đến mức này vì README được viết tốt và ghi chú phát hành phù hợp thường bao gồm những điều cần thiết.

Tuy nhiên, nếu bạn muốn thực sự giới thiệu tác phẩm của mình theo cách đầy đủ và có tác động hơn, hãy cân nhắc việc mở rộng phạm vi ra ngoài kho lưu trữ.

Viết một bài viết về dự án của bạn cho phép bạn giải thích động lực, quyết định thiết kế, thách thức và giải pháp theo cách có cấu trúc và dễ đọc định dạng. Nó cung cấp ngữ cảnh mà chỉ riêng mã thường không thể giao tiếp được.

Tiến thêm một bước nữa, việc quay một video demo ngắn có thể còn hiệu quả hơn nữa. Nó cho phép mọi người xem dự án của bạn đang hoạt động, hiểu hành vi của nó ngay lập tức và cảm nhận về trải nghiệm người dùng mà không cần thiết lập bất cứ điều gì. Đây thường là cách nhanh nhất để truyền đạt giá trị.

Sự kết hợp này, một bài viết hoặc bản demo, cũng giúp bạn cải thiện kỹ năng giao tiếp và trình bày, những kỹ năng này cũng quan trọng như khả năng kỹ thuật.

Bởi vì dù ứng dụng của bạn có tốt đến đâu nhưng nếu nó không được trình bày đúng cách thì nó có thể không bao giờ thu hút được sự chú ý xứng đáng.

Đây là Danh sách kiểm tra đầy đủ để sao chép và sử dụng

✅ README
✅ Phần "Giới thiệu"
✅ Vệ sinh chi nhánh
✅ Phát hành thẻ
✅ Bộ quy tắc nhánh và thẻ
✅ Ghi chú phát hành và phát hành mới
✅ Chuyển tất cả nhiệm vụ sang Hoàn thành
✅ Chọn giấy phép cho dự án của bạn
✅ Đường dẫn trạng thái CI/CD & Sức khỏe
✅ Bản dựng được phiên bản & Cấu phần phần mềm
✅ Tùy chọn: Viết bài hoặc quay video demo

Kết thúc mạnh mẽ như khi bạn bắt đầu

Đôi khi, chúng ta quá khao khát hoàn thành một dự án đến mức vội vàng thực hiện các bước cuối cùng và cuối cùng bỏ lỡ những chi tiết quan trọng. Khi điều đó xảy ra, hãy nhớ giảm tốc độ, hít một hơi thật sâu và nhắc nhở bản thân rằng kết thúc tốt cũng quan trọng như khởi đầu tốt.

Hãy nghĩ đến một chiếc ô tô mới tinh bị thiếu đèn hậu hoặc gương chiếu hậu - nó vẫn hoạt động nhưng chưa hoàn thiện, không an toàn và trông xấu xí. Các dự án chưa hoàn thành hoặc gấp rút đều có cảm giác giống nhau: thiếu thứ gì đó quan trọng.

Nếu bạn đã cam kết thực hiện điều gì đó, hãy dành thêm thời gian để thực hiện nó một cách đúng đắn. Hãy là người về đích mạnh mẽ. Hãy là người hoàn thành mọi việc một cách cẩn thận và có chủ đích.

1% cuối cùng của mỗi dự án GitHub: Niêm phong nó đúng cách