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

file

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

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

链接:https://laravel-china.org/courses/laravel-specification


Practice makes perfect.

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

沙发!~

1年前
BradStevens

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

1年前

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

1年前
沈益飞

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

1年前
tonyski

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

1年前
Ellison

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

1年前
godruoyi

不要拦我, 我要打赏

1年前
skyLee

app下载在那里哟

1年前

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

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

1年前
Insua

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

1年前
Insua

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

1年前

赞~

1年前

非常赞!

1年前

告诉20楼,我要嘿咻嘿咻

1年前

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

1年前

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

1年前
Ryan

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

1年前

赞同不使用 Repository

1年前

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

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

1年前

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

1年前

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

1年前

绝不使用 Repository !

1年前

受用了

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年前

:+1:

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年前

@lenon 同感。。。

1年前

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

1年前

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

1年前

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

1年前
Ali

非常赞,收藏了。谢了。

1年前

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

1年前

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

1年前

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

10个月前

  • 请注意单词拼写,以及中英文排版,参考此页
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`, 更多语法请见这里 Markdown 语法
  • 支持表情,使用方法请见 Emoji 自动补全来咯,可用的 Emoji 请见 :metal: :point_right: Emoji 列表 :star: :sparkles:
  • 上传图片, 支持拖拽和剪切板黏贴上传, 格式限制 - jpg, png, gif
  • 发布框支持本地存储功能,会在内容变更时保存,「提交」按钮点击时清空
  请勿发布不友善或者负能量的内容。与人为善,比聪明更重要!