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

file

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

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

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

摈弃世俗浮躁,追求技术精湛
本帖已被设为精华帖!
本帖由系统于 6年前 自动加精
Summer
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《G01 Go 实战入门》
从零开始带你一步步开发一个 Go 博客项目,让你在最短的时间内学会使用 Go 进行编码。项目结构很大程度上参考了 Laravel。
讨论数量: 44
Summer

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

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

6年前 评论

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

6年前 评论

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

6年前 评论
宇宙最厉害

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

6年前 评论

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

6年前 评论

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

6年前 评论
godruoyi

不要拦我, 我要打赏

6年前 评论

app下载在那里哟

6年前 评论

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

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

6年前 评论

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

6年前 评论

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

6年前 评论

告诉20楼,我要嘿咻嘿咻

6年前 评论

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

6年前 评论

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

6年前 评论
Ryan

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

6年前 评论
stoneworld

赞同不使用 Repository

6年前 评论
nff93

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

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

6年前 评论

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

6年前 评论

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

6年前 评论
monkey

绝不使用 Repository !

6年前 评论

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

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

6年前 评论

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

6年前 评论
Summer

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

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

6年前 评论

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

6年前 评论

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

6年前 评论
Summer

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

6年前 评论

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

6年前 评论
Artisan

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

6年前 评论
Artisan

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

6年前 评论
Artisan

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

6年前 评论

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

6年前 评论

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

6年前 评论

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

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

Anyway,不要过度设计。

6年前 评论

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

6年前 评论
幽弥狂

@lenon 同感。。。

6年前 评论

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

6年前 评论

非常赞,收藏了。谢了。

6年前 评论

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

6年前 评论

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

6年前 评论
LDL1023

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

6年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!