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

[bmos]

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

[zjsxwc]

发出来看看

[trait]

可以看下 代码大全

[jingyulong]

设计模式，重构，代码大全，数据结构与算法分析

[q8164305]

我也是，总觉得自己代码不够好，又不知道怎么改，野路子的好像都这样，哎

[qiumaoyuan]

https://www.v2ex.com/t/569357#r_7412894

09 年左右大概和楼主有一样的困惑。

[cedoo22]

@jingyulong 调下顺序，代码大全 设计模式 数据结构与算法分析 重构

[whileFalse]

设计模式有用。不过我建议读框架源码。

[tt67wq]

补习下心态

[specita]

多写多看吧

[jingyulong]

@cedoo22 #6 赞！其实我是想到什么就写什么。如果要算基础的话，数据结构和算法要排在第一。还有一本《代码整洁之道》不错

[qiumaoyuan]

我觉得建议看源码的最扯淡，我不知道为什么这种说法能一直流行到现在，我也很好奇这些人在说出这些建议的时候是不是真的清楚自己在说啥。

首先，开源代码本身就良莠不齐，请问如何分辨哪些是优秀的？使用的人多就是优秀的？我觉得很多时候恰恰相反。MooTools 这样优秀的开源库就很少人知道，同时期最流行的却是 jQuery。MooTools 在小众的圈子里一直到存活到 CoffeeScript、TypeScript、ES6、ES7 出现之后，开发人员觉得 MooTools 完成使命，可以退休了，官方才宣布停止维护。

其次，优秀的源代码你看过一遍基本上只会有一种感觉：这代码本来就应该是这么写，理所当然的，看过之后根本不会留下什么印象。而让你留下深刻印象的往往是些炫技的代码，这样的代码又只会把人往坑里带。

[brust]

七大原则
设计模式
数据结构
算法
看源码
多看多写
多画 UML

[cedoo22]

@jingyulong 个人把代码大全 排第一，是觉得其中有几章是一些很基本的原则， 像‘变量的力量’、‘工作的类’啊 这些， 数据结构和算法 也很重要，但不能一蹴而就的。

[bmos]

@qiumaoyuan #11 源码偶尔也看看的，确实有这种感觉。

[qiumaoyuan]

@bmos 我觉得完成功能之后，消除重复是首要目标。当你竭尽全力的去寻找消除重复代码的方法的时候，会发现许多面向对象的特性正好可以拿来消除重复；然后会发现设计模式原来是这么回事；会去寻找在当前这个场景下，消除重复最合适的重构手法。所有的面向对象的特性、设计模式和重构手法的应用，全都是最合适的。

但如果一上来就去找设计模式之类的东西，反而会没了方向，学了方法不知道该在哪用。

其实，在“消除重复”之前，还有更根本的东西：“消除重复”的动机是什么？是降低代码结构的复杂性。

前面一直有人在提《代码大全》，《代码大全》里面很重要的一句话大概是这样的（原话不太记得了）“软件开发中的首要目标就是降低复杂性”。而复杂性来源于哪里？一、重复代码；二、糟糕的命名。

[qiumaoyuan]

抓到了根本，招式都是结果。

[bmos]

@qiumaoyuan 谢谢！～

[qiumaoyuan]

@bmos :D 不客气。我之前也是一直对自己的代码不满意。现在虽然也并不是非常满意，但起码方向是清晰的，不像之前那么没底气，写什么系统都 hold 得住，知道自己该如何继续改进。最重要是别放弃这份追求。加油。

[GiantHard]

https://m.douban.com/book/subject/1140457/ 希望这本书能对你有所帮助

[whileFalse]

@qiumaoyuan @bmos

源码相对于书本的优势是，源码提供了一整套场景，并提供该场景对应的解决方案。一套场景是很复杂的，需要多种所谓的设计模式的嵌套。书本提供招式，源码提供套路。你学了一个套路，你就能解决这个套路面临的问题。你学了一个招式，你就看什么都想用这个招式解决；你学了 30 个招式……你就不知道该用哪个。

[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]

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

[whp1473]

学会造轮子，先自己实现，遇到不懂的地方参照同类的程序，多比较几种情况，你就会知道原来这里要这样实现，哦，为什么要用这种设计模式，为什么要用这种写法。
对于只是完成任务的工作，千万不要重复造轮子，浪费时间。
但对于个人的提升，千万要造轮子，只有这样你才能深入理解知识。