97 lời khuyên dành cho lập trình viên – Phần 5

Bạn có thể xem bài viết gốc của mình tại đây: https://phucluong.com/97-loi-khuyen-danh-cho-lap-trinh-vien-phan-5/

Điều 21 – Distinguish Business Exceptions from Technical – Tách biệt rạch ròi giữa “lỗi” hệ thống và “lỗi” nghiệp vụ

“Lỗi” hệ thống (tạm dịch từ “technical exception”) ám chỉ những lỗi đến từ phía lập trình viên, hoặc phía hệ thống (không phải lỗi của người dùng). Ví dụ:

• Bạn có một mảng gồm 17 phần tử, nhưng bạn lại cố gắng truy xuất dữ liệu tại phần tử thứ 83.
• Bạn sử dụng sai cú pháp/quy định (contract) của các thư viện, ví dụ như có một hàm của thư viện yêu cầu bạn truyền vào 2 tham số, nhưng bạn chỉ truyền 1, hoặc tham số truyền vào của bạn không đúng với những gì mà hàm đó kì vọng (“wrong type” chẳng hạn).
• Database bị chết hoặc đường truyền có vấn đề khiến dữ liệu không thể truyền đến người dùng.

“Lỗi” nghiệp vụ (tạm dịch từ “business exception”) ám chỉ những lỗi đến từ phía người dùng, khi họ sử dụng sản phẩm không đúng cách hoặc thiếu các bước cần thiết. Ví dụ:

• Người dùng chỉ có 500 nghìn trong tài khoản ngân hàng, nhưng họ lại muốn rút 1 triệu.
• Người dùng nhập dữ liệu nhân viên, nhưng lại nhập thiếu thông tin phòng ban của nhân viên ấy.

Ở góc độ lập trình viên, việc nhập nhằng giữa lỗi hệ thống và lỗi nghiệp vụ sẽ khiến luồng xử lý lỗi của bạn khó bảo trì và mở rộng. Bạn cần thiết kế làm sao để lỗi hệ thống và lỗi nghiệp vụ sẽ được xử lý theo những luồng khác nhau, tránh trộn lẫn với nhau khiến không chỉ người dùng mà cả bạn (và các lập trình viên khác) cảm thấy bối rối. Quay lại với ví dụ “rút tiền” ở trên, thay vì thông báo lỗi nghiệp vụ kiểu như “không đủ tiền trong tài khoản”, hệ thống lại thông báo lỗi hệ thống kiểu như “có lỗi hệ thống, vui lòng thử lại”.

Với lỗi nghiệp vụ, cần thông báo lỗi cụ thể để giúp người dùng biết được lỗi đến từ phía mình, và hướng dẫn họ cách sửa lỗi bằng cách điều chỉnh các thao tác nghiệp vụ. Với lỗi hệ thống, bạn có thể thông báo lỗi chung chung (một cách lịch sự) như “có lỗi hệ thống, vui lòng thử lại hoặc liên hệ admin”, hoặc “có lỗi về kết nối đường truyền”…

Điều 22 – Do Lots of Deliberate Practice – Thường xuyên làm việc có chủ đích

Làm việc có chủ đích (tạm dịch từ “Deliberate Practice”) là việc thường xuyên thực hành một công việc với mục tiêu là thuần thục kĩ năng hoàn thành công việc ấy. Nếu bạn đặt câu hỏi: “tại sao tôi lại làm công việc này”, và câu trả lời của bạn là “để hoàn thành công việc ấy”, thì đó không phải là “deliberate practice”. Mục tiêu của việc “làm việc có chủ đích” là để thuần thục kĩ năng hoàn thành công việc, chứ không phải chỉ đơn thuần là làm xong công việc.

Hãy tự đặt câu hỏi cho bản thân rằng, bạn đã dành bao nhiêu thời gian cho việc lập trình các sản phẩm của các công ty mà bạn đã và đang làm việc? Và bạn đã dành bao nhiêu thời gian cho việc xây dựng bản thân?

Theo bạn, làm bao lâu thì sẽ đạt được mức thuần thục công việc? Peter Norvig (http://norvig.com/21-days.html) và Mary Poppendieck (tác giả sách Leading Lean Software Development) đều cho rằng bạn cần ít nhất 10,000 giờ lập trình để có thể trở thành một chuyên gia trong lĩnh vực của mình (tương đương khoảng 20 giờ mỗi tuần, liên tục trong 10 năm). Tất nhiên là không phải bạn cứ phải đạt đủ 10,000 giờ thì mới là chuyên gia, mà kĩ năng của bạn đã được tích lũy tăng dần đều qua năm tháng.

Các nhà nghiên cứu cho rằng dù những người có tài năng thiên bẩm thì họ cũng sẽ chạm ngưỡng năng lực của họ nếu không thật sự cố gắng. Ngược lại, thành quả lớn sẽ đến với bất kì ai dù chỉ có một ít khả năng tự nhiên, nhưng nỗ lực không ngừng nghỉ.

Một điểm lưu ý khác nữa, việc “làm việc có chủ đích” không đơn giản là lặp đi lặp lại mãi một việc, mà là phải liên tục thử thách bản thân với những mức độ khó dần, những việc nằm ngoài khả năng chuyên môn hiện tại của bạn. Thử thách chúng, và tự đánh giá bản thân sau khi hoàn thành (hoặc không hoàn thành) các công việc ấy.

Lời kết, “làm việc có chủ đích” xoay quanh một vấn đề duy nhất, đó là việc học hỏi (learning). Chính việc học hỏi không ngừng sẽ thay đổi con người bạn, và thay đổi cả những hành vi của bạn. Chúc bạn thành công.

Điều 23 – Domain-Specific Languages – Ngôn ngữ chuyên ngành

Bất cứ ngành nghề nào (bác sĩ, giáo viên, kì thủ cờ vua…), đều có những ngôn ngữ đặc thù (chuyên ngành) của ngành nghề đó. Dù bạn là người Việt, nói tiếng Việt, nhưng khi nghe 2 chuyên gia về lĩnh vực bảo hiểm nói chuyện với (bạn không có chuyên môn về bảo hiểm), thì có thể bạn cũng sẽ lùng bùng lỗ tai với những thuật ngữ mới lạ. Đó được gọi là “domain-specific languages” (DSLs): một lĩnh vực chứa các từ ngữ chuyên dụng và đặc trưng để mô tả cho những thứ trong lĩnh vực ấy.

Trong lĩnh vực phần mềm của chúng ta, DSLs là những đoạn lệnh/code/script để thực thi những tác vụ cụ thể, chúng sẽ khác nhau tùy vào ngôn ngữ lập trình. Chúng thường có hạn chế số lượng từ vựng, ngữ pháp so với ngôn ngữ của loài người, và cú pháp của nó cũng khó đọc, khó hiểu, đôi khi những ngôn ngữ ấy chỉ dành cho máy móc chứ không dành cho con người để đọc hiểu chúng.

Bạn phải luôn luôn biết đối tượng mà bạn đang tương tác khi sử dụng các ngôn ngữ chuyên ngành phần mềm của chúng ta. Họ là những lập trình viên, nhà quản lý, khách hàng, hay người dùng cuối? Bạn phải biết linh hoạt lựa chọn từ ngữ để nói chuyện với từng đối tượng khác nhau. Ví dụ:

• Có bao giờ bạn đi nhậu với đám bạn thân, nhưng lại nói chuyện về công việc lập trình của mình, và đám bạn chả hề quan tâm hay thấy hứng thú gì cả?
• Với những câu thông báo lỗi trên màn hình, nếu bạn nhắm đến đối tượng là người dùng không có kiến thức chuyên sâu về IT, thì những câu lỗi hiển thị nên dễ hiểu, phù hợp với họ, để họ hiểu cơ bản nguyên nhân lỗi và cách khắc phục. Hoặc nếu những câu thông báo lỗi dành cho những lập trình viên khác, thì nội dung cũng cần phải thay đổi để thể hiện chi tiết và chuyên sâu hơn.
• Hoặc khi bạn báo cáo vấn đề công việc với sếp của bạn, người sếp của bạn có chuyên môn cao về IT không? Dù có hay không, bạn cần phải trình bày vấn đề linh hoạt làm sao để người sếp của bạn hiểu được vấn đề, có thể ra quyết định hợp lý (và không bị cảm giác “quê” trước nhân viên của mình). Chúng ta không nên tỏ ra xem thường sếp của mình nếu họ không hiểu những vấn đề về kĩ thuật, mà hãy xem lại bản thân đã trình bày vấn đề dễ hiểu hay không.

Điều 24 – Don’t Be Afraid to Break Things – Đừng sợ phải làm hỏng thứ gì.

Chắc hẳn các bạn đã từng ít nhất một lần làm trong một dự án vô cùng mong manh dễ vỡ. Nó được xây dựng kém ngay từ thời điểm ban đầu, hoặc do qua quá nhiều lần thay da đổi thịt bởi những nhóm lập trình khác nhau, nên việc thay đổi một thứ gì đó có thể sẽ làm một module không liên quan khác bị lỗi. Và khi bạn thêm một module mới, bạn phải cố gắng hạn chế phạm vi ảnh hưởng của nó nhiều nhất có thể để tránh rủi ro, và cầu nguyện cho mọi thứ suôn sẻ khi release.

Lý do là vì hệ thống ấy đang mắc bệnh, và nó cần một người bác sĩ chữa trị cho nó. Nếu không, tình trạng bệnh chỉ có nặng dần lên theo năm tháng mà thôi. Một bác sĩ phẫu thuật có kinh nghiệm, họ biết rằng việc phẫu thuật là cần thiết để cứu lấy bệnh nhân, và kết quả sẽ hoàn toàn xứng đáng với công sức mà vị bác sĩ ấy bỏ ra, đó là việc bệnh nhân khỏe lại sau ca phẫu thuật.

Đừng sợ chính mã nguồn của bạn. Chính nỗi sợ này khiến bạn không dám thay đổi, như hệ thống có bệnh nhưng không có người chữa bệnh, và nó ngày càng trầm trọng hơn. Hãy dành thời gian để đánh giá và tái cấu trúc (nếu cần thiết). Và tương tự, kết quả sẽ xứng đáng với công sức mà bạn đã bỏ ra. Một lợi ích khác nữa là bạn (và nhóm của bạn) sẽ có những kinh nghiệm quý báu trong việc giải quyết những vấn đề của những hệ thống yếu kém, và bạn sẽ nhanh chóng thành những chuyên gia. Nếu vô tình bạn được phân công vào một hệ thống như vậy, đừng trách móc hay chán nản, mà hãy vui lên vì bạn đang có một cơ hội hiếm có để thực hành và phát triển bản thân, cũng như thể hiện năng lực bản thân với mọi người. Thái độ của bạn sẽ truyền cảm hứng cho những người xung quanh cũng muốn làm tương tự, hoặc ít nhất cũng sẽ có những ý niệm trong đầu.

Để tránh việc chán nản hay bỏ cuộc giữa chừng, hãy cố gắng phân nhỏ công việc, hoàn thành từng chút một, và đi kèm với test cẩn thận. Hãy thuyết phục sếp của bạn và nhấn mạnh về tầm quan trọng của công việc ấy. Nó có thể không có kết quả rõ rệt và thấy được trước mắt, nhưng chắc chắn nó sẽ giúp giảm chi phí và công sức cho những lần release tiếp theo.

Điều 25 – Don’t Be Cute with Your Test Data – Đừng tinh nghịch với dữ liệu kiểm thử

Trong một lần làm việc muộn cuối ngày, tôi đã đưa một số dữ liệu giả để thử nghiệm cho layout mới mà tôi đang phát triển. Dữ liệu này cần có tên người dùng, tên công ty, và mã chứng khoán với 4 kí tự in hoa. Với tên người dùng, tôi chọn tên các thành viên trong ban nhạc The Clash. Với tên công ty, tôi chọn các bài hát của nhóm Sex Pistols. Với mã chứng khoán, tôi đã chọn 4 chữ cái kinh điển mà chắc bạn đã biết là gì. (Mình đoán là từ “F**K”)

Mục đích của tôi chỉ là để giải trí thời điểm ấy, và dự định là ngày mai đồng nghiệp của tôi sẽ giúp kết nối với dữ liệu thật sau. Tuy nhiên, vào sáng hôm sau, người quản lý dự án đã chụp màn hình một số trang ấy cho một buổi thuyết trình.

Lịch sử ngành chúng ta có rất nhiều việc như vậy từng xảy ra. Người lập trình viên, hay người thiết kế nghĩ rằng dữ liệu mẫu này sẽ không có ai thấy được đâu, tuy nhiên vô tình chúng lại bị lọt ra bên ngoài, tìm ẩn những rủi ro kinh khủng về hình ảnh/danh tiếng của một người, một nhóm, hay cả công ty. Ví dụ:

• Trong một buổi họp với khách hàng, khi khách hàng click vào một button (chưa được hoàn thiện phần code bên dưới), một popup hiện ra với nội dung “Đừng click nữa, đồ ngốc”.
• Một lập trình viên được yêu cầu hiển thị một popup thông báo lỗi ở một hệ thống nọ, và người này quyết định lấy log lỗi được lưu trong hệ thống để xuất ra màn hình. Và một ngày nọ, người dùng bất ngờ thấy một thông báo lỗi: “Holy database commit failure, Batman!”
• Một ai đó nghịch ngợm với hệ thống quản lý dữ liệu (admin), và thêm một sản phẩm “cho vui” và hệ thống bán hàng online: “Máy mát xa cá nhân hình Bill Gates”.

Ngay cả mã nguồn của bạn cũng cần phải cẩn thận. Vào năm 2004, khi mã nguồn của Window 2000 bị lộ trên mạng, một số người đã phát hiện ra những câu comment “thú vị” của các lập trình viên trong mã nguồn của họ.

Nói tóm lại, khi viết bất kì một từ gì trong code của bạn, dù cho nó là comment, log, popup, hay dữ liệu mẫu (test data), hãy cân nhắc trước khi viết, và thử tưởng tượng nếu những từ ngữ này bị lộ ra ngoài thì sẽ như thế nào. Tốt nhất là bạn hãy luyện bản thân mình luôn luôn tỉnh táo và không đùa nghịch quá trớn khi làm việc.