我总对自己的写的程序结构不满意，需要补习什么呢

[bmos]

因为大环境不一样，独立成长，总是感觉自己写的缺了点啥。

[xuanbg]

学而不思则罔，思而不学则殆。我建议楼主多画画结构图，不断优化结构，直到自己完全无法再优化的时候再去实现一把。等实现过了，就会有更深一层的理解，又能再次优化结构了。

[chenyu0532]

楼主 ，咱俩有相同的感觉，每次做项目都觉得上一次写的不好，就用另外一种方法来写，改改改到自己觉得满意为止。虽然我的满意其实也不大好。但是现在的水平也就到这了。。

[QQ2171775959]

好好向高手请教一下吧。

[qiumaoyuan]

@whileFalse 我想表达的意思是招式不重要，重要的是解决问题，用最简单的办法解决问题，同时不引入新的问题就行，解决完一系列问题，你说的“设计模式的嵌套”已经自己出来了。

我觉得我们这个圈子里，太多太多人喜欢套用自己先前用过的、或者其它“大公司”分享过的方法 /模式，也就是所谓的“招式”。我更倾向于对每个系统重新做设计。而且我所谓的“设计”并不是扮先知，预言未来的需求和可能遇到的问题。我所谓的“设计”，是在满足且仅满足当前需求的前提下，用最简单的代码来实现需求。对“未来可能”的需求和问题作 0 考虑——就是根本不考虑。未来的东西本来就是不确定的，万一（回顾一下吧，其实是多数时候）你预言错了呢？之前对未来做出的复杂设计就变得一文不值，同时还会是累赘，是负产出。而仅实现当前需求的代码，是最简单也最容易改变的。

设计不是“预知未来”，精良的设计能让改动的成本降到最低，但不可能让你在面对需求的变化时无需改动设计。必须积极地改动设计——在每一次需要改动的时候，不要把这些必须改动的设计积累起来。“拥抱变化”说的是这个。

还是对于“招式”，有件事我们需要明白：方法是用来解决问题的，如果问题不存在，那方法本身根本无意义。

补充一个相关链接 https://www.zhihu.com/question/306481351/answer/562237980

我不知道我是不是废话比较多，其实蛮希望能有朋友能讨论这些东西。谢谢你花时间看完。

[russian]

理论方面可以看看设计模式，clean code 之类。
然后你会发现自己看完之后还是什么都不懂，然后就可以看一些比较好的开源库了。看完了你才懂为什么有些要怎么写

[whileFalse]

@qiumaoyuan 从该帖的主贴内容，我大致判断 LZ 没有到能够“对每个系统重新做设计”的程度。相同的问题对于不同的提问者其答案也不同。


“用最简单的办法解决问题，同时不引入新的问题就行”。
在系统开发的初期，预先想到所有问题几乎是不可能的。当你系统做到 80%的时候，你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作。然后就只能快乐地往代码里拉屎，以绕过这个底层问题。

成熟的框架，不管它写的好不好，其功能限制是已知的，并且也很可能是为大家所默认的。

[hatcloud]

找一个长期做的项目，对代码反复迭代，不停重构。不停用几个标准来 judge 自己的代码：
是否低耦合？
编码风格是否规范？
别人调用自己的接口是否觉得别扭？
是否足够灵活来应对产品需求变更？

标准未必是我提的这些，但一定要要自己的标准，然后在一次次迭代重构中不断往标准靠。

过程中还需要对不同标准的冲突做取舍，去思考，往那个方向靠更加合理。比如低耦合和修改的灵活性有时候会冲突，那可以考虑这个模块是否会有频繁变更的可能性，如果有，那更应该考虑后续维护的低成本上，那么高一些的耦合性是可以接受的。而如果这个模块是基础性的，不会轻易变更，但却会被很多人使用，那低耦合更重要一些。

形成自己的有效的编码标准，有了标准，愿意思考，去看别人的代码，编程结构的时候就能非常有目的性的去攫取自己需要的那一部分来完善自己的编码结构。

另：虽然有些奇怪，我觉得代码不应该最求完美的设计模式。所有的代码都是为需求而生的，所有的思考都应该以满足需求为前提，为了需求做编码风格的让步是很高贵的品质。要追求，应该追求的是最契合需求的代码结构和编码思路。

[carlclone]

同上 , 代码大全 , 全是实用的技巧 , 没有理论的东西

[hatcloud]

接着上面说的，假如是和产品合作，需求是由别人提出的，一定要参与进去。很多情况下，导致坏的设计结构的出现，往往都是因为不合理的需求。尽量去理解需求提出的初衷，并对可能导致坏代码的需求，提出自己的修改意见（不要轻易否定别人的需求）。

[hatcloud]

我不同意楼上的很多人的看法。
我不喜欢「实用」的技巧，倒偏爱「无用」的理论。

[Raisu]

除了看书，可以看一下能找得到的大牛的代码，比如 Peter Norvig,

[qiumaoyuan]

@whileFalse “当你系统做到 80%的时候，你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”，其实这个问题我敢说是基本上就是“预先设计”本身引起的。

或者这么说，如果你的代码一直是完成且仅完成当前的业务需求，那么结果就是你的代码完全贴合业务需求，那么这个时候如果新的需求无法实现，只能说明这个需求本身是错的，你自己会很容易发现这一点。这时候你把问题抛回给提需求的人，他都能够很明白这其中的逻辑冲突。

软件开发中的复杂性我是分为两个部分来看的，一部分是业务逻辑的复杂性，另一部分是代码结构的复杂性，如果完全消除了代码结构的复杂性，那么软件整体的复杂性就跟业务逻辑本身的复杂性趋向于一致。这种情况下，如果新需求无法实现，就只会有一个原因：新业务与旧业务冲突，而不是技术上的问题。反过来，如果业务逻辑确实没有冲突，那么只能说明代码本身对未来的预测与当前业务不符，就是“预先设计”引起的问题。所以我还是拒绝任何程度的预先设计。

另一方面，当“你发现产品的一个新需求无法实现，因为系统完成度 20%时写的底层架构不支持该操作”的时候，如果因为进度或者其它客观原因，暂时没办法花时间和精力去修复，这时候“绕过这个底层问题”也是讲方法的，而不能因为底层已经烂了，上层就随便应付了事。

[qiumaoyuan]

把“烂”的程度控制住也是很重要的。

[Ritr]

说点实际的，不如把代码发出来看看，让大家给你瞅瞅

[gaocc]

@hatcloud 正常项目不断重构是不可能的，不会有领导允许你动稳定的代码。重构的收益是不可见的，而对应的风险是不可控的，所以经常重构代码是不太可能的。

[qfdk]

看一下设计模式吧 然后用最少的代码做出来更多的东西 每个方法都不要超过十行！ 设计模式就是为了解决实践中的各种已知问题. 比如按钮点击可以认为是观察者模式，连接数据库 单例模式等等. 还有一点 看看自己的桌面 有没有做到文档有序的分类，代码也一样. 比如 大学课程 可以分类 大一大二 等等 大一大二之下可以有不同学科 不同学科下面会有 不同类型的课件 比如课件 /01- 数据结构 到 exam 复习 /01-数据结构 再到作业 /01-数据结构 类似于这样 归类一下这样自己也方便

[kidlj]

提高审美，获取对整体的感知力。代码看累了可以读读小说，听听音乐（听整张专辑）。

[version]

用尽量少的代码完成任务，减少代码和业务报错，加快完成工时才是关键的，从中你只能去看现在流行框架的代码和开源库写法，看懂了会搬到自己项目然后不停重构才能学到东西，这样你写新项目就能预知需求预知坑位
如果你真的想要独立发展，而不想架构和脚手架也是别人研究的自己进去只会拧螺丝，那就别用大企业的思路，专心独立做好自己一个小产品，包括私人外包

[petelin]

多看看垃圾代码就好了 再看看好代码
哪有什么捷径 慢慢积累的

[1800x]

既然是独立成长的
那还是应该找个靠谱的技术团队
我目前接手一套代码
写代码的人真的牛逼
可惜
跟楼主情况比较类似，代码相当垃圾