Các mẫu từ các ngôn ngữ và khung khác để nâng cao các dự án giao diện người dùng của bạn

Tôi đã lập trình được mười hai năm và đã làm việc với nhiều ngôn ngữ. Chúng bao gồm C , C++ , Java , Python , C# và cuối cùng là JavaScript . Mỗi ngôn ngữ hoặc khuôn khổ có quy tắc riêng của mình. Ví dụ: Rust sử dụng trường hợp con rắn cho tên hàm.

Tuy nhiên, có một số quy tắc, công cụ và khuôn mẫu mà tôi ngày càng đánh giá cao. Tôi kết hợp chúng vào các ứng dụng giao diện người dùng của mình. Những quy tắc này chỉ cộng hưởng với tôi nhiều hơn và làm cho quá trình viết mã trở nên suôn sẻ hơn. Dưới đây là một vài điều mà tôi đặc biệt thích:

Lập trình chức năng

Mẹo đầu tiên của tôi đến từ C, ngôn ngữ đầu tiên tôi học. Bạn có nhớ khi chúng ta viết React với các lớp không ? Chỉ nghĩ về nó thôi cũng khiến tôi ớn lạnh. Khi React chuyển sang các thành phần chức năng, nó làm cho mã không chỉ dễ đọc hơn mà còn dễ kiểm tra hơn.

Nó cũng phù hợp hơn với các nguyên tắc của Lập trình hàm.

Cách tiếp cận này hoạt động hiệu quả với các khung giao diện người dùng vì chúng thường tập trung vào việc tạo các đoạn mã có thể tái sử dụng. Sử dụng Lập trình chức năng trong phát triển giao diện người dùng luôn là một chiến lược hữu ích để tôi hiểu khái niệm này và cũng để xây dựng các tính năng giao diện người dùng mới.

Tuân theo các nguyên tắc Lập trình chức năng là điều bắt buộc phải có trong mọi ứng dụng giao diện người dùng của tôi.

Nếu bạn chưa quen với Lập trình hàm, tôi thực sự khuyên bạn nên tìm hiểu thêm về nó. Điểm này không nằm ở đầu danh sách này mà không có lý do. Những lợi ích nó có thể mang lại cho quá trình phát triển của bạn là rất đáng kể.

Trình định dạng mã

Khi tôi mới bắt đầu lập trình, tôi không chú ý nhiều đến định dạng mã. Tôi đoán tất cả bắt đầu ở trường đại học, nơi tôi đang học C++ trên IDE CodeBlocks thú vị của mình với chủ đề màu trắng.

Nhìn lại mã cũ của tôi từ năm 2016 trên GitHub , tôi có thể thấy rằng tôi chỉ sử dụng khoảng trắng để định dạng. Tôi đã không sử dụng bất kỳ công cụ nào để tự động xử lý việc này.

Bây giờ, tôi nhận ra đó là một sai lầm. Nếu bạn có thể tự động hóa thứ gì đó trong dự án của mình, thì bạn chắc chắn nên làm như vậy. Bây giờ, tôi luôn thiết lập Prettier và ESLint khi bắt đầu mọi dự án. Nếu không muốn mất nhiều thời gian cho việc này, bạn có thể sử dụng các cấu hình được tạo sẵn như cấu hình từ Airbnb .

Tin tôi đi, bạn sẽ không hối tiếc đâu!

Ồ và đừng quên thiết lập trong IDE của bạn một hành động tự động định dạng khi lưu tệp!

Hành động cam kết trước

Bây giờ bạn đã có các trình định dạng tuyệt vời, hãy tự động hóa chúng! Tôi không thể nhớ chính xác khi nào tôi bắt đầu sử dụng pre-commit hook, nhưng chúng đã giúp ích rất nhiều cho các dự án của tôi. Tại sao phải định dạng thủ công khi nó có thể được tự động hóa trước mỗi lần xác nhận? Các công cụ như husky và lint-staged giúp khả năng tự động hóa này trở nên khả thi.

Kebab-case cho tên tệp

Mặc dù Angular có nhiều người hâm mộ và phê bình, tôi thích tập trung vào mặt tích cực. Angular thường là lựa chọn đầu tiên cho các công ty lớn và các ứng dụng lớn. Tôi nghĩ rằng nhiều quyết định được đưa ra trong Angular là để giữ cho mọi thứ dễ bảo trì.

Đó là lý do tại sao tôi quyết định sử dụng kebab-case cho tất cả các dự án giao diện người dùng của mình. Nó cung cấp một vài lợi ích, như:

• Đơn giản : Tôi không phải lo lắng về việc nên sử dụng pascal case, camel case hay solid case (nếu bạn thích). Với kebab-case, chỉ có một lựa chọn.

• Tính nhất quán : Nếu bạn đang làm việc theo nhóm, việc áp dụng một quy ước đặt tên duy nhất như kebab-case có thể giúp đảm bảo mọi người đều thống nhất và dự án luôn được tổ chức. Đừng quên rằng bạn có thể buộc sử dụng kebab-case thông qua quy tắc eslint bằng gói kỳ lân :

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• Khả năng tương thích đa nền tảng : Các hệ điều hành khác nhau xử lý các tên tệp khác nhau. Ví dụ, Windows không quan tâm đến cách viết hoa, nhưng Linux thì có. Bằng cách sử dụng kebab-case, sử dụng chữ thường và dấu gạch ngang, tôi tránh được mọi sự cố.

• Không có vấn đề về git : Có vấn đề với việc đổi tên tệp từ chữ thường thành chữ hoa trong git. Sử dụng kebab-case, tôi không phải lo lắng về điều đó.

Tôi muốn giữ cho mọi thứ đơn giản. Nếu tôi có thể làm cho cuộc sống của mình dễ dàng hơn và nhận được một số lợi ích từ nó, tôi sẽ làm tất cả.

Sử dụng thẻ cho các loại tệp

Một điều khác mà tôi đã mượn từ Angular là cách họ đặt tên cho các tệp. Angular khuyên bạn nên đặt tên tệp theo cách phản ánh chức năng và loại của chúng. Tôi thấy rằng nó giúp tôi điều hướng và hiểu cấu trúc của dự án dễ dàng hơn. Trong Angular, tên tệp thường có ba phần: vùng tính năng, vai trò của tệp và loại tệp.

Ví dụ: heroes.component.ts cho biết tệp này là một thành phần cho tính năng heroes và đó là tệp TypeScript. heroes.service.ts là một dịch vụ dành cho heroes .

Tôi không phải là một fan hâm mộ lớn của services , nhưng tôi sử dụng một cấu trúc tương tự cho các thành phần React của mình. Đây là một ví dụ:

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

Tôi cũng sử dụng mẫu này cho các móc và chức năng của mình. Mẫu này cũng dạy tôi đặt các bài kiểm tra của mình bên cạnh các tệp liên quan đến chúng.

Tự động tạo mã

Mẫu tôi đã đề cập trước đây rất hữu ích, nhưng chúng ta có thể làm cho nó tốt hơn nữa bằng tự động hóa. CLI góc cho phép người dùng tạo mã tự động và tôi luôn sử dụng plop để làm điều tương tự. Hệ thống mẫu của Plop rất mạnh, nhưng quan trọng nhất là nó tiết kiệm thời gian.

Với tự động hóa, tôi không phải mất nhiều thời gian suy nghĩ về cấu trúc cơ bản của một thành phần. Nhiệm vụ này có thể được tự động hóa, cho phép tôi tập trung vào những gì tôi thực sự muốn làm.

Sử dụng 'Miền'

Tôi sẽ không giải thích chi tiết domain là gì ở đây. Nếu bạn muốn tìm hiểu thêm về nó, tôi khuyên bạn nên đọc bài viết này . Hiện tại, tôi đang làm việc với một nhóm gồm các nhà phát triển toàn diện và chúng tôi nhận thấy rằng việc có một lớp miền trong dự án giao diện người dùng của chúng tôi thực sự hữu ích.

Đó là nơi chúng tôi đặt tất cả các loại và hoạt động chính của chúng tôi. Nó đóng vai trò là 'nguồn sự thật' trong ứng dụng của chúng tôi.

Nếu bạn muốn xem cách tôi xử lý 'miền' trong ứng dụng của mình, bạn có thể xem bài viết này . Tôi dành rất nhiều thời gian để mô tả chủ đề này.

Kiểm tra kiến trúc của bạn

Khi làm việc với Kotlin , chúng tôi đã từng gặp sự cố khi logic bị trộn lẫn giữa nhiều lớp, chẳng hạn như sử dụng một loại được xác định trong kho lưu trữ bên trong miền của chúng tôi. Đây là điều không nên từ quan điểm Kiến trúc sạch, nhưng mọi người đều phạm sai lầm.

Đó là khi chúng tôi phát hiện ra ArchUnit , một công cụ để kiểm tra đơn vị kiến trúc của chúng tôi. Về cơ bản, nó kiểm tra xem chúng tôi có tuân thủ đúng kiến trúc của chúng tôi hay không.

Nếu bạn đang duy trì một kiến trúc nhất định, sẽ rất hữu ích nếu có một công cụ để kiểm tra xem nó có bị hỏng tại một số điểm hay không. Một công cụ như tàu tuần dương phụ thuộc có thể là vô giá về mặt này.

Và điều đó kết thúc danh sách thiết yếu của tôi về các mẫu từ các ngôn ngữ và khuôn khổ khác để nâng cao các dự án giao diện người dùng của bạn. Tôi hy vọng bạn thấy thông tin này hữu ích và ít nhất một trong những chiến lược này đã truyền cảm hứng cho bạn áp dụng nó vào công việc của chính mình!