Bạn nghĩ rằng senior hơn junior ở những cái cao siêu như thuật toán phức tạp, viết code cực nhanh, thiết kế hệ thống cực khủng sao?

Lầm rồi! Đa phần họ hơn nhau ở kinh nghiệm làm việc, ở những trải nghiệm thực tế họ gặp phải và những công cụ họ đã sử dụng.

Nhờ kinh nghiệm, Senior dev sẽ biết cách tiếp cận vấn đề, biết lựa chọn những công cụ cần thiết để làm việc hiệu quả hơn, tạo ra phần mềm chạy nhanh hơn, ít lỗi hơn.

Trong bài viết này, mình sẽ giới thiệu về những công cụ đơn giản, bá đạo mà 69.96% sinh viên IT không hề biết.

Những thứ này truờng không hề dạy, làm đồ án cũng không bao giờ dùng. Tuy nhiên, chúng lại đuợc áp dụng trong 96.69% các dự án thực tế.

Thông qua những câu chuyện ngắn gọn, mình sẽ giới thiệu và giải thích về các công cụ này nhé. Chúng lần luợt là:

• Phần 1: Unit Test và Logging
• Phần 2: Chờ coi sẽ biết

Hai nhân vật chính trong câu chuyện này là:

• Sơn, một sinh viên Ép Tao Dê mới ra trường, gia nhập công ty phần mềm Ép Dê Tao với vị trí junior.
• Tùng, một anh senior dev kì đẹp trai cao to sáu múi.

Toàn bộ những chuyện dưới đây đều là hư cấu, không dựa trên bất cứ sự kiện có thật nào nhé!

Unit Test – Phát hiện bug trong chớp mắt

Với những bạn nào chưa biết về Unit Test và Testing, các bạn đọc 2 bài này truớc để hiểu câu chuyện nhé:

• Tổng quan về testing
• Viết Unit Test trong C#

 

Chuyện thứ nhất: Ngày mới vào công ty, Sơn đuợc tham gia bảo trì, thêm chức năng mới cho một dự án C# khoảng 2 năm tuổi. Không chỉ fix bug, Sơn còn nhiệt tình… refactor code để code ngắn gọn hơn, dễ bảo trì hơn.

Thế nhưng, đến lúc deploy lên máy khách hàng, hệ thống chỉ chạy đuợc 30 phút rồi… tử ẹo. Sau một hồi truy tìm nguyên nhân, hoá ra thủ phạm chính là những đoạn code đã “được” Sơn refactor.

Do gây ra hậu phải hơi nghiêm trọng, Sơn bị đồng nghiệp hắt hủi, cấp trên xa lánh. Thấy tội nghiệp, anh Tùng liền vào giúp đỡ Sơn. Anh chỉ Sơn làm theo 3 buớc đơn giản:

1. Viết unit test cho các đoạn code sẵn có. Test phải cover càng nhiều dòng code càng tốt.
2. Chạy thử unit test để đảm bảo các case đều pass.
3. Sau khi sửa chữa, refactor code, chạy unit test lại.

Mỗi khi sửa code, Sơn đều chạy unit test cho tới khi các case pass hết. Nếu có case nào bị fail, tức là code có lỗi, Sơn chỉ cần vào sửa lỗi là xong.

Nhờ áp dụng 3 buớc cơ bản của anh Tùng, code của Sơn không còn bug nữa. Sơn rất vui mừng, lòng biết ơn anh Tùng vô hạn.

Logging – Quay ngược thời gian có khó gì!

Chuyện thứ hai: Hết dự án này, Sơn lại đuợc đưa qua một dự án khác làm Java.

Truớc đây, hệ thống chạy rất ổn định. Thế nhưng, chẳng hiểu do số xui hay sao mà từ khi Sơn vào đuợc một tháng thì hệ thống hay chập chờn, cỡ 11-12h đêm là … tắt ngúm, làm mấy bác Sysadmin phải restart lại mỗi sáng.

Team bắt đầu nghi ngờ code của Sơn làm cho hệ thống chập chờn. Sơn vô cùng đau khổ, vò đầu bứt tai mấy ngày liền mà không biết nguyên nhân do đâu.

Thấy tội nghiệp, anh Tùng liền vào giúp đỡ Sơn. Anh kêu Sơn tích hợp log4j vào dự án, gắn thêm service log vào server để theo dõi CPU và Ram của hệ thống.

Sáng hôm sau, Sơn và anh Tùng cùng xem lại log. Dựa theo log, đúng 10h thì hệ thống ngỏm cù đèo vì bị Timeout Exception và OutOfMemoryException.

Theo log trên server, có 1 file coin-xxx.exe tự động chạy vào lúc 9h45, chiếm 90% CPU và 7GB RAM nên làm hệ thống quá tải!

Thủ phạm nhanh chóng được tìm ra, hoá ra do một thanh niên tên Kha cùng team, do đầu tư XRP thua lỗ nên viết script dùng máy công ty để đào coin.

Script này tự bật lên lúc 9h45, tự tắt lúc 6h sáng nên thần không biết quỷ không hay. May nhờ có log nên mới truy ra đuợc. Thế là Sơn đã được giải oan.

 

Câu chuyện kể trên cho ta thấy vai trò của logging trong một phần mềm.

Khi hệ thống đang chạy, chúng ta không thể debug để tìm lỗi đuợc. Nhờ có logging, ta biết đuợc hệ thống chạy ra sao, dùng bao nhiêu tài nguyên, có những lỗi gì đã xảy ra trong quá khứ.

Khi hệ thống có vấn đề, log là thứ chúng ta xem đầu tiên. Nhờ có log ta mới có thể biết chuyện gì đã xảy ra, tìm huớng giải quyết.

Thuở còn học và làm bài tập, đôi khi chúng ta dùng Console.Write (C#) hoặc System.out.print (Java) để ghi log. Cách này cũng đúng nhưng chưa đủ. Việc ghi log phải đạt đuợc những yêu cầu sau:

• Phải có thời gian log đuợc ghi
• Log phải đi kèm với level: info, warn, error
• Phải có format cụ thể để sau này ta parse và xử lý dự liệu từ log.
• Phải ghi log vào file để dễ xem lại, khi file lớn quá thì phải xoá bớt.
• Không gây ảnh huởng nhiều đến performance, không làm chậm hệ thống.
• Phải cho phép config, cài đặt thông qua code, qua file XML hoặc JSON.

Do vậy, thông thuờng nguời ta không tự viết mà sử dụng các thư viện đã có sẵn, đáp ứng đủ các yêu cầu trên.

Ngôn ngữ nào cũng có các thư viện log hết cả! Ví dụ Java có Log4j, .NET có Log4net hoặc Serilog, NodeJS thì có morgan.

Tạm kết

Ban đầu mình định viết 1 phần thôi, mà do lỡ hứng quá viết hơi dài nên series nó thành 2 phần luôn rồi.

Các bạn nhớ đón xem phần 2 đến biết 2 công cụ còn lại là gì, chuyện tình cảm giữa Sơn và Tùng sẽ đi đến đâu nhé!