Khoan, gì cơ ? Phải, bạn không đọc nhầm đâu. Trên internet đã có rất nhiều những bài hướng dẫn và lời khuyên bổ ích nên bài viết sẽ “hơi” khác biệt một chút. Bài viết này sẽ liệt kê 5 “tội lỗi” mà bạn có thể gây ra bằng code của mình. Những thói quen này “xấu xa” đến mức có thể khiến tất cả các lập trình viên khác phải hắt hủi bạn. Các bạn đã sẵn sàng tiếp thu kiến thức kì quái này chưa? Hãy cùng nhau tìm hiểu nào.
Thói quen xấu số 1: Biến việc đặt tên thành một trò giải đố
Hãy khởi động với một cái gì đó đơn giản. Để bắt đầu, thêm vài chữ viết tắt vào các tên biến hoặc tên hàm.
Việc nên làm ở đây là làm cho tất cả những cái tên miêu tả chức năng của nó càng rõ ràng càng tốt, đúng không? Ví dụ như handleFormSubmit, getUserConfiguration hay parseCustomerInformation. Nhưng ở đây chúng ta không làm người tốt.
Để khiến cho kết quả trở nên tệ hại, luôn rút gọn và viết tắt tên gọi nhiều nhất có thể, để cho lập trình viên tiếp theo làm việc với code của bạn phải đoán xem bạn đang nghĩ cái gì.
Những cái tên như handleBtnClick, getConfig hay parseInfo là các ví dụ điển hình. Chúng không hé lộ quá nhiều về công dụng của hàm, tuy nhiên nó vẫn có thể chạy được trong quá trình duyệt lại code. Và những từ viết tắt không cần thiết như btn, func, config hay cb khiến code càng trở nên khó hiểu hơn nữa.
Bạn còn có thể làm nhiều hơn nữa với tên biến ! Có một danh sách những người dùng chưa xác nhận ? Đừng có gọi biến là uncofirmedUsers, mà hãy cứ đặt tên nó là users. Lập trình viên kế tiếp sẽ phải đọc TOÀN BỘ code trả về các biến để biết trong đó có gì. Sẽ không có discountedProducts cho con người khốn khổ ấy, bởi chỉ cần tên sản phẩm thôi vẫn là đúng và đủ.
Để thêm một chút “gia vị”, bạn có thể sử dụng kiểu chữ (in hoa, in thường), và đảm bảo là đồng nghiệp sẽ ghét cay ghét đắng bạn. thay vì tạo ra một readXmlDocument method như vẫn thường được khuyến khích (Các từ viết tắt nên được định dạng như từ thông thường) bạn có thể tạo một readXMLDocument method đòi hỏi các lập trình viên khác phải nhìn kỹ và đọc cẩn thận để có thể hiểu được.
Và tất nhiên, tất cả những trò ác ôn trên đều có thể được giải quyết trong quá trình duyệt lại code nhưng việc của bạn là phải chống chế. Có thể là do bạn quá lười để sửa, hay “đùa tí gì căng”. Bằng cách này hay cách khác, hãy nhớ là bạn luôn có thể hứa sẽ sửa sai trong lần pull request tiếp theo và hi vọng rằng mọi người sẽ tha thứ và quên đi “tội lỗi” của bạn (và chắc là họ sẽ bỏ qua thôi).
Thói quen xấu số 2: Viết code cực kì phức tạp
Lúc này bạn sẽ có cơ hội chứng tỏ mình là một Rick Sanchez (Nhân vật chính trong phim Rick and Morty) của nghề lập trình phần mềm.
.jpg)
Bạn phải viết code sao cho nó phức tạp hơn mức cần thiết.
Có lẽ bạn sẽ tìm ra cách tổng quát hóa mà cho phép sử dụng lại 3 dòng code ở 2 chỗ khác nhau bằng cách tạo ra một method có thể chấp nhận 5 tham số ? Hay gộp 3 dòng code vào làm 1 bằng cách sử dụng 3 toán tử 3 ngôi được lồng vào nhau ? Hãy để trí tưởng tượng của bạn bay xa!
Tất nhiên là nó sẽ làm ứng dụng khó đọc và khó bảo trì hơn nhưng đấy là việc mà đồng nghiệp của bạn phải giải quyết cơ mà? Tuyệt cú mèo!
Vậy hãy bắt tay và viết những dòng code để thể thiện trình độ hacker thượng thừa của bạn. Bạn nên sử dụng các hàm xâu chuỗi, các câu lệnh điều kiện lồng nhau, các kiểu mẫu thiết kế quá khổ và các dòng lệnh đơn tài tình sử dụng những tính năng rất khi ít dùng trong ngôn ngữ mà bạn đang sử dụng. Bởi tại sao phải viết Date.now() trong khi có thể làm cùng một công việc với hàm +new Date() mơ hồ hơn ? Hẳn là đồng nghiệp làm cùng dự án sẽ cảm ơn bạn khi họ phải dành thời gian để cố mà hiểu cái quái gì đang diễn ra trong mấy dòng code.
Và hãy nhớ: code càng được phức tạp hóa và tối ưu sớm bao nhiêu thì sẽ càng khiến đồng nghiệp của bạn phải vật lộn bấy nhiêu. Bạn sẽ ghi được 10 điểm “tôn trọng” khi sử dụng hàm reduce và 100 điểm khi gọi hàm đệ quy. Đến cuối dự án thì bạn đã trở thành một coder chuyên nghiệp rồi, xin chúc mừng!
Thói quen xấu số 3: Import từ mọi nơi
Những kĩ thuật đã được kể đến bên trên có lẽ sẽ khó mà qua được vòng duyệt lại code.Tuy nhiên, nếu bạn là một lập trình viên web JavaScript hay PHP, bạn có rất nhiều mệnh đề import/use trên gần như tất cả các file. Rất nhiều lập trình viên không kiểm tra phần này bởi họ chỉ cuộn đến phần mà họ nghĩ là có vấn đề.
Đây là lúc mà bạn phải dùng đến dependencies (các phần phụ thuộc) để reo rắc nỗi kinh hoàng cho những ai dám chạm vào code của bạn.
Tưởng tượng bạn có một vài UserSubscriptions view trong React. Tạo một file với hàm helper calculateTimeToSubscriptionEnd. Tuyệt. Giờ đặt file này ở đâu được ? Trong một thư mục chứa tất cả các domain logic liên quan đến lượt đăng kí thuê bao hay thanh toán? Xời, ai lại làm thế ? Tốt hơn là cứ đặt nó trong view mà bạn vừa tạo ra !
Đây là một nước đi trước thời đại bởi khi bạn đã làm admin panel (và cả Subscriptions nữa), không ai có thể cản bạn import hàm helper vào các user view. Và có lẽ sẽ chẳng ai để ý đâu, bởi gần như mọi người không bao giờ kiểm tra danh sách import. Bằng cách này bạn có thể ghép 2 module không liên quan gì đến nhau và khiến lập trình viên nào muốn thay đổi hay tái cấu trúc code của bạn phải vò đầu bứt tóc. Và không gì có thể khiến các lập trình viên tức điên hơn là một dự án có cấu trúc tệ hại.
Có thể bạn sẽ nghĩ, “Trông có vẻ cũng không khó lắm”. Lập trình viên non kinh nghiệm sẽ không thể giải quyết được vấn đề này nhanh chóng được. Họ sẽ phải vật lộn với mớ hổ lốn mà họ vừa tìm ra, nghĩ rằng chắc là nó quan trọng nên phải để nguyên đấy. Và sẽ rất đau đớn khi BẤT CỨ LÚC NÀO một lập trình viên mới phải cố vắt óc để hiểu được cấu trúc ứng dụng. Và sẽ càng bực mình hơn khi dev phải cập nhật hay xóa cái gì liên quan đến hàm đó. Một mớ hỗn độn nho nhỏ làm tổn thương tất cả mọi người cho tới khi một người hùng xuất hiện và sửa nó. Có lẽ người ấy sẽ là bạn vào một ngày nào đó
Thói quen xấu số 4: Làm tất cả các hàm giống nhau vận hành khác nhau.
Bạn có phải là một người có đầu óc sáng tạo và một tâm hồn nghệ sĩ ? Đây sẽ là phương thức “tra tấn” ưa thích dành cho bạn.
Thế giới này rất khó lường và không ai nói rằng mọi thứ phải vận hành như nhau. Và cũng không ai nói rằng sự nhất quán và có thể đự đoán là chìa khóa cho một trải nghiệm lập trình tốt hay một dự án thành công ? Ờ thì cũng có nhiều người nói vậy nhưng đừng có nghe theo, OK?
Chúng ta sẽ phá hỏng ngày đẹp trời của ai đó bằng cách làm cho các hàm tương tự nhau trong codebase hoạt động hơi khác nhau một chút.
Ví dụ, bạn có các hàm validation trả về giá trị true nếu dữ liệu hợp lệ và một string thông báo lỗi khi có có gì đó không ổn. Nếu như trình xác nhận mà bạn thêm vào trả về false hoặc không xác định khi dữ liệu đi qua vẫn đúng ? Điều này sẽ phá vỡ kế hoạch viết xử lý form của ai đó. Tốt…
Bạn cũng có thể chấp nhận các đối số của các dạng hoàn toàn khác nhau trong tất cả các hàm. Hay giống như meme trên đây. Hãy để một chỉ số chấp nhận user ID nhưng số khác lại chấp nhận cả đối tượng là người dùng (Kể cả khi chúng chỉ cần ID). Hay có lẽ bạn sẽ tìm ra cách để chấp nhận cả email của người dùng ? Lập trình viên nào mà làm việc theo sau bạn thì sẽ không được vui vẻ lắm đâu.
Cá là các bạn còn nghĩ ra nhiều cách hay hơn nữa, vậy tại sao không khiến mọi thứ ngẫu nhiên và khó đoán ? Và cũng đừng nghĩ về toàn cảnh của codebase dự án, mà hãy thêm niềm vui vào từng file riêng biệt. Hay nói cách khác: đừng làm một kĩ sư, hãy làm một nghệ sĩ ! Đảm bảo là các lập trình viên khác sẽ ghét bạn đến tận xương tủy. Nhưng hiển nhiên đấy là do bạn đang đi trước thời đại mà thôi.
Thói quen xấu số 5: Copy code ra khắp nơi
Cứ thử đi và đừng mong có ai muốn làm việc cùng bạn nữa.
Đừng tách riêng bất kỳ common logic nào vào các hàm, lớp hay thành phần khác nhau. Cứ copy dòng lệnh bạn cần vào giữa các file.
Code của bạn là quan trọng và cực kì hoàn mĩ , vậy nên hãy khiến cho mọi người được chiêm ngưỡng nó trong suốt dự án. Hãy để nó được tỏa sáng !
Nhưng mà như bạn thấy, đấy không phải là lý do duy nhất mà bạn muốn nhân bản code của mình lên. Trong trường hợp có bất cứ cập nhật nào, nó buộc các lập trình viên phải tạo thay đổi trong nhiều file cùng lúc. Tuyệt vời hơn, ai đó có thể (và sẽ, nếu không kiểm tra kĩ dự án) bỏ lỡ một hoặc vài sự cố của logic được copy và sẽ phải kiểm tra lại đến lần thứ 2 hoặc thậm chí là thứ 3. Và còn gì vui hơn là đi tìm cùng một dòng code trong hàng trăm file của codebase dự án ? Hẳn là đồng nghiệp của bạn sẽ rất vui đấy.
Hãy nhớ rằng tạo ra một trừu tượng (abstraction) tốt là rất tốn công và tốn thời gian nên hãy cứ bỏ qua đi mà copy code vào bất cứ chỗ nào mà bạn cấn. Người duyệt code của bạn sẽ hiểu mà. Nếu không thì bạn vẫn có thể dành thời gian để giải thích cho họ hiểu được tầm quan trọng của việc tạo ra những bản sao cho dòng code quý báu của bạn. Tự tin lên, bạn có thể làm được!
….Mà thôi, vui vừa vừa chứ đừng vui quá.
Bài viết này chỉ mang tính chất giải trí. ĐỪNG BAO GIỜ thử làm những việc trên.
Thật đấy.
Mà ngược lại:
-
Hãy đặt tên trong code của bạn một cách rõ ràng và sạch sẽ,
-
Viết code một cách đơn giản và dễ hiểu để bất kì ai cũng có thể cùng làm việc được.
-
Giữ cho cấu trúc dự án được gọn gàng,
-
Đừng quên viết các giao diện đồng nhất và dễ đoán,
-
Tách riêng common logic bất cứ khi nào có thể mà không làm mất đi sự minh bạch của code.
Và còn nữa, hãy luôn đối xử tốt với các đồng nghiệp của bạn.
Có một câu nói trong cộng đồng lập trình rằng bạn nên viết code như thể lập trình viên làm việc sau bạn là một sát thủ. Bạn không muốn bị một sát thủ ghét, đúng không? Nhưng riêng với mình thì:
Bạn nên viết code như thể người tiếp theo làm việc với nó là chính bạn.
Trong lần tới bạn code, hãy tự hỏi bản thân rằng: “Mình có vui vẻ khi thấy lại những dòng code viết đã lâu mà mình còn quên mất nó làm được những gì”?
---
HỌC VIỆN ĐÀO TẠO CNTT NIIT - ICT HÀ NỘI
Học Lập trình chất lượng cao (Since 2002). Học thực tế + Tuyển dụng ngay!
Đc: Tầng 3, 25T2, N05, Nguyễn Thị Thập, Cầu Giấy, Hà Nội
SĐT: 02435574074 - 0383.180086
Email: hello@niithanoi.edu.vn
Fanpage: https://facebook.com/NIIT.ICT/
#niit #niithanoi #icthanoi #hoclaptrinh #khoahoclaptrinh #hoclaptrinhjava #hoclaptrinhphp #java #php #python