-
Design Pattern
- Singleton Design Pattern
- Factory Design Pattern
- Factory Method Design Pattern
- Abstract Factory Design Pattern
- Builder Design Pattern
- Prototype Design Pattern
- Object Pool Design Pattern
- Chain of Responsibility Design Pattern
- Command Design Pattern
- Interpreter Design Pattern
- Iterator Design Pattern
- Mediator Design Pattern
- Memento Design Pattern
- Observer Design Pattern
- Observer Design Pattern - Xử Lý Exception
- Strategy Design Pattern
- Template Method Design Pattern
- Visitor Design Pattern
- Null Object Design Pattern
- Adapter Design Pattern
- Bridge Design Pattern
- Composite Design Pattern
- Decorator Design Pattern
- Flyweight Design Pattern
- Proxy Design Pattern
- S.O.L.I.D
- Clean code
- Lập trình socket
- Java Core
- Multi-Thread
- Spring
- Java Web
- Memory Caching
- Message Queue
- DevOps
- Xây dựng một nền tảng
- MongoDB
- MySQL timestamp
- Properties vs yaml
- Kotlin
- Lập Trình Machine Learning với PyTorch
- Mã Nguồn Mở
- Ezy HTTP
- Free Chat
- Một số kinh nghiệm với Git
- Review cho đồng nghiệp!
- Setup Dev Environment
- Hello World
- Create a Server Project
- Handle Client Requests
- Using ezyfox-server-csharp-client
- Using ezyfox-es6-client
- Client React.js Interaction
- Build And Deploy In Local
Không hề đơn giản!
Như anh em đều biết, ngành công nghệ thông tin của chúng ta đơn giản là xoay quanh dự án và source code (mã nguồn). Đi cùng với đó là một công việc chúng ta không hề yêu thích một chút nào, đó chính là review code. Nó bao gồm các công việc: giúp xem lại, đóng góp ý kiến và đưa ra bản sửa đổi. Tuy ngắn gọn nhưng không hề đơn giản, nó là nguồn cơn của rất nhiều xung đột, tranh luận cãi vã và kết quả cuối cùng là tan vỡ. Dựa theo kinh nghiệm làm trong dự án đa quốc gia, mình xin chia sẻ một số quan điểm cá nhân nhé.
Xác định rõ mục tiêu
Đầu tiên, hãy xác định rõ mục tiêu của việc review. Review là để phát hiện ra những sai sót có thể xảy ra từ đó đưa ra những sửa đổi kịp thời. Nếu bạn nghĩ review là để thể hiện bạn giỏi, thể hiện kiến thức siêu việt của bạn thì nó cũng tương đương với việc tự bắn vào chân mình. Vì sao vậy? Vì trong tất cả các lĩnh vực nói chung thì việc đưa cái tôi cá nhân vào công việc sẽ dẫn đến việc bạn mất tập trung vào mục tiêu chung và nhận lại những phản ứng tiêu cực từ phía đồng nghiệp.
Hãy chân thành
Đừng góp ý hời hợt. Hãy lấy source code về chạy thử, kiểm tra các một lượt các chức năng xem nó hoạt động thế nào, có lỗi ở đâu không và đưa ra phản hồi. Đừng chỉ cưỡi ngựa xem hoa, lướt lươt trên giao diện web, nó có thể thật ngầu đấy, nhưng nó cũng có thể giết chết một dự án. Cẩn thận chưa bao giờ là thừa.
Đưa phương án cụ thể
Hãy đưa ra phương án cụ thể. Sẽ thế nào nếu bạn nhận được 1 câu góp ý: "chỗ này không đúng", rõ ràng là bạn sẽ rất hoang mang rồi đúng không? Những người nóng tính thậm chí còn cảm thấy phát điên. Câu tiếp theo sẽ là: "Sai ở đâu?", như vậy câu chuyện sẽ bị kéo dài, tốn thời gian của tất cả mọi người. Hãy làm kiểu thế này, tôi thấy chỗ này của bạn thiếu xử lý logic khi gặp lỗi, đây là code sửa đổi của tôi, bạn có thể thao khảo nhé. Ví dụ ở đoạn code này:
Integer result = null;
try {
result = emitData();
}
catch(Exception e) {
e.printStackTrace();
}
Chúng ta có thể thấy dường như người code đã quên xử lý lỗi cho trường hợp Exception, vậy hãy comment thế này nhé: Tối thấy dường như bạn đã quên không xử lý lỗi, tôi có 2 đề nghị thế này, bạn thử tham khảo nhé.
Phương án 1: Sử dụng biến int, như vậy bạn có thể trả về kết quả là 0 nếu có lỗi và tránh được NullPointerException
.
int result = 0;
try {
result = emitData();
}
catch(Exception e) {
e.printStackTrace();
}
Phương án 2: Hãy ném ra exception để cho lớp GlobalExceptionHandler
xử lý:
int result = 0;
try {
result = emitData();
}
catch(Exception e) {
throw new IllegalStateException("emit data error", e);
}
Bạn thấy không? Rất rõ ràng và cụ thể, và vấn đề sẽ được giải quyết nhanh chóng hơn rất nhiều.
Hãy tự tin
Đừng nghĩ mình kém. Khi làm trong một dự án sẽ có rất nhiều người, và mỗi người sẽ có 1 cách nhìn nhận vấn đề khác nhau, đừng tự ti nếu bạn đang có số năm kinh nghiệm ít hơn, hãy thẳng thắn đưa ra những góp ý của mình, đây cũng là cơ hội để học hỏi và gia tăng thêm kinh nghiệm cho bản thân.
Không phán xét
Đừng vội vàng phán xét. Nếu bạn đang dùng việc reivew để đánh giá đồng nghiệp của mình thì hãy suy nghĩ lại. Có làm thì mới có sai, và khi là một thành viên trong dự án, hãy luôn nghĩ rằng ngăn chặn những cái sai là công việc không của riêng ai cả. Hãy tập trung vào việc review trước còn việc đánh giá hãy đợi khi dự án kết thúc.
Tổng kết
Review code là một trong những việc tối quan trọng trong dự án. Không ai là hoàn hảo cả, nhưng cùng nhau, chúng ta có thể tạo ra được nhiều thứ tốt đẹp hơn và giảm thiếu được lỗi ở mức tối đa, từ đó mà có những đêm ăn ngon ngủ yên.
-
Design Pattern
- Singleton Design Pattern
- Factory Design Pattern
- Factory Method Design Pattern
- Abstract Factory Design Pattern
- Builder Design Pattern
- Prototype Design Pattern
- Object Pool Design Pattern
- Chain of Responsibility Design Pattern
- Command Design Pattern
- Interpreter Design Pattern
- Iterator Design Pattern
- Mediator Design Pattern
- Memento Design Pattern
- Observer Design Pattern
- Observer Design Pattern - Xử Lý Exception
- Strategy Design Pattern
- Template Method Design Pattern
- Visitor Design Pattern
- Null Object Design Pattern
- Adapter Design Pattern
- Bridge Design Pattern
- Composite Design Pattern
- Decorator Design Pattern
- Flyweight Design Pattern
- Proxy Design Pattern
- S.O.L.I.D
- Clean code
- Lập trình socket
- Java Core
- Multi-Thread
- Spring
- Java Web
- Memory Caching
- Message Queue
- DevOps
- Xây dựng một nền tảng
- MongoDB
- MySQL timestamp
- Properties vs yaml
- Kotlin
- Lập Trình Machine Learning với PyTorch
- Mã Nguồn Mở
- Ezy HTTP
- Free Chat
- Một số kinh nghiệm với Git
- Review cho đồng nghiệp!
- Setup Dev Environment
- Hello World
- Create a Server Project
- Handle Client Requests
- Using ezyfox-server-csharp-client
- Using ezyfox-es6-client
- Client React.js Interaction
- Build And Deploy In Local