如何提高代码架构、设计、优雅的能力？

• 資深大佬 : wumou

  《重构》、《设计模式》

• 資深大佬 : sirius1024

  80%的时间用来设计
  20%的时间用来实施（写代码）
  剩下的漫漫人生，用来重构……

• 資深大佬 : Kirsk

  多读书多思考多写 思考是写的时间 2x+ 不要觉得业务逻辑简单 对屎山零容忍（要么你 diss 同事要么同事 diss 你

• 資深大佬 : redtea

  极客时间还是有些专栏不错的

• 資深大佬 : limuyan44

  抄

• 資深大佬 : sunny352787

  我的方法是重构，不停地重构，代码不断的进化，在这个不断踩坑的过程中自己就会想到一些避开坑的设计方式。
  其实设计啊，本质上就是绕开坑走路…

• 主 資深大佬 : DarkCat123

  @wumou 谢谢。设计模式看了一鳞半爪，对我小的部分提高很大；但是高屋建瓴的方面感觉有点不够。我去看看重构

  @sirius1024 整天都在重构，但是也不知道是更好了还是更坏了。

  @Kirsk 业务逻辑是不简单，不过很多时候总感觉，要不然是“这个需求以后应该不会有共性问题，case by case 做吧”，然后崩了…… 要不然是 “这里我设计一下，考虑到未来，做好扩展性”，结果后来未来的扩展场景和自己设计的不一样，等于增加了更多的困难。

  @sunny352787 这个确实，我每次重构，每次写代码都感觉自己有所提高。但是还是感觉提高得不够，想要找找方法论。

  @redtea 谢谢，我去看看。

• 資深大佬 : xuanbg

  结构！结构！！还是结构！！！

  结构设计对了，你会发现所有的功能都早就有合适的坑位在那里，就等着你去把这些细枝末节拼装上去。结构没设计对，总有些功能只能很不优雅地强行拼凑上去。这个时候，就该重新分析问题解决问题了。如果有时间，最好进行一次重构。

• 資深大佬 : Kirsk

  @DarkCat123 建议视野放高一些 好的设计脱离不了架构 我个人经验的话若是单一需求会去思考业务场景 需求多会从系统整体去看 维度大概是 相关性 抽象层级 粒度 想要做出良好设计脱离不了面对对象 从业务分析下来能够最直接体现业务就是整体的面对对象结构 可以去看下 ddd 之类的。oo 是应对复杂结构的良药 有一本书推荐 聊聊架构 不厚 但是对于什么是架构说的挺好 也可以从关键词 系统设计去找 内容很多很广

• 資深大佬 : yixinlove

  同样的感觉，期待大佬们的解惑。有时候感觉现在的小年轻们比我们想法更好，不知道从哪里可以学到这些方法论

• 資深大佬 : qinyusen

  怎么说呢，时间是检验真理的唯一标准，实践是学习和成长的最好途径。

  除了历久弥新的《重构》啊还有《架构即未来》这一类理论书籍，我其实推荐是看完之后，套用一些方法，去整理“屎山”，跨过“屎山”

  一般来说，自己的“屎山”最好处理，另外达到什么水平才算满意呢？
  长久使用不需要打补丁是一种检验方法，“或者”最好能达到“并且”，升级功能的同时代码量低于线性增加（比如基础版本 5 个 feature，100 行代码， 后续连续 3-4 次升级每次 5 个 feature，代码到 500 行了，然后新增功能前进行重构，能达到代码行数-100，新增功能，5 个 feature 只用了 50 行就搞定了，甚至，最后没增加行数）

  另外，强迫自己，任何时候，任何规模都都能做到 KISS，DRY，你会发现越来越费神，来找出来一个优雅的方式，解决当下的问题（重构），久而久之，基本上可以做的很好。

• 資深大佬 : James369

  使用场景、互操作性、多写多提炼

• 主 資深大佬 : DarkCat123

  @Kirsk 谢谢老哥。ddd 和 ddia 最近都在看。不过我其实更喜欢 functional 的结构。感觉很 fancy 。
  但是我感觉架构固然重要，细枝末节也挺关键的。
  我司感觉都是架构大体都挺优秀的，但是细枝末节的设计啊 CI CD 啊 代码风格啊，不敢恭维。
  @yixinlove 我就是应届生

• 主 資深大佬 : DarkCat123

  @qinyusen 这个量化的方法很好，我准备观察一下自己这方面。
  不过我感觉这个方法不绝对，毕竟满足这个条件的，也可以是在 shit 上拉 shit

• 資深大佬 : Kirsk

  @DarkCat123 架构也需要在细节体现 不注重细节的架构算务虚 应届生能有这个意识很强了 慢慢体会

• 主 資深大佬 : DarkCat123

  @Kirsk 主要还是压力大，感觉给了我好多新项目。
  工作造火箭了

• 資深大佬 : reus

  推荐一篇文章，Do the Real Thing： https://www.scotthyoung.com/blog/2020/05/04/do-the-real-thing/

  怎么提高？多写，多改进，多思考，少发帖，少求神

• 資深大佬 : binbinbbb

  https://refactoringguru.cn/
  可以看看这个设计模式，重构还没中文化

• 資深大佬 : nl101531

  看源代码，看得多了就有感觉了

• 資深大佬 : limboMu

  我觉得我的路子比较野，推荐主在读的书籍里加一本 SICP

• 資深大佬 : gowk

  Learn By Doing

• 資深大佬 : yixinlove

  @DarkCat123 那你也是后浪了，我这种前浪只能被拍在沙滩上。

• 資深大佬 : qinyusen

  @DarkCat123
  方法不绝对，我只是说其中之一，还有一个东西就是，提前写设计文档画 UML
  我一般要求自己和带的人用 markdown + mermaid 反复画状态转移图， 和状态流程图，和业务流程图。

  第一步 ， 后先审图， 一般一个事情， 三图合一（互相验证没有明显看出来 bug 就基本 ok ），但是一般 3 年以内工作经验的， 都不用 review code，直接 review 这种图，就能发现一堆未考虑的点以及 bug，或者 case by case，抽象做的不好， 图巨大务必还很难看。 这是第一步。 把东西想清楚想明白。 一般都是 keep it simple （设计可读性 + 设计复杂度）的一个 trade off
  新人 审 5 轮，老人审 3 轮。 防止出现设计完全是 bug，或者实现出来，没几天就推翻重写重设计（这个很多软件工程的书里都写的很明白，比如人月神话之类的，越早期的投入，越降低之后的投入，这里越少的投入，后面投入是指数级上升）

  第二部， 写代码，写完代码 review， 一般来说 5 年以内的工程师，自己熟悉的领域不会出大问题（ 3 年左右，还是会出现设计没考虑到实现不好做，或者写代码的时候发现欠考虑了），能做到设计文档和代码 1：1， 但是， 如果有新领域和跨部门配合，还是会出问题。 review 代码的时候，让其自己的设计文档和最后的代码实现进行 PK 。

  一般来说，会出现几种情况（设计文档里命名和代码里不一致这种低级错误，推荐第一次提示，第 N > 3 次直接考虑劝退或劝跳槽, 态度问题无关工作经验，起名都没法 1：1，我怎么能信得过代码实现和设计 1：1 ？）
  1. 手懒，实现的简单，设计了但是没实现或者弱实现
  2. 想多了，代码实现的时候，过度设计
  3.设计能力大于实现能力， 设计的很好实现不出来 =>增强一些奇淫巧技和代码套路的学习
  4.实现能力大于设计能力， 代码里充满了奇淫巧技，做复杂了 ， 很难和 2 区分，需要 review 的人个人能力碾压，才能识别出来， 这里需要考察代码 readable，更高维度的 readable 就是看了设计文档很轻松能对应上代码段， 这里一般是更高维度的 DRY， 因为他们 Repeat 的是之前的小范围的实现方式

  12 其实是 34 的低级版本，其根源就是设计和实现阶段的脑力和体力的输出配比不均匀，我个人认为工程师代码讲究的是设计和实现的期间脑力和体力的持续稳定输出。 减少心血来潮，和状态不好的随意 /敷衍输出。

  做到这点，基本上，代码这边儿就到头了（单纯字面意义的代码，不包含背后业务水平、管理水平、人力架构，项目架构（类似于怎么在合适的时间、合适的项目进度进入合适的人）这些东西）

• 主 資深大佬 : DarkCat123

  @qinyusen
  “我一般要求自己和带的人用 markdown + mermaid 反复画状态转移图， 和状态流程图，和业务流程图。”
  很感谢，我也经常用 md + plantuml，看来无意间做了正确的事情。
  =====

  后面几条非常好，帮助非常大这块。
  我准备去实践了！！谢谢老哥！

  —
  我感觉有时候项目时间太赶，就搞的很难受，很多东西玩的不那么好。 —— 最近准备排期再多给点 buffer 试试。