1. Automatic test
In small projects, there is usually a small budget or the need to develop an application quickly, so automated testing will be considered "extra workload"
In a large project, you cannot manually test all functions before you release the project You can test your own code before the code is released, but you can't be sure that you won't change other people's code. It's too scary to think about it this way. You don't even know how these codes or these modules work, because you are only concerned with the part of the application you are developing.
So, how do you ensure that the code you publish will not have bugs? Generally speaking, new code is a refactoring of the old code. If you change something in the project, how can you ensure that the content of these tests is not broken? ? Don't fall into the mentality that I call finger cross-driven development.
In addition, back to the definition of large projects-remember that the cost of bugs is high. Therefore, literally, your wrong code may cause economic losses to the enterprise. If this parameter still does not convince you to use tests to cover the code, then there may be no other way to convince you.
Yes, I know the typical argument of "We don't have time to write tests". I have a complete video.
But this is where you need to find time. It includes some communication: evaluating deadlines, considering the time to write the test, and talking to your manager about what will happen if you don't write the test. Then they will understand and allow this extra time. If they don’t, it means they don’t care about quality so much, so maybe it’s time to find another company?
Now, we don’t need to talk about the fabulous "100% test coverage." If you are really in a hurry, please test the functions that are essential to your application’s work
2. Architecture and project structure
You can follow many different models or ideas: divide the project into modules](https://github.com/nWidart/laravel-modules), use [DDD method](https://stitcher.io/blog/laravel- beyond-crud-01-domain-oriented-laravel), choose some from design patterns, or just follow the [SOLID principle](https:/ /laraveldaily.teachable.com/p/solid-code-in-laravel). This is completely personal preference.
The problem is that there’s no silver bullet (there’s no silver bullet), and there is no one size fits all solution. For example, no one dares to say that all large Laravel projects must follow DDD. Even the SOLID principle is sometimes considered not the best solution.
But the problem is obvious: as your project structure grows, you need to change certain things, and you need to reorganize files/folders/classes into a more manageable look. So what do you need to do?
First, move everything into subdirectories and namespaces. This Monica CRM example does a good job.
Secondly, make sure your classes/methods are not very big. There are no magic numbers to use. When you feel that you need to scroll up and down frequently, or always spend a lot of time figuring out the function of the class/method, then you should refactor the code and classify the code into other Place. The most common example is this super large controller file.
These are just two suggestions, but these two changes make your code more readable, maintainable, and testable.
Yes, sometimes it requires a big "risky" refactoring of the class, but hey, you might have automated tests to check everything, right? Right?
3. "Fake data" with factories and seeds
A topic related to automated testing that we have already discussed. If you want to stress test application features, you need a lot of data. Factory + seed is a perfect combination, it is easy to achieve this.
Just get into the habit, when creating a new model, create a plant and seed immediately, from the beginning. So, whoever uses it to generate some fake data in the future will thank you very much.
But this is more than just testing. Also, consider a fresh install of the application. Large and successful projects will only get bigger, so you definitely need new developers. If they don't have any sample data to use, how difficult will they be in the installation process and acceleration?
You may also need to install applications multiple times on various servers-local servers, temporary servers, some docker-based environments, and so on. You can customize the seed to run in a production environment or a local environment.
4. Database structure
Although I mentioned at the beginning that database size is not the definition of a large Laravel project, the database structure is very important for long-term performance and maintainability.
Which relationship should be used? In Laravel terminology, should it be HasOne? HasMany? BelongsToMany? Polymorphic?
Try to ask "future self", what queries will be made in these data tables in the future, and try to write these queries first.
In other words, consider the final goal, and then think backwards about the structure from the end. This can help you "feel" the correct structure.
If you have prepared the plants and seeds, you will be able to easily simulate future usage, and you can even quantify the two options and choose which one is better. This is actually very important: changing the database structure in the future when there is a large amount of online real-time data may be the most complex, costly, and dangerous change. So you'd better make a decision before then.
In other words, when you really need to refactor the database, you don't need to worry about anything. Move some data to a separate, less used table, change HasMany to Polymorphic, choose other field types, etc.
Just make sure you have not lost user data.
5. External packages and upgrade Laravel
Once you have determined which Laravel/PHP packages to include in your composer.json, it will be very simple at the beginning. They are all the latest version packages. Just make sure that these packages are available and just use it.
But after a period of time, when the project survived for one or two years, not only Laravel itself, but also these packages were facing the need for version updates.
Fortunately, Laravel changed from being updated every 6 months, to annual release, and later changed to Laravel 9 release The time is changed to synchronize with Symfony. So developers no longer have to have a headache every 6 months.
Generally speaking, the framework itself has a fairly stable kernel, and it is relatively easy to upgrade to a new version, and it only takes a little time. In addition, there is a right-hand man named Laravel Shift dedicated to helping developers save time in this area.
But the problem comes from the package you use.
A very typical scenario: You want to upgrade the Laravel in your project to a new version, but some packages in composer have not yet released a new version that supports the new version of Laravel. Therefore, in my experience, at least a few months after the official release of Laravel, package authors followed up to upgrade the project.
There is even worse: when the package authors don’t have time to develop a new version (remember, most package authors use their spare time to develop for free), or even give up the package, what should I do?
First, of course, you can help the creator and submit a pull request that includes a suggested upgrade (don't forget to include automated testing). But even so, they need to review, test, and approve your PR, so I rarely see this happen in real life. These packages are either actively maintained or are in a state of near obsolescence. Therefore, the only reasonable solution is to use your own version in the future.
However, a better decision is to think more deeply when choosing which software package to use. The questions to ask are: "Do we really need this package?" and "Does the package creator have a reputation for maintaining their packages?"
6. Project performance
If the project is successful, its database will grow with more data, and the server needs to provide services to more users at the same time. Therefore, loading speed becomes an important factor.
But Eloquent and databases are just one aspect of it. In order to increase the speed, you also need to optimize some other things:
– Queue Mechanism: Your users should not spend 5 minutes waiting for the invoice email
– Load front-end resources: If you can compress them, you should not provide 1 MB CSS/JS files
– Run automated test suite: You cannot wait an hour to deploy a new version
– Web server and PHP configuration: When 10000 users browse the website, users should not wait in line
- and many more.
Of course, each topic is an independent world that can be studied in depth, but the first thing you should do is to establish a measurement and reporting system, so that if there is a slow query somewhere, or a visitor You will be notified when the peak is reached at a certain time, or the CPU of the server is close to the limit.
7. Deployment process and downtime
In traditional small projects, you can log in to the server with SSH and run a few git and artisan commands to deploy new changes to the server.
But if your traffic is bigger and your team is bigger, you need to pay attention to two things:
-Non-stop deployment: In order to prevent visitors from seeing the words "Deploying" and conflicts before and after deployment. This is the official project Envoyer in this area, and some alternatives: laravel-deployer, laravel -zero-downtime-deployment.
-Automated deployment: Not everyone in the team has (or should have) SSH permissions in the production environment, so it should be a button somewhere to trigger the deployment, or automatically trigger the deployment on certain git actions .
Also, remember the automated testing? Yes, you should automate their automation. I mean the test should be run automatically before any deployment. Or, in fact, as long as new code is pushed to the staging/develop branch, they should run.
You can schedule more automated operations at that time. Generally, the automation of this build/deployment process is called [Continuous Integration or Continuous Delivery (CI/CD)](https://www.infoworld.com/article/3271126/what-is-cicd-continuous-integration-and- continuous-delivery-explained.html). It relieves some pressure when releasing new features.
Recently, the most popular tool to achieve this goal has become Github Actions. Here are some related resources:
– Use GitHub Actions to build, test and deploy Laravel applications
– [How to use GitHub operations to create CI/CD for Laravel applications](https://blog.logrocket.com/how-to-create-a-ci-cd-for-a-laravel-application-using-github- actions/)
But this is not just about setting up software tools. What is important is the human factor: every developer should know the deployment process and their respective responsibilities. Everyone should know which branch to work on, how to submit code, how to close the issue, and subconsciously follow things like "Don't push directly to the main branch" and "Merge only after passing the test".
8. Scalable hardware architecture
If your project usage is large enough, the optimized code is not enough to meet the required performance, then you need to expand it in terms of hardware. Increase the power of the server, or pre-set according to the visitorMeasure the performance of scaling up or down, such as in the case of Black Friday.
In addition, load balancing between multiple servers is beneficial, even if one of the servers fails for some reason, the program can still run normally. For this, you can use Laravel Forge, see the screenshot below.
Also, don't forget the extension of external** services. ** There is a separate infrastructure hardware solution to support your file storage, queue, Elasticsearch/Algolia, socket real-time content, database, etc. Each field deserves a special book.
There are so many different tools on the market, I can't definitely recommend one, especially, everything depends on your project needs, budget, and your familiarity with a certain ecosystem.
Obviously, the leader with the strongest server capabilities in the world is Amazon, which owns the AWS Ecosystem, but it’s often difficult to understand its documentation, and there are even other companies like AWS Explain in plain English website.
In addition, there is a relatively new "player" here, the so-called server. With the release of Laravel Vapor-a Laravel serviceless deployment platform powered by AWS, it has become a thing in the Laravel world.
Perhaps in this reduced world, the best resource is Scaling Laravel.
9. Backup and recovery strategy
You probably know that you need to back up your database regularly. Moreover, on the surface, it is easy to use a simple Spatie Laravel Backup package:
Of course, you also need to "automate" this aspect, like "set it and forget it." But an important question is, have you tried to restore from a database backup at least once?
You need to actually test this scenario: If the current database is down completely, or someone deletes the complete production environment data, and you have the backup SQL. Try to import from SQL, and then test whether the import process is not interrupted. If there is a problem with backup and recovery, you'd better know it in advance before this disaster occurs.
In addition, if you have multiple database servers, and the backup is in progress, and you want to not reduce the server access speed during the backup process, then things will become more complicated. So you can adjust the entire process or use some database backup tools directly, even outside of the Laravel world.
10.Bug monitoring process
Of course, the larger the code base, the greater the probability of bugs occurring. In addition, when there are many features, developers cannot test them by themselves, and even automated testing cannot capture all possible scenarios and cases. In a production environment, bugs happen to real users of the system.
As a team, your goal is to monitor them and be notified when they happen. There are various tools to help solve this problem, I personally use Bugsnag, but there are also Flare, Sentry, Rollbar-they almost all have the same function: notify you of vulnerabilities, and all possible help in tracking and fixing Vulnerability information.
This is not a problem of tools, but a problem of human factors. The team needs to understand the process of who responds to which bugs, and how to do it: which bugs are urgent, which can be postponed, and which are negligible.
In addition, the question of "who is on duty today" is also very relevant: if the error tracking software informs something, then "who" needs to get the message "where"? In our team, we use the Slack notification tool, and ideally, the developer responsible for the problematic application fixes the problem. Of course, in actual situations, this situation does not happen often, but at least the team needs to know its reaction time.
There is another part of the team: Non-technical people. Developers need to keep in touch with customer support staff and managers to inform them of the severity and status of the situation, and the "front desk" staff will talk to customers accordingly.
11. Security
This problem is more obvious, so I won't explain it in detail. In addition to avoiding being hacked in general, the most important thing is probably to protect your users’ personal data-whether it comes from multi-tenant system or Personal data of other users from outside.
I recommend reading this article: [How to protect your Laravel Web application from OWASP Top Ten Security Risks](https://www.freecodecamp.org/news/protect-your-laravel-app-against-the-owasp -top-10-security-risks/)
In addition, I suggest you try attack yourself. Yes, I'm not kidding — let some trusted friend/company hack into your application from the outside and do some damage. A company called Heck even paid for this-there are companies specializing in this field. Of course, you can also do this yourself, but as the author of the code, you have a certain inclination, so you may not be able to use unpredictable attack methods like a real hacker.
Finally, what I want to express is that I am very happy because we no longer need to explain the necessity of SSL certificates, as the browser’s warning policy changes, and things like [Let's Encrypt](https://www.techalyst.com /posts/install-lets-encrypt-ssl-certificate-on-digital-ocean-for-laravel-nginx-application) such a free tool, there is no excuse to prevent your website from seeing *https:// *.
12. New developer induction document
The last point of this big article is about people. If you are not working from the first day of the project, remember the day you were introduced to it. Do you remember the feeling of installing everything, reading documentation, playing with test data, trying to understand how things work?
Now, imagine the idea of a new developer doing this on the current project. It's not complicated. So, you need to help those poor guys as much as possible.
I suggest that you can even be a "new developer" for a day. When was the last time you tried to install an application from scratch? For example, installing the operating system on a new computer or reinstalling the operating system. So, give it a try, you may have some unpleasant "surprises" that need to be resolved.
For example, the installation instructions in the above files (it may also be a Docker image), the comments in the code can make the code "clickable" in the IDE, you can easily and quickly jump to the file where the code is located, and it is convenient to add it in git commits Understanding messages – these should be noted. Also, remember that the factory files and seed files we discussed are very applicable here.
By the way, here are some tools to help you, like this Readme generator.
It's not just about new developers-the same can happen to any existing team, and they need to fix things in the module that they haven't seen before.
发表评论 取消回复