Cảnh báo: bài viết này chứa những kiến thức khá cao, không dành cho newbie. Cụ thể tôi sẽ đề cập những thứ mà 1 cuộc bàn luận Node.js thông thường sẽ không nói đến. Thêm vào đó tôi sẽ không cầm tay chỉ việc. LMGTFY.

Chúng ta sẽ khám phá các lỗi thông thường mà mọi người hay mắc phải khi làm việc với 1 project mới, đặc biệt với các project đặt nặng các vấn đề hiệu năng, mở rộng và deadline.

Vài người thích 1 ứng dụng web từ đầu đến cuối. Nhận yêu cầu từ khách hàng, lên kế hoạch, sắp xếp thời gian và bắt đầu. Xác định model, xây dựng phần backend, xây dựng frontend, thêm tính năng, xử lý vấn đề, thêm nhiều tính năng nữa,...

Kết quả bạn nhận được là gì? Một mớ hỗn độn (thuật ngữ gọi là spaghetti code -code mì ống) mà hễ bạn đụng vào là nó lại lỗi.

Nếu bạn thấy việc này nghe có vẻ quen quen, thì hãy tập trung lắng nghe. Hãy đào sâu vào các vấn đề mà các developer thường chạm trán, các vấn đề mà ảnh hưởng đến hiệu năng, tính mở rộng, cũng như thời gian quý báu của lập trình viên Javascript full-stack.

  1. Lựa chọn database kém.
  2. Sử dụng không đúng mức các build tool.
  3. Don't repeat yourself (DRY).
  4. Bỏ qua style guide.
  5. Quản lý dependency kém.

1. Lựa chọn database kém

Hiện nay có rất nhiều hướng stack cho lập trình viên theo đuổi. Tuy nhiên họ lại dần thần thánh hóa stack mình học, dần xem nó như 1 thứ tôn giáo. Họ sử dụng MEAN hay MERN stack, bỏ ngoài tai hoàn toàn lời khuyên sử dụng các relational database. Tôi hiểu sự tiện dụng trong việc sử dụng model của stack để làm prototype cho 1 ứng dụng. Tuy nhiên chỉ cắm đầu làm mà không cân nhắc tất cả các lựa chọn là 1 sự thiếu trách nhiệm trầm trọng, thiếu công bằng cho những người khách hàng.

NoSQL database được thiết kế để xử lý các dữ liệu phi cấu trúc (ví dụ: text, các media post trên mạng xã hội, video, email,...), những thứ chiếm tỉ lệ lớn trong tổng lượng dữ liệu hiện nay.

Trích từ MongoDB website

Vấn đề

Khi bạn mở rộng quy mô ứng dụng, trong MongoDB, bạn tối ưu hóa cho thao tác READ bằng cách lồng object. Tuy nhiên điều này lại trở thành vấn đề hiệu năng cho thao tác WRITE. $

$populate là 1 giải pháp thay thế hợp lí cho SQL JOINS, tuy nhiên 1 lần nữa, hiệu năng lại trở thành vấn đề cần cân nhắc.

Chúng tôi buộc phải nói chuyện với các khách hàng, sau khi nghiên cứu, rằng lựa chọn database ban đầu của họ là nguyên nhân gây ra các vấn đề về hiệu năng. Chúng tôi cũng đồng thời giúp họ chọn ra các relational database khác.

Hãy lập kế hoạch trước tiên, vạch ra giản đồ các yêu cầu cho database, sau đó quyết định loại database nào phù hợp với quỹ thời gian xây dựng ứng dụng, cũng như lưu trữ loại dữ liệu phù hợp.

2. Sử dụng không đúng mức các build tool

Các tool giờ đã trở thành người bạn thân quen của các lập trình viên, giúp gia tăng năng suất làm việc. Với ứng dụng Java enterprise lớn, restart server có thể mất đến vài phút. Khi được làm quen với môi trường build của Javascript, tôi đã phát khóc với sự nhanh chóng của nó.

Vấn đề

Rất nhiều nhóm đã không tận dụng được khả năng của build tool đúng cách. làm tác động đến tốc độ phát triển của ứng dụng. Gần đây tôi đã viết 1 bài viết động chạm đến tính phổ biến của các build tool. Nhưng cho dù bạn chọn sử dụng tool nào đi nữa, nó nên thực hiện được các task chính. 

Đảm bảo rằng build tool bạn sử dụng thực hiện được các task sau:

  • Minify các file CSS và JS cho production build.
  • Minify các ảnh.
  • Sử dụng các file source map để các bộ tiền xử lý biên dịch code, phục vụ cho quá trình debug ở môi trường development.
  • Linting - Gulp/Webpack.
  • Chạy các test.
  • Inject các dependency.
  • Inject file CSS và JS vào trình duyệt trong quá trình modification.
  • Sử dụng biến môi trường.

Bạn nên chú ý đến CI với các server development. Đọc thêm ở bài viết này, về triển khai Jenkin với Docker.

Tham khảo các khóa học lập trình online, onlab, và thực tập lập trình tại TechMaster

3. Don't repeat yourself (DRY).

Hẳn bạn đã quen thuộc với định luật Don't Repeat Yourself - Đừng lặp lại chính mình.

Vấn đề

Code bốc mùi, code mì ống (spaghetti code),... Đây là những việc quá bình thường trong cuộc sống của các lập trình viên. Hãy chắc chắn rằng bạn nhận ra và tối ưu chúng trước khi chúng trở nên bốc mùi hơn nữa.

Hẳn bạn sẽ phản đối: "Nhưng mà Eric. Chúng ta đang nói về việc bắt đầu 1 ứng dụng Node.js từ đầu cơ mà. Ở đâu ra cái công việc refactor này vậy?".

Chúng tôi đã từng trải qua các project kéo dài trong vòng vài tháng trước khi hoàn toàn vượt ra ngoài tầm kiểm soát của chúng tôi vì sự thiếu trách nhiệm hoặc giám sát từ các lập trình viên. Chính điều này dẫn đến cái mớ hỗn độn code trên.

Thêm nữa, 1 trong những điều tuyệt vời khi sử dụng Javascript ở cả client và server là cơ hội tái sử dụng code.

Module hóa code. Đừng tối ưu hóa code quá sớm hay quá muộn. Nhưng cũng đừng bao giờ bỏ qua các sự thay đổi nhỏ. Một chút lưu tâm, và ứng dụng của bạn sẽ phát triển nhanh hơn, lỗi sẽ ít xảy ra hơn.

4. Bỏ qua style guide

Bất cứ ai cũng đều muốn nhảy thằng vào code, xây dựng ứng dụng ngay mà không quan tâm đến các vấn đề khác. Bạn sẽ nhận ra rằng khi bạn gần kết thúc project, bạn sẽ càng gặp nhiều đoạn code thiếu nhất quán về styling.

Vấn đề

Không sử dụng 1 style guide chuẩn cho thiết kế frontend là 1 cách đảm bảo rằng bạn sẽ tạo ra 1 sự thiếu nhất quán trên phần HTML. Có lẽ với tư cách lập trình viên, bạn sẽ bỏ qua nó, cho rằng nó không đáng kể. Tuy nhiên nó có thể là nguyên nhân gây ra sự thiếu nhất quán trong style, hoặc tệ hơn, sẽ buộc bạn phải tạo style CSS mới để "hack".

Nếu bạn có thể, hãy bắt đầu với 1 style guide gồm HTML và Javascript được đóng gói thành các block, phục vụ phía frontend. Đấy chính là lý do Bootstrap và Foundation trở thành các ông lớn như hiện nay. Tuy nhiên đừng bê y nguyên code vào mà không chỉnh sửa. Hẳn bạn cũng không muốn thấy trang web của bạn trông chẳng khác gì trang admin Bootstrap, đúng không?

5. Quản lý dependency kém

yarn add jquery. yarn add sẽ thêm các plugin jquery theo cách không thể tiện hơn. Cần thêm các thao tác với array? yarn add lodash. yarn add package, từ đó lập trình viên chỉ cần sử dụng các function.

Giờ thì hãy cùng nhìn cái file package.json (hay Bower) đang phình to ra nhé.

Vấn đề

Bạn sẽ nhận ra vấn đề ngay thôi. Bạn thêm vào nhiều các dependency, làm cho ứng dụng trở nên phình ra. Bạn sử dụng nhiều dependency, dẫn đến nhiều request đến server, hay các file asset được ghép lại sẽ rất lớn.

Lúc bắt đầu quá trình development, hoàn toàn dễ hiểu khi bạn cần truy cập đến toàn thư viện mà bạn đã import do không biết lúc nào sẽ cần thêm 1 function khác. Tuy nhiên bạn dự định theo dõi chúng như thế nào, một khi cần tối ưu?

Lúc này, điều nên làm lại là có 1 tập các thư viện được module hóa. Hẳn nhiên các thư viện JS cũng cung cấp các phiên bản nhỏ gọn, với việc bỏ đi 1 số chức năng.

Điều quan trọng bạn cần nhớ đó là hãy theo dõi sát sao những thứ bạn sử dụng, cách mà bạn sử dụng chúng.

Kết luận

Khởi đầu 1 dự án luôn là 1 quá trình cân bằng giữa 2 việc: tiến triển nhanh và tối ưu. Bạn hẳn muốn chắc rằng ứng dụng của bạn sẽ chạy kịp tiến độ thời gian mà vẫn đảm bảo hiệu năng tốt. Hãy giữ vững sự cân bằng đó với các kinh nghiệm:

  • Lựa chọn database tối ưu, phù hợp - relational DB và NoSQL.
  • Thiết lập tốt quá trình build setup - đảm bảo include CI vào server dev.
  • Module hóa code và thực hiện DRY.
  • Sử dụng 1 style guide frontend.
  • Sáng suốt khi thêm các dependency.

Bài viết được dịch từ: https://blog.qmo.io/common-problems-when-developing-a-node-js-web-application/?utm_source=nodeweekly&utm_medium=email#4ignoringthestyleguide