开始写一个项目之前，我们都会考虑很多问题。上到服务器层，下到代码层。以至于选用哪种语言开发新项目，一要保证开发效率，二要贴合产品需求。对于启动一个 Laravel 项目，必须在原有代码生态上制定出业界认同的标准规范。符合软件设计原则，尽量贴合底层包的设计优先。

新项目启动，刚开始都会开需求研讨会，拆分细节，拆分功能模块，建立项目流程管理机制。一步一步落实到开发者层面，中间分布式衔接到测试者之样例，运营者账号管理，项目经理进度把控，运维服务器调度等等多个环节。对于 PHP 开发者来说，可能每个公司制定的代码规范都不尽相同，虽然有起初的 PSR 业界规范，但是数万个程序员依然有数万中代码风格。Github 上有篇文章介绍 Laravel Best Practices，起初很早的时候在 LC 上阅读过这篇文章，可以帮助我们理解面向对象的 SOLID 原则。不管是用什么语言开始你的新项目，规范化的 start 一件事情，永远都是头等大事，这即是真切之言。不要让其在迫不得已的后期 restart。

针对文章的不少代码片段在此做一个总结，方便以后查阅。也时常去思考用如何在实践过程中也出更加贴近与 Laravel 的代码。

单一责任原则

一个类和一个方法应该只有一个原则，Laravel Model 提供了属性修改器的功能，可以更加友好的去格式化我们需要的属性，对于调用 Model 的 Services 不应该关心你想获取的属性内部如何处理的。但是如何简化 Model 层也是开发过程中值得思考的问题

简化控制器

实际开发中我们应该将查询构造器相关的代码放入 Eloquent 模型或存储库类中。与控制器层衔接的应该是上层的 Service、Repository

验证类归类

使用 Laravel 构造私有 Api 服务器的项目，或者一般的 Web 项目都少不了表单验证、前端数据校验。那么最合理的做法应该将验证逻辑抽离成一个子目录，每个 Api 接口对应一个 Request 类，而这个类继承的是 Laravel 核心基类 Http Request，此类中包含 验证规则，验证信息提示，验证结果三个核心方法。

杜绝重复代码块

老生常谈的话题，软件设计原则，尽可能的重用代码，Give Up DRY!

带完结