这是一个创建于 2880 天前的主题，其中的信息可能已经有所发展或是发生改变。
我是个普通的 PHP 码农，正式工作一年多一点了
框架熟练 CI ，会用 yii2 、 TP3/5
做的项目越多、越大，就感觉自己的架构水平越辣鸡；代码能写、能用，各种编程基本概念都懂，但就是不知道怎么合理运用它们。
例如让我做个 xx 系统，需求我都明白了，但我总觉得自己写出来的代码不够优雅，尤其是如何划分一些类以及类之间的继承、抽象关系上，要么就是写着写着耦合度又提高了；在数据表设计上也是这样，属于那种 道理我都懂，但就是不知道怎么去做 的感觉
所以我想问下各位，有没有那种用实际（或虚拟）案例来做分析，教授如何优雅划分类、设计表这样的教材？载体不限，书籍视频都可以，收费也行
 |
1
uxstone 2017-01-03 10:39:15 +08:00
php 不就应该是面条嘛,还能咋地.......
|
 |
2
mikulch 2017-01-03 10:44:45 +08:00
别整这么多没用的
要想去搞什么优雅啊 耦合度啊 那你得放弃世界上最好的语言，转而去研究世界上最具有模式的语言： java 你觉得这个代价值得吗。 |
 |
3
klom303 2017-01-03 10:48:48 +08:00
尝试下 Laravel 框架，看看源码
|
 |
4
mokeyjay OP |
 |
6
peinhu 2017-01-03 10:56:16 +08:00  3
JAVA 跟优雅没有任何关系，就是结构工整、语法啰嗦，追求优雅的话你可以看看 laravel ，关键字 repository ，推荐你看看这个 http://oomusou.io/laravel/laravel-architecture/
|
 |
7
mercurylanded 2017-01-03 10:56:59 +08:00
少年听过 DDD 吗
|
|
8
mokeyjay OP |
|
9
mercurylanded 2017-01-03 11:04:17 +08:00
|
 |
10
ElmerZhang 2017-01-03 11:04:57 +08:00 1
学架构没什么好教材，最好的办法就是工作中努力把事情做得更好，更接近完美。
|
 |
12
otakustay 2017-01-03 11:07:57 +08:00 1
一年多谈啥架构，也没什么教材，架构本身就是掉坑掉得体无完肤总结出来的东西
|
|
13
mokeyjay OP |
 |
14
Troevil 2017-01-03 11:09:20 +08:00
优雅 -> scala
结构 -> java |
 |
15
denghongcai 2017-01-03 11:22:45 +08:00
Laravel 性能还好的，用 https://github.com/denghongcai/laravoole 免去框架加载时间
|
 |
16
Allianzcortex 2017-01-03 11:23:03 +08:00
|
 |
17
feiyuanqiu 2017-01-03 11:40:38 +08:00 via iPhone
程序设计是从需求分析阶段就开始了...不过现在干 php 的都挺不重视这个的
设计类最主要的还是需要学习面向对象设计方法论，经典的比如 grasp 的创建者模式和信息专家模式在划分类时都是很有用的指导。这方面可以看看 uml 与模式应用 这本书 进一步地，可以看看领域驱动设计，尽管可能受限于环境因素不能照搬，但理解它的领域模型聚合实体值对象领域服务领域事件等概念还是挺有用的。这方面的书写得都挺难看的...随便找本书翻翻了解下概念，然后可以去汤老师 cnblogs.com/netfocus 的博客上看看，他的文章写得很好 最后，我的感觉，不一定对， php 这行业平均水平就这样了，写写过程式代码完成需求就行了，你弄些复杂的概念进来同事不一定看得懂，还影响同事间关系...业务代码翻来覆去就那样，平时工作里干的那些零零碎碎的工作对自己的技术提升真是有限，有时间多学点基础知识，搞点完整的复杂项目，这种提升才是真实的 |
 |
18
kuber 2017-01-03 12:09:08 +08:00 1
建议看看“企业应用架构模式”。架构模式很大程度上跟语言无关
https://book.douban.com/subject/1230559/ |
 |
19
guoer 2017-01-03 12:19:24 +08:00 via iPhone
去大公司做大项目
|
 |
20
bzzhou 2017-01-03 12:19:36 +08:00
才工作一年，别想太多了，多干活多写代码，等你感觉代码哪里不爽了，或者哪里重复工作多了，再去看一些架构的书籍，就水到渠成了
|
 |
21
misaka19000 2017-01-03 12:25:33 +08:00 via Android
写 PHP 不就是图快吗，还要啥自行车
|
 |
22
glasslion 2017-01-03 12:38:17 +08:00
同推荐 企业应用架构模式， 以及其作者 Martin Fowler 的博客
|
 |
23
jwdstefanie 2017-01-03 12:42:15 +08:00
一年。。 PHP 。。。谈架构。。
|
 |
24
hantsy 2017-01-03 12:48:04 +08:00
语言只是工具，架构方案与语言关系不是特别大。现在 PHP 中的 ZF ， Symfony 框架，甚至 PSR （命名都是 Copy JSR ）都是从 Java 中获得灵感。
不要为了什么追求架构，模式，想尽办法去看书，去套用。哲学上这叫形而上学，大部分情况下把简单的事情搞复杂。 多写写代码，多进行实践，回过头来再去看看那些架构和模式，比较一下自己之前的方法，或许有顿悟的感觉，以后再应用就轻松得多。 |
 |
25
FrankFang128 2017-01-03 12:49:01 +08:00
Unix 编程艺术
|
 |
26
zhidian 2017-01-03 12:51:59 +08:00
《重构》。
|
 |
27
bk201 2017-01-03 12:53:43 +08:00 via iPhone
一直以为 php 和 jsp 一样，怎么快怎么来
|
 |
28
myoula 2017-01-03 13:02:36 +08:00
github 是最好的学习材料 多看看别人的 code
但也不要太过于追求架构，如果跟同事一起开发，同事为了改代码，打开 7 ， 8 个文件才找到真正实现的地方，估计心理要骂娘了。 |
 |
29
phpdever 2017-01-03 13:49:37 +08:00
《架构即未来》
|
 |
30
Time2 2017-01-03 13:54:52 +08:00
同 lz 差不多情况， 不过现在看框架的 源码，收获很大啊。
|
 |
31
ubear1991 2017-01-03 13:58:38 +08:00
一年。。。
|
 |
32
yangxiongwei 2017-01-03 14:01:08 +08:00
一年，还是做 php 的，谈啥架构？
能快速出活就 OK 了，要啥自行车？ |
|
34
mokeyjay OP |
 |
35
jswh 2017-01-03 15:49:13 +08:00
这种事情，真的需要场景和老师，比较经验向我觉得。多看看别人的源码吧。
|
 |
36
chnhyg 2017-01-03 17:16:32 +08:00
架构这个东西不是刻意就能学来的，工作中项目中可以多思考，而不仅仅是完成任务就行了。
|
 |
37
a15819620038 2017-01-03 17:25:15 +08:00
架构？还是结构？
我猜楼主想问的是『怎么在代码里把类组织好』。 除了多写，额，多写也没用，得看写什么东西。 多造轮子，从零早起，慢慢就有感觉了。 |
 |
38
zuston 2017-01-03 17:43:29 +08:00
@mokeyjay 写 php 几年，现在也写 python,java,scala ，何来比我有志向,哪看出来的？ laravel 的架构同时也是模式复用的结果， java 也有，语言之争也没啥意思。我是没看懂你 @我干嘛？
|
 |
39
huijiewei 2017-01-03 17:48:41 +08:00 via iPhone
架构和语言无关
架构是一步一步演进出来的 加油吧，先从重构做起，先把代码做到可测试化 |
 |
40
yura93 2017-01-03 17:52:03 +08:00
架构要结合业务吧，适合业务场景的架构才是好的
|
 |
41
Felldeadbird 2017-01-03 17:54:02 +08:00
架构就是你写代码的经验啊。 这东西是随着你开发经验来完善的。即使你看完了世界名师的架构框架，你没有从实践中总结出经验，你写出来的代码和现在的水平是相差无几的。
|
 |
42
winiex 2017-01-03 17:58:23 +08:00
你指的是代码层级的设计，这个和我们常规意义上说的架构联系不大。单说代码层级的设计的话，多写多修改，有经验了深刻理解下设计模式、重构，再反过来指导改进代码。再就是多看别人写的好代码，依葫芦画瓢。数据库的设计先读一本经典的教材，从了解范式入手。
进入实践-读书-反馈到实践中的优化循环就上路了。 书就先不推荐了，你应该已经有了比较多的代码实践，可以先了解常见的设计模式，然后读一个 mvc 、依赖注入类框架的源码。 PHP 系的可以看看 laravel 的源码。 |
|
43
winiex 2017-01-03 18:05:09 +08:00
然后就是一些依靠自己平时多关注的最佳实践的积累了，比如看了 laravel model 的设计后你就会发现，一个关系型数据库表在设计字段的时候通常会加入 id 、 createdAt 、 updatedAt 、 deletedAt 等必要字段，然后自己思考后考虑到数据会存在类型、状态，所以每个表还会添加 type 、 status 字段。后来你又看到互联网 web 领域的后端应用一般要求最终一致性并注重低延时，所以你就取消了外键字段，用单独的 id 字段来记录记录之间的关系。
没有多大诀窍，花时间去积累去关注。 |
 |
46
BigDipper7 2017-01-03 20:37:36 +08:00
@winiex 问个问题哈，我还没到架构这个层面，咳咳 取消外键字段的话，那么数据一致性靠代码来保证么，咳咳咳，而且外键依赖不是只影响写入效率么，不影响读吧😊
|
 |
47
mhycy 2017-01-03 21:08:25 +08:00
“看需求”
不要为了应用某种设计模式而强行编码，有时候面条代码（面向过程）反而是更合适的实现方式。 每一种开发理念都有其合适的应用场景的。 （ JAVA 啰嗦，但是在合理设计文档充分的前提下， JAVA 很适合开发健壮性足够高的业务代码。） |
 |
48
konakona 2017-01-03 21:24:24 +08:00
我就给你一个意见：你不要只看 PHP 好吗？
|
 |
49
jeremaihloo 2017-01-03 21:26:27 +08:00 via Android
从最近看 C#的 Orchard2 得到的经验是，多看优质的代码，受益匪浅
|
 |
50
theohateonion 2017-01-03 21:30:14 +08:00
架构这个东西和设计模式一样，属于一套形而上的东西，更像是先人把自己的经验进行总结后的产出。所以最好的方式毋庸置疑是看源码
|
 |
51
tairan2006 2017-01-03 21:39:15 +08:00
看框架源码
|
 |
52
eyp82 2017-01-03 23:08:09 +08:00
个人感觉不用刻意追求这些东西:
1. 平时多看好的项目的代码, 感觉到了自然就到了 2. 可以追求好的架构, 可能会得不偿失 3. 有时候是真没时间搞什么好架构 |
|
53
mokeyjay OP @a15819620038 对对，我确实是想问“怎么在代码里把类组织好”以及“如何设计数据表”
@zuston 额不好意思我点错了 @huijiewei 请问“可测试化”是指单元测试吗？ @winiex 感谢耐心回答，这么多人都推荐 Laravel ，我一定要去看看 |
 |
54
dai269619118 2017-01-04 09:21:57 +08:00
真考虑框架的速度，还不如自己写最基本的 mvc 比 85%的框架速度都快
|
 |
55
zscself 2017-01-04 09:41:35 +08:00
来呀，一起写 Java 呀。[滑稽]
|
|
56
misaka19000 2017-01-04 10:50:57 +08:00
@mokeyjay PHP 我也写过，写完之后发现这货真的是天生就是为 Web 而生的，而且 PHP 的优势就是快，写起来简单，架构能力这种反而是 PHP 的短板，放着 PHP 的长处不用为什么非要去发扬它的短处呢
如果非要谈这些架构，为什么不用 Java ， Python 这种语言呢 |
 |
57
Miy4mori 2017-01-04 15:53:35 +08:00 via Android
想要入门架构设计，推荐你读读软件架构设计，当然，如果你想要的其实是实现整洁优雅，你可能需要的是 effective 系列而不是学架构设计
|
|
58
Miy4mori 2017-01-04 15:57:02 +08:00 via Android
@mokeyjay 如何设计数据表这是需要经验和结合业务来谈的，如果你想要避免设计出反人类的表，你可以读读 SQL 反模式这本书，还是有点用的，至于如何设计出最适合业务的，这个一般没有书讲，只能你自己去深入了解业务，或许可以查查领域模型设计相关的资料。
|
|
59
winiex 2017-01-04 17:55:55 +08:00 1
@BigDipper7 一致性是分几个级别的，一般来说，除了类似于支付宝设计资金流转这样的一致性极敏感业务， web 后端的一致性要求都不高，在 CAP[1] 中 Web 后端应用舍弃了 C ，而强调 A 、 P 。
至于不用外键，这个原因很多，你可从 Web 后端应用的特点与外键的优劣来理解，可以参考这个[2]。举个例子， Web 后端的业务决定了删除数据记录以置脏位为实现，外键也受到了类似的限制。带外键的表写入效率低下是主要原因之一，外键不能支持后端数据库服务水平扩展（简单描述的话就是加机器）也是一个重要原因。 [1] http://julianbrowne.com/article/viewer/brewers-cap-theorem [2] http://stackoverflow.com/questions/83147/whats-wrong-with-foreign-keys |
|
60
BigDipper7 2017-01-05 00:20:52 +08:00
@winiex 谢谢大佬，嘎嘎，从来没想过这个，涨姿势了 😄
|
 |
61
garveen 2017-01-11 16:21:43 +08:00
@denghongcai 抓了个现行 /滑稽
|
|
62
denghongcai 2017-01-12 12:25:14 +08:00
@garveen 略有点尴尬，把 fork 版本发出来了 https://github.com/garveen/laravoole
|
Select Language