Skip to main content

Posts

[Code Review] Lợi ích và những sai lầm thường thấy

Tôi là một kĩ sư, một kĩ sư công nghệ, thế nên việc hiểu và thực hành code review nó là một trong những công việc hằng ngày của tôi. Tuy nhiên việc thực hành code review một cách hiệu quả thực sự là một thách thức. Việc hiểu những lợi ích và khó khăn trong khi tiến hành code reivew sẽ giúp chúng ta hiểu đúng và có cách tiếp cận phù hợp để mang lại giá trị và lợi ích cao nhất. Các lợi ích nổi bật code review mang lại Improve code quality Thông qua code review chất lượng code base được tăng cường, khi bạn thực hành code review một cách có hiệu quả nó thường dẫn đến một số các kết quả như bạn nhận được nhiều feedback có giá trị từ những đồng nghiệp trong team. Và thông qua các tương tác trao đổi kết quả tất yếu là chất lượng code base của bạn được nâng cao Tìm kiếm và ngăn chặn các lỗi từ sớm Khi code review đã trở thành một thói quen và bạn cảm thấy thích thú với việc đó, thì bạn có thể mang đến rất nhiều lợi ích cho sản phẩm, bạn có thể ngăn chặn các lỗi từ trước khi chúng xuất hiện, th
Recent posts

Idiomatic Git commit message

Source control is a developer’s best friend. The ability to share code with multiple developers, track changes, and easily roll back when problems arise is indispensable in this distributed world. Reviewing others’ commits and pull requests becomes something worth doing, and suddenly can be done independently. Understanding why something happened months or years ago becomes not only possible but efficient. A project’s long-term success rests (among other things) on its maintainability, and a maintainer has few tools more powerful than his project’s log. It’s worth taking the time to learn how to care for one properly. What may be a hassle at first soon becomes habit, and eventually a source of pride and productivity for all involved. The seven rules of a great Git commit message 1. Separate subject from body with a blank line 2. Limit the subject line to 50 characters 3. Capitalize the subject line 4. Do not end the subject line with a period 5 .Use the imperative mood in

Testing like a boss

Manual mobile app testing là một công việc không hề dễ dàng, nó đòi hỏi QA/Tester phải giành nhiều thời gian và công sức để có thể verify/qualify được hết tất cả các test case. Đặc biệt khi những yêu cầu như pixel perfect hay khi dữ liệu được combine từ nhiều nguồn khác nhau (API/Cache/Local Database/Sharepreferences), thì thời gian mà QA/Tester bỏ ra để có thể đánh giá được chính xác "development progress" là ko hề nhỏ. Tôi có thể kể ra một số câu hỏi thường gặp khi manual testing mobile app  1. Liệu 2 màu ( ▲ )( ▲ )   (implementation/specs) có thực sự giống nhau? Hãy chỉ ra mã màu của chúng? 2. Textsize là bao nhiêu? Typeface là gì? TextColor, HintColor giá trị như thế nào? Làm sao để trả lời đã tuân theo design specs hay chưa? 3. Khoảng cách giữa 2 view là bao nhiêu pixel? Có đúng specs ko? 4. Làm sao có thể biết được trong một màn hình, dữ liệu lấy từ đâu? (API/Cache/Local Database/Sharepreferences) 5. Làm sao có thể xoá local storage khi cần thiết? 6. Kiể

Auto Code Review (Danger)

Code review là một quy trình bắt buộc trong qui trình phát triển phần mềm chuyên nghiệp. Mục tiêu quan trọng nhất của code review là nâng cao code quality của dự án. Tuy nhiên đối với những team làm outsource hoặc khi tính chất của dự án “quick win” với deadline oriented. Thông thường cách tiếp cận của team trong code review chỉ là apply một số rule về coding convention và coding style để cho dự án chạy. Lý do thường thấy nhất đó là reviewer thường phàn nàn không có đủ thời gian để làm review một cách chuẩn chỉnh và qui củ, hơn nữa việc bỏ sót lỗi trong quá trình review là khó tránh khỏi (human mistake). Hoàn toàn hợp lý tuy nhiên chúng ta có thể có một cách tiếp cận tốt hơn bằng cách delegate việc review code style, code convention, và kết quả static analysis tool cho code review bot (Danger). Bằng cách này chúng ta giải quyết được 3 vấn đề chính: Reviewer chỉ cần focus vào review business logic, cái này giá trị hơn rất nhiều so với code style và code convention cũng như s

Follow Law of Demeter!

Việc code bẩn code rác là khá phổ biến đối với lập trình viên, mà để thay đổi nó chúng ta cần phải có thời gian luyện tập, mình sẽ thông qua series các bài viết chia sẻ kinh nghiệm việc mình luyện tập và apply việc refactor code làm cho code đẹp hơn. (Trong series này mình sẽ sử dụng ngôn ngữ Ruby để làm ví dụ) Ở phần 1 này mình sẽ đi vào nguyên lý đầu tiên  Follow Law of Demeter . Để hiểu xem cụ thể Low of Demeter (LoD) là gì chúng ta sẽ đi vào một ví dụ cụ thể. Giả sử chúng ta có 3 class là Address, Customer và Order class Address < ActiveRecord :: Base belongs_to: customer end class Customer < ActiveRecord :: Base has_one: address has_many: orders end class Order < ActiveRecord :: Base belongs_to: customer end Vì  Ruby  cho phép chúng ta thông qua quan hệ của các đối tượng để truy cập đến các thuộc tính và phương thức của những đối tượng liên quan. Để hiển thị địa chỉ của khách hàng cho 1 đơn hàng, chúng ta thông thường sẽ xử lý