分享下团队的开发规范 ——《Laravel 项目开发规范》

file

这是一套严格的团队开发规范,是 优帆远扬 团队内部 Laravel 工程师践行的开发规范。我们崇尚开放和透明的工程师文化,所以我们尽可能把信息公开。希望这些信息可以为他人参考和借鉴,发挥最大的价值。

Laravel 文档和网上的各种教程,会教授我们一个任务可以使用好几种方法来完成。对于框架设计来说,灵活是件好事,能提供给开发者不同的选项,能让框架适用更多的用户场景。但是对于团队的协同开发来说,大部分时候,更多的选项反而是累赘。此文档,正是为解决此问题而诞生。

链接:《 Laravel 项目开发规范 5.5》


Practice makes perfect.

本帖已被设为精华帖!
本帖由系统于 1年前 自动加精
Summer
《L03 构架 API 服务器》
你将学到如 RESTFul 设计风格、PostMan 的使用、OAuth 流程,JWT 概念及使用 和 API 开发相关的进阶知识。
《L04 微信小程序从零到发布》
从小程序个人账户申请开始,带你一步步进行开发一个微信小程序,直到提交微信控制台上线发布。
讨论数量: 46
Summer

Repository 是一种设计模式,懂得怎么用,并且团队架构师认同即可,没有好坏,只是应用场景不同。
讨论使用 Repository 是个无底洞,没有太大意义,只是一个选择而已。

作为工匠,应该专注在你的作品上,而不是工具。

1年前 评论

沙发!~

1年前 评论

只能注册这个网站才能看啊,请问一下有没有其他的渠道可以查看的?

1年前 评论

阅读完毕!这个规范和我自己的差不多,学习借鉴了~哈哈哈哈哈哈

1年前 评论
沈益飞

无法用言语表达,感谢,为我们这些小开发者团队指明了方向。

1年前 评论
tonyski

哇,干货!一支对规范迷迷糊糊的,例如那些单复数命名等等。总而言之十分感谢! :smile:

1年前 评论

视频播放器为大家推荐IINA,开源免费,比 MPlayerX 好用

1年前 评论
godruoyi

不要拦我, 我要打赏

1年前 评论

app下载在那里哟

1年前 评论

可否部分借鉴作为自己所在团队的开发规范?

另外,如果不推荐 repository 的话,面对企业应用极其复杂的表单和报表逻辑,有什么比较好的方式来复用代码呢?

1年前 评论

看了一下,发现自己开发时,采用错误规范的时候比较多

1年前 评论

绝对不使用 Repository的话,模型会肥到天际的啊

1年前 评论

告诉20楼,我要嘿咻嘿咻

1年前 评论

请问有没有针对Exception相关的规范呀?比如使用Exception来做流程控制之类的,很好奇

1年前 评论

看完后获益良多啊! 很多之前的疑惑渐渐感觉有点串起来了。 再次感谢无私奉献

1年前 评论
Ryan

除了绝不使用Repository,其他基本差不多,赞

1年前 评论
stoneworld

赞同不使用 Repository

1年前 评论
nff93

必须使用Homestead。。。表示用的Valet

楼下准备被 #14 @23tl 嘿咻嘿咻

1年前 评论
MushishiXian

绝不使用Repository的话,是简单加一层service层去处理复制逻辑吗?

1年前 评论
MushishiXian

@MushishiXian 打错....应该是 : 处理复杂逻辑

1年前 评论
monkey

绝不使用 Repository !

1年前 评论

除了绝不使用Repository,其他都赞

对于有几百张表的项目,如果逻辑全写在模型里,想想都有点蛋疼

1年前 评论

除了绝不使用Repository,其他都赞!规范是为了更好的协作,每个团队都有自己的规范,大致是相通的,没有对错,统一就是规范。

1年前 评论
Summer

Repository 是一种设计模式,懂得怎么用,并且团队架构师认同即可,没有好坏,只是应用场景不同。
讨论使用 Repository 是个无底洞,没有太大意义,只是一个选择而已。

作为工匠,应该专注在你的作品上,而不是工具。

1年前 评论

3.11. 前端开发
“必须 使用 Elixir 做前端开发自动化工具”,应该加上 Mix。
“必须 保证页面只加载一个 .css 文件” 和 “必须 保证页面只加载一个 .js 文件”,有时项目中只有某个页面用到一个比较大的 js 或者 css,我认为应该把它独立出来,不然会拖累其他无关页面的首次加载。

1年前 评论

@Summer 这个文档的系统是你自己写的?

1年前 评论
Summer

@dinghua 当然,怎么啦,字体不像是我写的?:smile_cat:

1年前 评论

@Summer 看起来很强大,有么有考虑开源

1年前 评论
Artisan

熟悉了这个,是不是就离加入优帆远扬更近了一步呢 . ?

1年前 评论
Artisan

从头到尾看了一遍,很赞,和我原来的习惯大多相同,这份规范值得遵守。

1年前 评论
Artisan

如果有关于测试的规范就更好了

1年前 评论

对于我这种单打独斗的人很有帮助

1年前 评论
mostwin

除了绝不使用Repository,其他都赞 :smile:

1年前 评论

@远客 laravel框架的Model其实就是Repository的一种实现,反倒是真正意义的Model在laravel里面是没有的,有些项目为了弥补这点,专门做了schema类来放实际的model,虽然觉得也是多此一举。

Respository用来进行resource操作,业务逻辑还是不能放进Repository里面的,放在哪里见仁见智,有的叫Biz,有点叫Serice,还有的叫Support。我倾向于用Service,因为很多逻辑是设计决定,而不是Biz里面的逻辑,Service更广泛一些。

Anyway,不要过度设计。

1年前 评论
lenon

很有帮助,下个项目就参考这个开发规范了

1年前 评论
Chasers9527

@lenon 同感。。。

1年前 评论

@远客 用traits来处理复杂逻辑不行吗?

1年前 评论

赞同不要使用Repository,从第一次使用这个玩意的时候,我就感觉这是茴香豆“茴”字的第5种写法

1年前 评论

我倒戈了- -,以前一直是把业务逻辑写在repository的,以后要改个名字

1年前 评论
Ali

非常赞,收藏了。谢了。

1年前 评论

@mrstranger 是的 非常不错 一会在用。

1年前 评论

@jobsssss 用 trait 来处理复杂逻辑是没问题的,用不用Repository本身没有太大问题,楼主说的,不要过度设计就好了。

1年前 评论
LDL1023

非常不错!!请问有没有 markdown 原文件下载??

1年前 评论

请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!

社区文档:

将托管在 packagist.org 和 github.com 的扩展包使用国内 CDN 加速
GitHub Laravel 扩展包 TOP 250
速查表方便快速查询框架功能,支持手机访问,支持中英文版本
Laravel 中文文档,由社区用户翻译和维护,将会保持一直更新
此文档的目的,就是为了提高技术团队的凝聚力、一致性和生产效率。
开发环境的部署,开发者工具的选择,适用于 Mac 和 Windows。
浓缩过后的精华
Laravel Nova 后台管理面板文档的中文翻译
Lumen 中文文档,由社区用户翻译和维护,将会保持一直更新
Laravel 下知名扩展包 Dingo API 的中文文档,Laravel API 开发必知必会