Skip to main content

Posts

Showing posts from November, 2018

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