Laravel hoạt động như thế nào với các bản ghi cơ sở dữ liệu lớn?

Có lẽ bước khó khăn nhất trong sự nghiệp của nhà phát triển là chuyển từ các dự án kiểu CRUD đơn giản trong những năm đầu sang một số công cụ cấp cao với kiến ​​trúc lớn hơn và mức độ trách nhiệm cao hơn đối với chất lượng mã. Vì vậy, trong bài viết này, tôi đã cố gắng liệt kê các câu hỏi (và một số câu trả lời) để suy nghĩ khi làm việc với các dự án Laravel (r) lớn

Bài viết này sẽ có đầy đủ các liên kết bên ngoài tới nội dung của riêng tôi và tài nguyên cộng đồng, vì vậy vui lòng kiểm tra chúng

từ chối trách nhiệm. Dự án LỚN là gì?

Đầu tiên, tôi muốn giải thích ý nghĩa của từ "lớn". Một số người đo lường rằng số lượng bản ghi cơ sở dữ liệu, chẳng hạn như hàng triệu hàng trong bảng người dùng là lớn. Có, nhưng đó là một cơ sở dữ liệu lớn, không phải bản thân dự án Laravel

Ý tôi là một dự án lớn hơn chủ yếu là số lượng thực thể cần quản lý. Nói một cách đơn giản, dự án của bạn có bao nhiêu Eloquent Model. Nếu bạn có nhiều mô hình, điều đó thường có nghĩa là phức tạp. Cùng với đó, dưới dạng số đo phụ, bạn có thể đếm số lượng tuyến đường hoặc phương thức Bộ điều khiển công khai

Ví dụ từ một dự án mã nguồn mở Monica CRM có hơn 300 dòng mã trong các tuyến đường/web. tập tin php

Với phạm vi công việc lớn như vậy, thường có nhiều nhà phát triển làm việc trong dự án, điều này dẫn đến sự phức tạp trong việc quản lý cơ sở mã

Ngoài ra, một tính năng phi công nghệ thứ ba của một dự án lớn là giá của lỗi. Tôi muốn nhấn mạnh những dự án mà mã của bạn không hiệu quả hoặc bị hỏng có thể khiến tiền thật bị mất. như 30 phút ngừng hoạt động trong một cửa hàng điện tử có thể dễ dàng mất 10.000 đô la cho doanh nghiệp. Hoặc, một số câu lệnh if bị hỏng có thể khiến hàng tá người thực KHÔNG đặt lệnh

Vì vậy, vâng, tôi sẽ nói về những dự án lớn dưới đây

1. Kiểm tra tự động

Trong các dự án nhỏ hơn, thường có ngân sách nhỏ hơn và nỗ lực mạnh mẽ hơn để khởi chạy "thứ gì đó" nhanh hơn, vì vậy các thử nghiệm tự động thường bị bỏ qua dưới dạng "tính năng thưởng"

Trong các dự án lớn hơn, bạn không thể kiểm tra thủ công tất cả các tính năng trước khi phát hành chúng. Bạn có thể kiểm tra mã của riêng mình, vâng, nhưng bạn không biết nó có thể ảnh hưởng như thế nào đến mã cũ do người khác viết. Rất tiếc, bạn thậm chí có thể không biết mã hoặc mô-đun khác đó hoạt động như thế nào vì bạn đang tập trung vào các phần của ứng dụng

Vì vậy, làm cách nào khác để bạn đảm bảo rằng mã được phát hành không gây ra lỗi?

Ngoài ra, quay lại định nghĩa về một dự án lớn hơn - hãy nhớ rằng, giá của lỗi rất cao. Vì vậy, theo nghĩa đen, mã bị hỏng của bạn có thể gây tổn thất tài chính cho doanh nghiệp. Nếu lập luận đó vẫn không thuyết phục được bạn viết mã bằng các bài kiểm tra, có lẽ sẽ không có gì khác

Vâng, tôi biết lập luận điển hình rằng "chúng tôi không có thời gian để viết bài kiểm tra". Tôi có một video đầy đủ về nó

Nhưng đây là nơi bạn cần tìm thời điểm đó. Nó liên quan đến một số giao tiếp. đánh giá thời hạn suy nghĩ về thời gian để viết bài kiểm tra, đồng thời nói chuyện với người quản lý về điều gì sẽ xảy ra nếu bạn không viết bài kiểm tra. Sau đó họ sẽ hiểu và cho phép thêm thời gian. Nếu không, điều đó có nghĩa là họ không quan tâm nhiều đến chất lượng, vậy có lẽ đã đến lúc tìm một công ty khác?

Bây giờ, tôi không nhất thiết phải nói về "phạm vi kiểm tra 100%" hoang đường. Nếu bạn thực sự bị áp lực về thời gian, hãy chọn các chức năng cần kiểm tra để ứng dụng của bạn hoạt động. Như Matt Stauffer đã nói một câu nổi tiếng, "đầu tiên, hãy viết các bài kiểm tra cho các tính năng, nếu chúng bị hỏng, bạn sẽ mất việc". Vì vậy, mọi thứ liên quan đến thanh toán, quyền truy cập của người dùng, tính ổn định của chức năng cốt lõi được sử dụng nhiều nhất

2. Kiến trúc và cấu trúc dự án

Ahh, vâng, một câu hỏi triệu đô. làm thế nào để cấu trúc một dự án Laravel?

Có nhiều mô hình hoặc ý tưởng khác nhau mà bạn có thể làm theo. chia dự án thành các mô-đun, sử dụng phương pháp DDD, chọn một số từ các mẫu thiết kế hoặc chỉ tuân theo các nguyên tắc RẮN. Tất cả chỉ là sở thích cá nhân

Vấn đề là không có viên đạn bạc nào và cách tiếp cận một kích cỡ phù hợp với tất cả. Chẳng hạn, không ai có thể khẳng định rằng tất cả các dự án Laravel lớn hơn phải tuân theo DDD. Ngay cả các nguyên tắc RẮN đôi khi cũng bị coi là không phải là tốt nhất trong một số trường hợp

Nhưng vấn đề rõ ràng. khi cấu trúc dự án của bạn phát triển, bạn cần thay đổi một số thứ và cấu trúc lại các tệp/thư mục/lớp thành một thứ dễ quản lý hơn. Vì vậy, những điều cần thiết bạn nên làm là gì?

Đầu tiên, di chuyển mọi thứ vào các thư mục con và không gian tên mọi thứ tương ứng. Một lần nữa, ví dụ từ Monica CRM khá tốt

Sau đó, đảm bảo rằng các lớp/phương thức của bạn không quá lớn. Không có con số kỳ diệu nào để tuân theo, nhưng nếu bạn cảm thấy rằng mình cần phải cuộn lên xuống quá thường xuyên hoặc dành quá nhiều thời gian để tìm hiểu xem lớp/phương thức đó làm gì, thì đã đến lúc cấu trúc lại và di chuyển các phần của mã sang nơi khác. Ví dụ phổ biến nhất về điều này là các tệp Trình điều khiển quá lớn

Đây chỉ là hai lời khuyên, nhưng chỉ hai thay đổi đó làm cho mã của bạn dễ đọc hơn, dễ bảo trì hơn và thậm chí dễ kiểm tra hơn

Và vâng, đôi khi nó yêu cầu tái cấu trúc các lớp "rủi ro" lớn, nhưng bạn có thể có các bài kiểm tra tự động để kiểm tra mọi thứ, phải không?

3. “Giả dữ liệu” với Nhà máy và Hạt giống

Một chủ đề liên quan đến kiểm thử tự động mà chúng ta đã nói đến. Nếu bạn muốn kiểm tra căng thẳng các tính năng ứng dụng của mình, bạn cần một lượng lớn dữ liệu. Và nhà máy + hạt giống là sự kết hợp hoàn hảo để đạt được điều đó khá dễ dàng

Chỉ cần tập thói quen, khi tạo một mô hình Eloquent mới, hãy tạo một nhà máy và một hạt giống ngay từ đầu. Sau này, bất cứ ai sẽ sử dụng nó trong tương lai để tạo ra một số dữ liệu giả mạo, sẽ cảm ơn bạn rất nhiều

Nhưng nó không chỉ là về thử nghiệm. Ngoài ra, hãy nghĩ về cài đặt mới của ứng dụng của bạn. Các dự án lớn thành công có xu hướng chỉ phát triển lớn hơn, vì vậy bạn chắc chắn sẽ phải giới thiệu các nhà phát triển mới. Họ sẽ phải vật lộn bao nhiêu với quá trình cài đặt và bắt kịp tốc độ, nếu họ không có bất kỳ dữ liệu mẫu nào để làm việc?

Bạn cũng có thể cần phải cài đặt ứng dụng của mình nhiều lần trên nhiều máy chủ khác nhau - cục bộ, dàn dựng, một số môi trường dựa trên Docker, v.v. Bạn có thể tùy chỉnh các hạt giống để chạy trong điều kiện đó là môi trường sản xuất hay địa phương

4. Cấu trúc cơ sở dữ liệu

Mặc dù tôi đã đề cập ngay từ đầu rằng kích thước cơ sở dữ liệu không phải là định nghĩa của một dự án Laravel lớn, nhưng cấu trúc cơ sở dữ liệu là một điều cực kỳ quan trọng đối với hiệu suất và khả năng bảo trì lâu dài.

Những mối quan hệ để sử dụng?

Ngoài ra, các câu hỏi khác. Một bảng lớn hơn hoặc một số bảng nhỏ hơn?

Cố gắng hỏi "bản thân tương lai" của bạn về những truy vấn SQL tiềm năng nào sẽ có trên các bảng DB này và cố gắng viết các truy vấn đó trước

Nói cách khác, hãy nghĩ về mục tiêu cuối cùng và thiết kế ngược cấu trúc từ mục tiêu đó. Nó sẽ giúp bạn "cảm nhận" đúng cấu trúc

Nếu bạn đã có sẵn nhà máy và hạt giống (hãy để ý mẫu về cách các chủ đề trong bài viết này hỗ trợ lẫn nhau?), bạn sẽ có thể dễ dàng mô phỏng cách sử dụng trong tương lai, thậm chí có thể đo lường các tùy chọn A so với B và quyết định xem đâu là lựa chọn đúng. . Thời điểm này thực sự rất quan trọng. thay đổi cấu trúc DB trong tương lai, với một lượng lớn dữ liệu trực tiếp, có lẽ là một trong những thay đổi phức tạp/tốn kém/rủi ro nhất cần thực hiện. Vì vậy, tốt hơn bạn nên đưa ra quyết định tốt trước

Điều đó nói rằng, bạn không nên ngại cấu trúc lại cơ sở dữ liệu nếu có nhu cầu thực sự về điều đó. Di chuyển một số dữ liệu vào một bảng riêng biệt ít sử dụng hơn, thay đổi HasMany thành Đa hình, chọn các loại cột khác, v.v.

Chỉ cần đảm bảo rằng bạn không mất bất kỳ dữ liệu khách hàng nào

5. Gói bên ngoài và nâng cấp Laravel

Khi bạn chọn gói Laravel/PHP nào sẽ đưa vào trình soạn thảo của mình. json, ban đầu nó khá dễ dàng. chỉ cần sử dụng các phiên bản mới nhất của mọi thứ và đảm bảo gói đó hữu ích

Nhưng sau này, khi dự án tồn tại được một hoặc hai năm, cần phải nâng cấp các phiên bản. Không chỉ bản thân Laravel mà cả các gói nữa

May mắn thay, Laravel đã chuyển sang lịch phát hành hàng năm từ 6 tháng (và sau đó đã chuyển bản phát hành Laravel 9 để đồng bộ với Symfony), vì vậy các nhà phát triển không phải đau đầu với 6 tháng một lần nữa

Nói chung bản thân framework này có core khá ổn định, việc nâng cấp lên phiên bản mới tương đối dễ dàng, chỉ mất vài tiếng. Ngoài ra, một dịch vụ có tên Laravel Shift là một trợ thủ đắc lực cho các nhà phát triển muốn tiết kiệm thời gian cho việc này

Nhưng vấn đề phát sinh từ các gói bạn sử dụng

Kịch bản khá điển hình. bạn muốn nâng cấp dự án lên phiên bản Laravel mới, nhưng một vài gói từ tệp trình soạn thảo của bạn chưa phát hành phiên bản mới của chúng để hỗ trợ nâng cấp Laravel đó. Vì vậy, theo kinh nghiệm của tôi, việc nâng cấp dự án diễn ra ít nhất vài tháng sau khi phát hành Laravel chính thức, khi những người tạo gói bắt kịp

Và, có những kịch bản tồi tệ hơn. khi người tạo gói không có thời gian để phát hành bản nâng cấp (hãy nhớ rằng, hầu hết họ làm điều đó miễn phí khi rảnh rỗi) hoặc thậm chí từ bỏ gói. Sau đó phải làm gì?

Tất nhiên, trước tiên, bạn có thể trợ giúp người tạo và gửi Yêu cầu kéo với bản nâng cấp được đề xuất (đừng quên bao gồm các bài kiểm tra tự động). Nhưng ngay cả khi đó, họ cần xem xét, kiểm tra và phê duyệt PR của bạn, vì vậy tôi hiếm khi thấy điều đó xảy ra trong cuộc sống thực. Các gói được duy trì tích cực hoặc gần với trạng thái bị bỏ rơi. Vì vậy, giải pháp hợp lý duy nhất sau đó là rẽ nhánh gói và sử dụng phiên bản của riêng bạn trong tương lai

Tuy nhiên, một quyết định thậm chí còn tốt hơn là suy nghĩ sâu hơn tại thời điểm chọn gói nào sẽ sử dụng. câu hỏi để hỏi là. "Chúng ta có THỰC SỰ cần gói đó không?"

6. Hiệu suất của mọi thứ

Nếu dự án thành công, cơ sở dữ liệu của nó sẽ phát triển với nhiều dữ liệu hơn và máy chủ cần phục vụ nhiều người dùng hơn cùng một lúc. Vì vậy, tốc độ tải trở thành một yếu tố quan trọng

Thông thường, trong cộng đồng Laravel, chúng ta đang nói về việc tối ưu hóa hiệu suất của các truy vấn Eloquent. Thật vậy, đó là không. 1 lý do điển hình của các vấn đề về hiệu suất

Nhưng Eloquent và cơ sở dữ liệu chỉ là một mặt của câu chuyện. Có những thứ khác bạn cần tối ưu hóa cho tốc độ

- Cơ chế xếp hàng. người dùng của bạn không cần đợi 5 phút để nhận email hóa đơn
- Đang tải nội dung giao diện người dùng. bạn không nên phân phát 1 MB CSS/JS nếu bạn có thể giảm thiểu nó
- Chạy bộ kiểm thử tự động. bạn không thể đợi một giờ để triển khai các thay đổi mới
- Cấu hình máy chủ web và PHP. người dùng không nên "xếp hàng chờ đợi" trong khi 10.000 người dùng khác đang duyệt trang web
- vân vân

Tất nhiên, mỗi chủ đề đó là một thế giới riêng biệt để tìm hiểu sâu, nhưng điều đầu tiên bạn nên làm là thiết lập một hệ thống đo lường và báo cáo, để bạn sẽ được thông báo nếu có truy vấn chậm ở đâu đó, lượng khách truy cập tăng đột biến ở một số thời điểm.

7. Quy trình triển khai và thời gian ngừng hoạt động

Trong một dự án nhỏ điển hình, bạn có thể triển khai các thay đổi mới chỉ bằng cách SSH tới máy chủ và chạy một vài lệnh git và artisan theo cách thủ công

Nhưng nếu bạn có lưu lượng truy cập lớn hơn và một nhóm lớn hơn, bạn cần quan tâm đến hai điều
- Triển khai không thời gian chết. để tránh bất kỳ khách truy cập tức giận nào sẽ thấy "triển khai các thay đổi. " màn hình và va chạm cho khách truy cập trước khi triển khai. Có dự án Envoyer chính thức cho việc này và một vài lựa chọn thay thế
- Triển khai tự động. không phải tất cả mọi người trong nhóm của bạn đều có (hoặc nên có) quyền truy cập SSH vào các máy chủ sản xuất, vì vậy việc triển khai phải là một nút ở đâu đó hoặc diễn ra tự động, được kích hoạt bởi một số hành động git

Ngoài ra, hãy nhớ các bài kiểm tra tự động? . Âm thanh meta, tôi biết. Ý tôi là các bài kiểm tra sẽ được tự động chạy trước khi triển khai. Hoặc, trên thực tế, chúng nên được chạy bất cứ khi nào mã mới được đẩy đến nhánh staging/develop

Bạn có thể lên lịch để thực hiện nhiều hành động tự động hơn vào thời điểm đó. Nói chung, tự động hóa quy trình xây dựng/triển khai này được gọi là Tích hợp liên tục hoặc Phân phối liên tục (CI/CD). Nó làm giảm một số căng thẳng khi phát hành các tính năng mới

Gần đây, công cụ phổ biến nhất để đạt được điều đó đã trở thành Github Actions, đây là một số tài nguyên về nó

- Xây dựng, kiểm tra và triển khai ứng dụng Laravel của bạn với GitHub Actions
- Cách tạo CI/CD cho ứng dụng Laravel bằng GitHub Actions

Nhưng nó không chỉ là việc thiết lập các công cụ phần mềm. Quan trọng là yếu tố con người. mọi nhà phát triển nên biết quy trình triển khai và trách nhiệm của họ trong đó. Mọi người nên biết nhánh nào sẽ làm việc, cách cam kết mã và ai/cách đóng các vấn đề. Những điều như "không đẩy trực tiếp đến nhánh chính" hoặc "không hợp nhất cho đến khi các bài kiểm tra được thông qua" nên được tuân theo ở cấp độ tiềm thức

Ngoài ra còn có các chuẩn mực xã hội như "không triển khai vào thứ Sáu", nhưng điều đó còn gây tranh cãi, hãy xem video bên dưới

8. Cơ sở hạ tầng phần cứng để mở rộng quy mô

Nếu dự án của bạn đạt đến giai đoạn rất phổ biến, nó không đủ để tối ưu hóa hiệu suất mã. Bạn cần mở rộng nó về mặt phần cứng, bằng cách tăng thêm sức mạnh máy chủ khi bạn cần hoặc thậm chí tăng/giảm kích thước dựa trên một số đột biến dự kiến ​​trong cơ sở khách truy cập của bạn, như trong trường hợp Thứ Sáu Đen

Ngoài ra, cân bằng tải giữa nhiều máy chủ cũng rất hữu ích, ngay cả trong trường hợp một trong các máy chủ gặp sự cố, vì bất kỳ lý do gì. Bạn có thể sử dụng Laravel Forge cho việc này, xem ảnh chụp màn hình bên dưới

Ngoài ra, đừng quên mở rộng quy mô của các dịch vụ bên ngoài. Có các giải pháp phần cứng cơ sở hạ tầng riêng biệt để cung cấp năng lượng cho Bộ lưu trữ tệp, Hàng đợi, Elaticsearch/Algolia, Công cụ thời gian thực của Ổ cắm, Cơ sở dữ liệu, v.v. Nó sẽ là một bài báo lớn về từng lĩnh vực đó

Có rất nhiều công cụ khác nhau mà tôi thực sự không thể đề xuất một công cụ cụ thể nào, mọi thứ phụ thuộc vào từng nhu cầu của dự án, ngân sách của bạn và mức độ quen thuộc của bạn với một hệ sinh thái nhất định

Nhà lãnh đạo sức mạnh máy chủ rõ ràng trên thế giới là Amazon với Hệ sinh thái AWS của họ, nhưng thường thì khá khó để hiểu tài liệu của nó, thậm chí có những trang web giải thích như AWS bằng tiếng Anh đơn giản

Ngoài ra, có một "người chơi" tương đối mới trong thị trấn, được gọi là serverless. Nó đã trở thành một thứ trong thế giới Laravel với việc phát hành Laravel Vapor - một nền tảng triển khai không cần máy chủ dành cho Laravel, được cung cấp bởi AWS

Có lẽ tài nguyên tốt nhất để tìm hiểu sâu hơn về toàn bộ thế giới mở rộng này là khóa học Scaling Laravel

9. Chiến lược sao lưu và phục hồi

Chắc hẳn ai cũng biết rằng bạn cần thực hiện sao lưu cơ sở dữ liệu thường xuyên. Và nhìn bề ngoài, nó khá dễ thực hiện với gói Sao lưu Spatie Laravel đơn giản

Và, tất nhiên, bạn cần tự động hóa nó, chẳng hạn như "thiết lập và quên nó đi". Tuy nhiên, một câu hỏi quan trọng là bạn đã thử khôi phục từ bản sao lưu DB đó ít nhất một lần chưa?

Bạn cần thực sự kiểm tra kịch bản. điều gì sẽ xảy ra nếu máy chủ DB hiện tại của bạn chết hoàn toàn hoặc ai đó làm mất toàn bộ cơ sở dữ liệu sản xuất và tất cả những gì bạn có là SQL dự phòng đó. Hãy thử thực sự chạy quá trình nhập từ nó và kiểm tra xem có gì bị hỏng không. Nếu có vấn đề với khôi phục sao lưu, bạn nên biết điều đó trước khi thảm họa xảy ra

Ngoài ra, nó sẽ phức tạp hơn khi bạn có nhiều máy chủ Cơ sở dữ liệu, sao chép và bạn cũng muốn không làm chậm máy chủ của mình trong khi quá trình sao lưu đang diễn ra. Vì vậy, bạn có thể điều chỉnh quy trình hoặc sử dụng trực tiếp một số công cụ sao lưu cơ sở dữ liệu, ngay cả bên ngoài thế giới Laravel

10. Quy trình giám sát lỗi

Tất nhiên, codebase càng lớn thì khả năng xảy ra lỗi càng lớn. Ngoài ra, khi có hàng tá tính năng, nhà phát triển không thể tự kiểm tra tất cả chúng và ngay cả kiểm tra tự động cũng không nắm bắt được hết các tình huống và trường hợp có thể xảy ra. Lỗi xảy ra với người dùng thực của hệ thống, trong tự nhiên

Mục tiêu của bạn với tư cách là một nhóm là giám sát chúng và được thông báo khi chúng xảy ra. Có nhiều công cụ khác nhau để trợ giúp việc đó, cá nhân tôi sử dụng Bugsnag, nhưng cũng có Flare, Sentry, Rollbar - tất cả chúng đều hoạt động khá giống nhau. thông báo cho bạn về các lỗi, với tất cả các thông tin có thể giúp theo dõi và sửa lỗi đó

Nhưng một lần nữa, vấn đề không chỉ là thiết lập công cụ, mà còn là yếu tố con người. Nhóm cần biết quá trình ai phản ứng với lỗi nào và chính xác như thế nào. lỗi nào là khẩn cấp, lỗi nào có thể hoãn lại hoặc hoàn toàn bỏ qua

Ngoài ra, câu hỏi "Hôm nay ai trực" cũng khá phù hợp. nếu phần mềm theo dõi lỗi thông báo về điều gì đó, thì ai cần nhận thông báo đó và thông qua kênh nào? . Tất nhiên, trong thực tế không phải lúc nào điều đó cũng xảy ra, nhưng ít nhất nhóm cần biết mục tiêu thời gian để phản ứng

Ngoài ra còn có một phần khác của đội. người không rành về công nghệ. Các nhà phát triển cần liên lạc với những người hỗ trợ khách hàng và với các nhà quản lý, thông báo cho họ về mức độ nghiêm trọng và tình trạng của tình huống, để những người "trực diện" sẽ nói chuyện với khách hàng một cách phù hợp

11. Bảo vệ

Câu hỏi này khá rõ ràng, vì vậy tôi sẽ không giải thích quá chi tiết. Ngoài việc tránh bị tấn công nói chung, có lẽ điều quan trọng nhất là bảo mật dữ liệu cá nhân của người dùng của bạn - cả với những người dùng khác trong hệ thống nhiều bên thuê và từ thế giới bên ngoài

Tôi khuyên bạn nên đọc bài viết này. Cách bảo vệ ứng dụng web Laravel của bạn trước 10 rủi ro bảo mật hàng đầu của OWASP

Ngoài ra, tôi khuyên bạn nên cố gắng tự hack. Vâng, tôi không đùa đâu - hãy nhờ một người bạn/công ty đáng tin cậy nào đó từ bên ngoài đột nhập vào ứng dụng của bạn và gây ra một số thiệt hại. Heck, thậm chí trả tiền cho điều đó - có những công ty chuyên về lĩnh vực này. Tất nhiên, bạn có thể thử tự mình làm điều đó, nhưng với tư cách là tác giả của mã, bạn hơi thiên vị và có lẽ bạn sẽ không thử điều gì đó bất thường như một hacker điển hình sẽ làm.

Cuối cùng, tôi muốn bày tỏ niềm vui của mình về việc chúng tôi không cần phải giải thích sự cần thiết của chứng chỉ SSL nữa. với các thay đổi cảnh báo của trình duyệt và với các công cụ miễn phí như Let's Encrypt, không có lý do gì để không có https. // trong trang web của bạn

12. Tài liệu giới thiệu nhà phát triển mới

Điểm cuối cùng trong bài viết lớn này là về con người. Nếu bạn làm việc với dự án không phải từ ngày đầu tiên, hãy nhớ ngày bạn được giới thiệu về nó. Bạn có nhớ cảm giác cài đặt mọi thứ, đọc tài liệu, thử nghiệm dữ liệu thử nghiệm, cố gắng hiểu mọi thứ hoạt động như thế nào không?

Bây giờ, hãy tưởng tượng tâm trí của một nhà phát triển mới đang làm điều đó trên dự án hiện tại, điều này không phức tạp hơn nhiều. Vì vậy, bạn cần phải giúp đỡ những người nghèo đó, càng nhiều càng tốt

Tôi sẽ đề nghị thậm chí trở thành "nhà phát triển mới" đó trong một ngày. Lần cuối cùng bạn thử cài đặt ứng dụng của mình, từ đầu là khi nào? . Vì vậy, vâng, hãy thử điều đó, bạn có thể gặp một vài "bất ngờ" khó chịu để khắc phục

Những thứ như hướng dẫn cài đặt trong Readme (thậm chí có thể với hình ảnh Docker), nhận xét trong mã, làm cho mã "có thể nhấp được" trong IDE, thông báo dễ hiểu trong cam kết git - tất cả những điều đó cần được quan tâm. Và, hãy nhớ khi chúng ta nói về các nhà máy và hạt giống?

Nhân tiện, có những công cụ giúp bạn, như trình tạo Readme này

Và nó không chỉ dành cho các nhà phát triển hoàn toàn mới - điều tương tự cũng có thể xảy ra với bất kỳ thành viên nhóm hiện tại nào cần sửa một thứ gì đó trong mô-đun mà họ chưa từng thấy trước đây. Bất kỳ trợ giúp được đánh giá cao

Suy nghĩ của bạn?

Bạn nghĩ sao về 12 câu hỏi này? . Bạn có thêm câu hỏi nào nữa vào danh sách này không?

Laravel có thể xử lý dữ liệu lớn không?

Làm cách nào để truy vấn laravel nhanh hơn?

Laravel sử dụng cách nào để lấy dữ liệu từ cơ sở dữ liệu?

Cơ sở dữ liệu hùng hồn trong laravel là gì?