- vừa được xem lúc

Các bài viết ngắn phần 10

0 0 11

Người đăng: BeautyOnCode

Theo Viblo Asia

Viết commit message, dễ mà khó

A commit message shows whether a developer is a good collaborator

Một commit message thể hiện người lập trình viên có phải là một người cộng tác tốt hay không

Trong cùng một dự án thì commit message nên thống nhất với nhau về:

– Style: như nội dung bằng tiếng Anh, viết hoa chữ cái đầu tiên, …

– Content: nội dung của message

– Metadata: ticket id, pull request id, …

Luôn luôn “Keep it simple” khi viết một commit message.

Có 7 nguyên tắc giúp bạn viết một commit message tốt hơn:

– Tiêu đề(subject) cách với nội dung một dòng trống

– Tiêu đề tối đa 50 ký tự

– Viết hoa chữ đầu tiên của tiêu đề

– Không viết dấu . cuối tiêu đề

– Sử dụng câu mệnh lệnh khi viết tiêu đề(bắt đầu bằng động từ) Create, Do, Clean, Refactor, Fix, …

– Body nên tối đa 72 ký tự

– Body nên giải thích cho why and how

Mời bạn đọc thêm chi tiết và ví dụ ở bài này.

Viết README thế nào cho chuẩn

README là tập tin đầu tiên được đọc trong dự án phần mềm, chứa các nội dung quan trọng nhất của dự án như mục đích của dự án, các tính năng tính, các công nghệ được áp dụng, …

Để viết một file README cho chuẩn, gợi ý đến bạn 7 vấn đề mà bạn nên quan tâm:

  1. Viết một đoạn ngắn giới thiệu và mục đích của dự án

  2. Sắp xếp các nội dung sao cho dễ truy cập (mục lục, phân nội dung theo từng phần, link liên kết, …)

  3. Thông tin chung của dự án bổ sung thêm thông tin sau đoạn ngắn giới thiệu ở trên (dự án giải quyết vấn đề gì, dùng kỹ thuật gì: framework, database, …)

  4. Hướng dẫn người dùng chạy dự án lên (các phần mềm tiên quyết, cách tải và chạy dự án)

  5. Hướng dẫn cách kiểm thử (run tests) nếu có

  6. Mô tả về các bugs, vấn đề của dự án đã biết (know issues)

  7. Cung cấp các môi trường đã deploy để người dùng trải nghiệm (staging, prod environment)

  8. Thường xuyên update README để cập nhật thông tin mới nhất

  9. Cuối cùng, một điểm mình hay thấy là “Nhớ đóng vai người dùng để chạy dự án theo cách bạn đã hướng dẫn, và đảm bảo những gì bạn hướng dẫn là chính xác”.

(Ref)

Chân Lê - Techie Story

Nếu học cách quan sát và lắng nghe, chắc chắn sẽ đi nhanh hơn từ những câu chuyện của những người đi trước, hay đơn giản là không bị mắc kẹt vào mớ kiến thức hạn hẹp của bản thân mình.

Câu chuyện của anh Chân Lê – Engineer Manager tại Truera (Ex Snapchat, Meta & Asana) đã làm mình hiểu thêm những điều thú vị anh đã trải qua, qua đó mình học thêm:

– Hàn Quốc là nơi tốt để phát triển học thuật nhưng có vẻ sẽ kìm hãm sự phát triển cho những người thích tự do.

– Nếu cần thì phải lên tiếng, chưa hỏi sao biết là không được.

– Cuộc đời đâu phải đơn giản như Google Map, nhập điểm đầu điểm cuối là tới đích đâu. Mà ngay cả Google cũng có nhiều con đường để đến cùng một đích, không đi đường thẳng thì đi đường vòng, không sao cả, huống chi là cuộc đời mình.

– Không cần thiết phải gắn chặt bản thân mình vào cái gì cả, khi mà mình luôn thay đổi mỗi ngày mà cuộc sống mình cũng vậy.

– Take it easy.

(Bài viết chi tiết ở đây)

Dev self-learning

Tất cả lập trình viên đều cần có khả năng “tự học” ngay từ ngày đầu tiên bạn bước vào nghề này. Trong suốt quá quá trình làm việc, bạn sẽ cải thiện dần khả năng tự học của mình sao cho có hiệu quả nhất

Một vài kỹ thuật / mẹo giúp bạn tự học lập trình hiệu quả:

– Học mỗi ngày với kế hoạch được vạch ra sẵn. Bạn có thể sử dụng reminder của lịch để nhắc bản thân.

– Nghỉ ngơi hợp lý. Thường xuyên nghỉ giữa các khung giờ làm việc để nạp lại năng lượng, đó có thể là 15-20 phút sau khi làm việc 2-3 giờ, và nhất là khi bạn đang bí với một con bug, nghỉ ngơi là cách tốt nhất để não có thể tự tìm cách giúp bạn.

– Chuyển đổi giữa các chủ đề khác nhau. Vì học hoài 1 chủ đề kéo dài sẽ dẫn đến chán, chuyển đổi chủ đề giúp giảm sự nhàm chán này lại, nhưng đừng chuyển nhiều chủ đề quá.

– Kiên định với mục tiêu những không quá cứng nhắc. Bạn không nhất thiết phải học từ a-z một khoá học, mà có thể xem trước nội dung toàn khoá, rồi chọn những phần thích để học trước, … Tuy nhiên đừng nên học quá nhiều khoá một lúc.

– Tìm niềm vui. Học điều mới thì luôn không dễ dàng, bạn có thể bị bí bất cứ khi nào. Để giữ lửa vượt qua những lúc khó khăn như vậy, bạn hãy nghỉ ngơi thường xuyên, giải trí bằng một bản nhạc yêu thích, … rồi sau đó có thể tiếp tục.

– Ôn lại kiến thức đã học để có thể nhớ và hiểu sâu hơn. Dành ra vài chục phút để ôn tập hay hướng dẫn người khác cũng là một cách rất hay để có thể ôn lại kiến thức.

– Xem xét quá trình học của bản thân và điều chỉnh cho phù hợp.

– Ghi chép bằng tay những điều quan trọng có thể giúp bạn nhớ sâu hơn.

– Hiểu vấn đề, lý thuyết đằng sau thay vì nhớ ví dụ hay code sẽ giúp bạn dễ dàng tìm được những kiến thức chung được áp dụng cho nhiều loại ngôn ngữ như design patterns hay các concepts cơ bản.

(Mời bạn đọc thêm ở đây)

Git commands should know

Git sẽ đi cùng bạn suốt thời gian làm dev, vì cứ hễ code là phải commit lên repository của github, gitlab cá nhân hay của dự án, công ty.

Làm chủ Git CLI với 30 câu lệnh mà lập trình viên nên biết với bài viết ở link.

Mình sẽ tóm tắt một số câu lệnh hay sử dụng và quan trọng theo cách mình nhìn nhé.

– Setup usernane và email với “git config”. Câu lệnh này quan trọng khi bạn có nhiều repository khác nhau cần commit với tên và email khác nhau, ví dụ như repo cá nhân và công ty, dự án.

– Clone một dự án về với “git clone”, chuyển branch với “git checkout <tên branch>”

– Tạo branch mới với “git branch”, tạo mới và checkout qua luôn với “git checkout -b <tên branch>”

– Xem các branch với “git branch”, xem cả cho remote thì thêm option “-a”

– Kiểm tra code changes với “git status”

– Thêm file thay đổi lên staged với “git add”

– Commit một dòng với “git commit -m <message>”

– View commit history với “git log”, thêm option -3 sẽ xem 3 commits gần nhất, thêm -p sẽ xem thay đổi trên commit. Xem log đẹp dạng graph thì sử dụng “git log –graph –oneline –decorator”

– Xem một commit với “git show <id>”, với id có thể là 6 số đầu của một commit id

– Bỏ thay đổi của file chưa lên staged với “git checkout”, nếu lên staged rồi thì dùng “git reset”

– Rollback commit gần nhất với “git revert”

– Xoá branch đã merge với “git branch -d”, nếu có lỗi tức là branch này chưa được merge vào main branch, lúc nãy vẫn muốn xoá cần dùng option “-D”

– Xoá branch ở remote với “git push origin –delete <branch-name>”

– Merge hai branch với “git merge”, nếu cần commit merge thì thêm option “–no-ff”


Nội dung này thuộc BeautyOnCode’s short posts là các bài viết ngắn tóm tắt nội dung và ý kiến cá nhân từ các nguồn như các slack channels (công ty, cộng đồng), các new letters, …

Bài viết này đăng từ bài gốc của blog BeautyOnCode tại đây.

BeautyOnCode.

Bình luận

Bài viết tương tự

- vừa được xem lúc

Đặt tên commit message sao cho "tình nghĩa anh em chắc chắn bền lâu"????

. Lời mở đầu. .

1 1 701

- vừa được xem lúc

Tập hợp những câu lệnh GIT hữu dụng

Dưới đây là một vài ví dụ về các câu lệnh Git mà tôi thường dùng. git config --global user.name "John Doe". git config --global user.

0 0 55

- vừa được xem lúc

Cấu hình CI/CD với Github (phần 2): Trigger một work flow

Events trigger. Bạn có thể cấu hình cho workflows chạy khi có một sự kiện nào đó xảy ra trên GitHub, theo một lịch có sẵn hoặc cũng có thể là một sự kiện nào đó xảy ra ngoài GitHub.

0 0 70

- vừa được xem lúc

Cấu hình CI/CD với Github (phần 1): Một ít lý thuyết

CI/CD là gì. Về mặt khái niệm là vậy nhưng về mặt triển khai thì CI/CD là quá trình tự động thực hiện các quá trình build, test, release, deploy khi có các trigger như commit/merge code lên một branch định sẵn hoặc có thể là tự động chạy theo một lịch cố định.

0 0 118

- vừa được xem lúc

Giới thiệu về Git LFS

. Git LFS là gì . Git LFS làm điều này bằng cách thay thế các tệp lớn trong repo của bạn bằng một con trỏ nhỏ.

0 0 29

- vừa được xem lúc

Git workflow được Google và Facebook sử dụng có gì hay ho

Với developer thì Git hẳn là công cụ rất quen thuộc và không thể thiếu rồi. Thế nhưng có mấy ai thực sự hiểu được Git.

0 0 66