Trong bài viết này, tôi sẽ chia sẻ những gì bản thân đã tích lũy để cải thiện kỹ năng code JavaScript của mình, những gì tôi đã áp dụng và đã làm để tối ưu code đem đến hiệu quả trong các dự án đang làm. Hãy cùng theo dõi nhé.
Editor
Hiện tại, có vô số loại editor trên thị trường và tôi đã từng rất phân vân vì không biết chọn loại nào.
Với tôi, ngoại trừ code Android phải sử dụng Android Studio hoặc iOS bằng Xcode, tôi chủ yếu chỉ sử dụng Visual Studio Code.
Đây là một trình soạn thảo được phát triển bởi Microsoft. Vâng, Microsoft Microsoft, nghe có vẻ tốt !!! Nó hỗ trợ hầu hết các ngôn ngữ, vô số plugin bổ sung, đề xuất code AI, giao diện đẹp ...
Trước đây, tôi chỉ sử dụng Sublime Text [VSCode không phổ biến tại thời điểm đó]. Hàng tấn plugin [mà tôi sẽ nói bên dưới] như tự động phát hiện và sửa lỗi, format code, git lens, thiết bị đầu cuối, ... đã tiết kiệm cho tôi rất nhiều thời gian vì tôi không còn phải sửa các lỗi nhỏ thường gặp khi lập trình nữa.
Nếu bạn lập trình PHP, bạn sẽ thích PHPStorm. Python, bạn sẽ thích PyCharm. Thật đúng là những trình soạn thảo [IDE] này rất mạnh nhưng chỉ dành cho một ngôn ngữ. Tôi là một Nhà phát triển Fullstack, với JavaScript, HTML, PHP, NodeJS và React Docker, thì tôi sử dụng VSCode vì nó cực kỳ mạnh, hỗ trợ rất nhiều plugin, đặc biệt là chế độ tự động rất thông minh. Tôi thích.
Yêu em ESLint từ cái nhìn đầu tiên
Một trong những điều khiến tôi mất nhiều thời gian và bực bội nhất là lỗi cú pháp. Các lỗi như không khai báo biến / hàm, con trỏ null, thiếu dấu,... Khi dữ liệu của chúng tôi lớn hơn, đồng nghĩa với việc tôi phải đọc hàng tá tệp cùng một lúc, đầu óc mụ mị, bàn tay run rẩy gõ từng dòng code , dẫn đến việc bỏ qua một số thứ và phạm sai lầm.
Khi tôi sử dụng ESLint, đây là một plugin giúp tìm lỗi, kiểm tra cú pháp, mã định dạng, từ đó giảm lỗi khi lập trình và giúp code trông đẹp hơn khi được định dạng theo các tiêu chuẩn phổ biến trên thế giới. ESLint hỗ trợ nhiều anh em như: JavaScript, React, Vue,...
Đặc biệt là sử dụng ESLint với VSCode, đây được gọi là cặp đôi hoàn hảo. Gõ code đến đâu sẽ được kiểm tra lỗi / cú pháp ngay lập tức và đề xuất về cách sử dụng các hàm và biến cho tối ưu luôn. Ngoài ra còn có code định dạng tự động, trời ơi, tôi thích nó.
Ngoài ESLint, còn có Prettier được sử dụng để định dạng code, nhưng tôi thích ESLint hơn vì nó hỗ trợ phát hiện lỗi và đề xuất code tối ưu.
Cấu trúc thư mục tối ưu
Gần đây tôi đã thuyết phục bản thân và tự nói với mình rằng: Đừng cố gắng tối ưu hóa cấu trúc dự án ngay từ đầu
Trước đây, khi bắt đầu một dự án, dù là lớn hay nhỏ, tôi luôn dành nhiều thời gian để cố gắng chọn một cấu trúc dự án tối ưu. Tôi google để đọc tất cả các loại "cấu trúc thư mục của NodeJS", "cấu trúc mã ReactJS". Nhưng sau đó tôi vẫn tự hỏi liệu điều này có tối ưu hay không, tôi có nên chọn framework để viết code không?.
Và tôi cũng nhận ra rằng mặc dù lúc đầu tôi đã cố gắng tuân theo một cấu trúc được cho là tốt, nhưng chỉ vài ngày sau đó, code của tôi đã biến thành một mớ hỗn độn. Bởi vì hệ thống của tôi chưa đáp ứng được, dù code có đẹp đến mấy cũng sẽ tan tành mây khói thôi.
Đừng suy nghĩ quá nhiều về việc chọn kiến trúc nào, cách tổ chức nó ngay từ đầu. Hãy chọn một hướng hoặc một thư viện, framework và bắt tay vào làm việc, thực hiện và cải tiến nó. Thế thôi.
Console.log bất cứ chỗ nào có vấn đề
Tôi rất chắc chắn console.log là thứ tôi sử dụng
nhiều nhất khi lập trình với JavaScript. Mục đích chính của việc này là để xem liệu dữ liệu tại vị trí bạn quan tâm có thực sự đúng hay không.
Cá nhân tôi nghĩ rằng lập trình, bất kể ngôn ngữ nào, chủ yếu xoay quanh dữ liệu, vì vậy nếu bạn thấy bất kỳ code nào có vấn đề, có thể không đúng, bạn nên dùng console.log để check lại.
Cũng có nhiều người nói rằng debugger trông chuyên nghiệp hơn. Chrome cũng hỗ trợ đặt Debug trong các dòng code giúp bạn biết rõ hơn. Trên thực tế,cá nhân tôi
thấy không cần thiết, console.log cũng có thể nhận biết LOC và sử dụng console.log nhanh hơn, thuận tiện hơn. Bạn biết không, tôi đã xem hướng dẫn của nhiều lập trình viên nổi tiếng thế giới từ Google đến Facebook, họ vẫn sử dụng console.log
Nhưng bạn cũng nên lưu ý rằng khi sử dụng console.log xong, hãy kiểm tra lại, sau đó xóa đi, đừng dại mà đưa nó vào git nhé :]]
Comment đúng lúc đúng chỗ
Trong khi lập trình, sẽ có nhiều lần chúng ta có code dài, phức tạp. Tôi sợ rằng sau một thời gian dài, vào một ngày không đẹp trời tôi đọc lại nó, tôi sẽ không biết code này đang làm gì nữa. Và thực lòng, tôi cũng muốn những người đến sau có thể hiểu những gì tôi đã viết [nếu lỡ như tôi có nghỉ việc chẳng hạn].
Việc để lại comment là vô cùng cần thiết, đặc biệt là khi dự án có nhiều người làm việc cùng nhau. Hơn nữa, đồng đội của tôi cũng không muốn hỏi hoài mỗi lần họ không hiểu code của bạn đâu. Họ cũng rất bận rộn để sửa một tấn lỗi mà tester đưa cho. Dành 1 chút thời gian để viết comment là giúp chính mình và những người khác tiết kiệm thời gian để làm được nhiều việc có ích hơn.
Nhưng bình luận cũng phải hợp lý và dễ hiểu nha. Không cần thiết phải bình luận về mọi thứ. Đôi khi nó sẽ khiến code của bạn khó đọc và khiến người khác "chíu khọ" đấy
Khi viết mã, tôi sẽ chọn tên của biến / hàm sao cho dễ hiểu, đừng để một lớp / hàm dài xử lý quá nhiều. Thay vào đó, tôi chia thành các lớp / chức năng nhỏ hơn [nhưng không phân chia quá nhiều, phải hợp lý để không bị đau mắt nữa]. Và chỉ nhận xét khi bạn cảm thấy cần thiết, hãy luyện viết code sao cho đoạn code đó có thể tự giải thích. Người khác chỉ cần đọc và biết đoạn code đó dùng để làm gì.
Sử dụng ES6,7,8,9
JavaScript là một ngôn ngữ phát triển rất nhanh cùng với việc bổ sung nhiều chức năng / thư viện có sẵn. Theo như tôi biết, hàng năm luôn có sự xuất hiện của các tiêu chuẩn JavaScript gọi là ECMAScript hoặc ES. Mỗi tiêu chuẩn này bao gồm một tập hợp các tính năng mới được tích hợp trong JavaScript.
2015 ECMAScript 6 [ES6]
2016 ECMAScript 7 [ES7]
2017 ECMAScript 8 [ES8]
2018 ECMAScript 9 [ES9]
2019 ECMAScript 10 [ES10]
Vì vậy, nếu chúng ta tận dụng sức mạnh của ECMA, code của chúng ta sẽ đẹp hơn, được tối ưu hóa và trông ngầu hơn nhiều so với việc chỉ sử dụng for and if, while loops,...
Dưới đây tôi có một vài ví dụ về các hàm / toán tử tôi sử dụng nhiều nhất khi lập trình:
Async / await giải cứu thế giới
Kể từ ES6 [2015], async / await đã được giới thiệu như là một thay thế cho Promise / callbacks để xử lý các hoạt động không đồng bộ. Async / await giúp chúng ta viết mã không đồng bộ trông giống như đồng bộ hóa, code chạy từng dòng, trông rất gọn gàng.
Ví dụ thế này:
async function test [] {
try {
const users = await axios.get['/users']
const addresses = await axios.get['/addresses']
} catch [error] {
console.log[error]
}
}
test[]Có một số lưu ý:
- Await luôn đi kèm với async
- sử dụng try / Catch để bắt lỗi xử lý các hoạt động trong chức năng async
- Bản chất của await là nó sẽ đợi cho đến khi Promise trả về giá trị, vì vậy đôi khi sử dụng await nhiều sẽ khiến ứng dụng bị chậm.
Một điều tuyệt vời khác khi sử dụng async / await thay vì Promise / Callback thông thường là khi sử dụng try / Catch để bắt lỗi async / await. Nó cũng bắt tất cả các lỗi khác bên trong try / Catchblock, không chỉ async / await.
Cải thiện chất lượng code với Typescript
Khi tôi mới bắt đầu lập trình với C, sau đó là Java. Chúng là những ngôn ngữ khá mạnh và yêu cầu code cực kỳ nghiêm ngặt. Yêu cầu định nghĩa rõ ràng và đầy đủ về kiểu dữ liệu [chuỗi, boolean,…] hoặc các đặc tả truy cập [công khai, riêng tư, được bảo vệ,…]. Nói chung là mệt lắm vì chả biết cái này là public hay private, kiểu dữ liệu của nó là gì, cứ chạy cho đến khi báo lỗi...
Sau khi chuyển sang JavaScript [hoặc PHP, Python], nó
đã được đơn giản hóa rất nhiều vì không cần biết kiểu dữ liệu là gì. Chỉ cần khai báo biến và sử dụng:
let x = 1
const test = 'This is a test'
const arr = [1, 2, 3, 4, 5]Đây cũng là một trong những điều khiến tôi yêu thích JS ngay từ đầu vì cú pháp rất “phóng khoáng”, ít lộn xộn, code trông sạch và đẹp. Nhưng đời không như là mơ, dần dần tôi nhận ra rằng khi dự án có nhiều người, hoặc sau khi code một thời gian rồi quay lại đọc. Thật là rối. Vì tôi không biết biến này là gì, nên hàm này sẽ trả về kiểu dữ liệu nào? …
const var1 = db.column1
const var2 = db.column2
const var3 = db.column3
const var4 = db.column4Vậy phải làm gì đây? Tất nhiên lại là console.log rồi.
const var1 = db.column1
console.log[var1] // -> string
const var2 = db.column2
console.log[var2] // -> boolean [true/false]
const var3 = db.column3
console.log[var3] // -> number
const var4 = db.column4
console.log[var4] // -> arrayTốn thời gian kinh khủng.
Typescript giải quyết vấn đề này như thế nào?
Typescript, theo ý kiến của tôi, là một "phiên bản nâng cấp" của JavaScript. Lúc này, code JavaScript của chúng ta sẽ có các loại được xác định rõ ràng [chuỗi, boolean, số,…], các hàm truy cập có thể truy cập [công khai, riêng tư],… và nhiều thứ khác. Code được viết bằng Typescript sẽ được biên dịch thành JavaScript đơn giản, vì vậy chúng ta có thể chạy như bình thường, không cần đến các đoạn code Typescript chuyên dụng hay bất cứ thứ gì khác. Hãy xem ví dụ sau:
class Student {
fullName: string;
constructor[public firstName: string, public middleInitial: string, public lastName: string] {
this.fullName = firstName + " " + middleInitial + " " + lastName;
}
}
interface Person {
firstName: string;
lastName: string;
}
function greeter[person: Person] {
return "Hello, " + person.firstName + " " + person.lastName;
}
let user = new Student["Jane", "M.", "User"];Hiện tại, TypeScript đang là xu hướng trong dân lập trình JavaScript. Các thư viện hoặc framework [Angular, React hoặc Vue] chú ý đến việc hỗ trợ cho TypeScript. Dành cho bạn nào chưa biết: Vue 3 là 100% kiểu viết lại từ typescript. Đồng thời TypeScript do Microsoft phát triển nên bạn yên tâm về chất lượng cũng như sự hỗ trợ nhé.
CI/CD — Code -> Test->Deploy
Automation test
Hãy nghe tôi, dự án bạn đang làm sớm muộn gì cũng sẽ tan tành nếu không có auto test.
Cách tốt nhất để đối diện đó là vừa làm vừa cải thiện cùng một lúc. Hãy xác định là dành 20% thời gian của bạn để cải tiến.
CI / CD - Kiểm tra và triển khai liên tục
CI / CD [Tích hợp liên tục / tích hợp liên tục], đây là xu hướng hiện nay, một cách mới để giúp ta viết code, kiểm tra và triển khai tự động và liên tục.
Trên thực tế hầu như các công cụ CI / CD được tích hợp vào Github, GitLab, BitBucket. Vì vậy, bạn không cần phải lo lắng về nó. Công việc của bạn là viết code sau đó đẩy code lên, các nền tảng DevOps [Github, gitlab, bitbucket] sẽ đảm nhiệm phần còn lại.
Kết luận
Tạm thế đã nhé. Hi vọng những kinh nghiệm tôi chia sẻ có ích đối với sự nghiệp của các bạn. Hẹn gặp lại trong những bài tiếp theo.
Tham khảo: medium.com