Laravel Lesson of the Week # How to avoid Over-Engineering

I am a beginner laravel programmer. One of the things I'm grateful for is that I met a great community on Twitter. The developers are so kind to give advice, it's great for beginners. I recommend beginners to start joining the twitter community.

A few days ago I made a tweet:

I didn't think that it would go viral, at least according to my version :D. I realized it happened because one of the laravel developers @enunomaduro retweeted this tweet. This is the greatness of the laravel community, even me a new beginner got such a good reception.

So here's a summary of the tweet's comments.

In order not to be an over-engineer:

1. Clean controllers, use out of the box functionality like requests, policies, rules, gates, events, listeners etc. Don't ram all your logic into controllers. @BarryDeen
2. Just don’t do something the framework already does (e.g. repository patterns) and stick to convention. @ChrisArter
3. Over engineering is the problem I see the most. A lot of seniors are often "by the book" so they force DRY/SOLID constantly. Remember, anti-patterns are fine too. There's always a trade off. Monolith vs Microservices is a good example of this. Both are fine. @chrispian
4. One thing per controller method and stick to the default (public) methods like index/store/edit/etc. Try and create a separate controller for things; PageController and a ArchivePageController, where the latter only has store and delete for archiving and dearchiving a page. @bernardohulsman
5. Read the documentation. Start developing. And read the documentation again. Probably Laravel has a solution and you probable didn’t get it from the documentation the first time you read it. @mgastkemper
6. Almost everything you can think of doing has in some way, been done before - research is important. I try to keep a 40-40-20 split: 40% of the budgeted time is spent researching how others have done it. 40% goes to planning how I want to do it. 20% goes to actually doing it. @bredmor
7. Most of the tips you'll learn are not Laravel specific anyway. Write code that is simple to read, simple to maintain, simple to debug. Document complex things for your future self/ colleagues. Do not use external packages if you can avoid them. KISS. @maazarin
8. The best way to learn is to work on a single project for about 2 years or more and make mistakes, learn from them otherwise you wouldn’t understand why abstractions, SOLID principles and design patterns are good and how using them is not exactly over-engineering. @davorminchorov
9. Make sure to write test. It will save you from shooting your self in the foot in the future and will help reduce complex logic it will help in the long run. @jdwernke
10. Try writing unit tests first and go from there. However, my tip for you is to actually do some over-engineering. @sumihiran
11. Stay up to date with the Laravel documentation and the community. Your architecture have to follow the Laravel way. @HakimBenm
12. Anticipate the next problem but no further. As a dev I would always think about the future. What would happen if the system needed to do x. In a lot of our day to day project work we never see the benefit of the consideration. @jeepstone
13. In general, you‘ll know you’re close to over-engineering when you find yourself creating too much value for tomorrow instead of today. What absolutely needs to be done today? Do that. Solve the other concern when it becomes a problem in the future, not before. @xavierelv
14. Remove features and functionality until it no longer completes the requirement, add the last thing back and build it. Ignore the what ifs until it works then measure feedback and pain points for what to prioritize to enhance. MVP and agile are a thing for a reason. @ziptied
15. The key is knowing the point in which you’re over engineering a solution and to stand-back and ask yourself how else can this be solved. I find this comes with experience and time boxing. I also sometimes need to over-engineer a solution in order to realise the simpler solution. You can always write the function and review it at the point of committing the code. I often see of ways to refactor code when I’m looking at the diff. Another tip is to have others review your pull requests. A fresh pair of eyes are great for spotting over-engineering gotchas. @pfwd
16. Best advice is to just keep working on projects. Keep everything simple. Also the reality is you will over engineer things. You’ll make mistakes but that’s all part of the learning process. Finally ask other devs you work with for advice. Let them review your code. @imperez
17. Don’t worry about bad code, write your code and learn the art of refactoring the bad code. Don’t worry, you’ll stop over-engineering with time and bit of experience. @thesagarkale
18. The only true and tested way to avoid over-engineering is when you make the switch away from software development to something non-IT. I'm 30 years in the business and it happens often enough that I can't see the forest for the trees. Just a way of life, really. @PHPGuus
19. Stick to the framework conventions and defaults. The Laravel Team did an awesome job on the documentation, always refer to it. Side Note: Avoid the use of too many packages in your project. @OilmoneDev
20. Try to build the simplest solution first, refactoring to perfection is a much more efficient route and will get to production quicker. @JustSteveKing
21. 1.) don't use frameworks; like Laravel, 2.) comments, organization of files and folders, 3.) PDO @tradesouthwest
22. Stick to the first obvious solution that comes from the documentation. Every 'best practice' or 'design pattern' out there is not necessarily needed when getting started. @yahyaman09
23. In order to avoid over-engineering try to have on mind these design principles: Don't Repeat Yourself (DRY), Keep It Simple Stupid (KISS). The more simple your code the better @wilterrero
24. A good way to know is to think about the "WHY" you are using a certain pattern or architecture. Why do you need this? Why is it necessary for this project? What's the point? @denz_io
25. I'd say don't be afraid of over engineering if you are new. I know that kind of sounds sacrilegious but over engineering is part of the fun when you are new. You'll learn over time to hold back. @JamesHamann19
26. Stick to the documentation, with time you would adopt a best practice that fit. @adroitcode
27. Write your tests first, let them all fail at the beginning. Then write enough code to pass the test @Elliot_Sawyer
28. I think we can start from documentation or similar project on github. I learn a lot from it @Fajar_Siagian_7
29. To avoid over-engineering, keep in mind what you think future features will be, so you don't burn architecture bridges. BUT don't start implementing ANY of those potential features or putting down skeleton code for them until you really get to them. They're likely to change. @JasonDJudge
30. taking apart and digesting some open source projects from known community leaders helped me. @thebusypixel.
31. Try TDD, you'll minimize over-engineering quite a bit. @GeniJaho

I would like to thank all my friends who have shared their experiences.

Information: In closing, a few days ago I also created a project curating the blogs of developers. The goal is to make it easier for developers to access the Laravel developer community. You can also add your blog by commenting on the following tweet.

You can access the curation at the following link: [kangmus.notion.site/f39919aa1dd14eeeaaaffb2..