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 , , , , và cuối cùng là . Mỗi ngôn ngữ hoặc khuôn khổ có quy tắc riêng của mình. Ví dụ: sử dụng cho tên hàm. C C++ Java Python C# JavaScript Rust trường hợp con rắn 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 ? 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. React với các lớp không 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 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ể. thêm về 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 thú vị của mình với chủ đề màu trắng. IDE CodeBlocks Nhìn lại , 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. mã cũ của tôi từ năm 2016 trên GitHub 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 và 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ừ . Prettier ESLint 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ư và giúp khả năng tự động hóa này trở nên khả thi. husky lint-staged Kebab-case cho tên tệp Mặc dù 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ì. Angular Đó 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ư: : 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. Đơn giả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 : Tính nhất quán kỳ lân 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ], : 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ả năng tương thích đa nền tảng : 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 đó. Không có vấn đề về git 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ụ: cho biết tệp này là một thành phần cho tính năng và đó là tệp TypeScript. là một dịch vụ dành cho . heroes.component.ts heroes heroes.service.ts heroes Tôi không phải là một fan hâm mộ lớn của , 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ụ: services 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. tự động và tôi luôn sử dụng để 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. CLI góc cho phép người dùng tạo mã plop 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 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 . 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 trong dự án giao diện người dùng của chúng tôi thực sự hữu ích. domain bài viết này miền Đó 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 . Tôi dành rất nhiều thời gian để mô tả chủ đề này. bài viết này Kiểm tra kiến trúc của bạn Khi làm việc với , 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. Kotlin Đó là khi chúng tôi phát hiện ra , 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. ArchUnit 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ư có thể là vô giá về mặt này. tàu tuần dương phụ thuộc 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!