到底应该怎么去架构？

[magic3584]

两天时间看完了《架构整洁之道》（ Clean Architecture ），可能其中代码很少，看完了觉得自己收获并不多，心塞。

为什么不 show me the code 我还好理解点。当然也可能是我太菜了。。。

[thevita]

这种情况就是 代码写得太少，理论看得太多
---
看不懂 /难理解的时候 跳过就行了，该懂的时候自然就懂了

[ration]

或者先从某方面看，比如设计模式，整本书下来的话涉及的面有点广。

[golangLover]

看來看不懂的不止我一個

[Red998]

架构也不是看看书 。主要看是经验、技术栈的深入。各种场景都有好的解决方案。

[magic3584]

@ration #2 在看的时候也去搜了 依赖倒置等的实现代码，但是跟书里的还是有出入。
@redorblacck886 #4 就是想有代码可能会更容易去理解点，比如《精力管理》这类书我实在是看不进去

[cutepig]

个人觉得架构，设计原则之类的书有点偏哲学了。就是一句话，比如 solid 原则之类的。每个人读了之后理解的可能都不一样。。理解了概念，能不能应用到实际，或者应用的好不好则是另外一件事情

[freeup]

怎么架构肯定是每个人都有自己的想法 我得想法就很简单在满足功能的前提下，尽可能通过架构设计与架构约定保证代码的可迭代，可维护，且能很好的支持可预见性的后续扩展，目的就是在业务的前提下（毕竟很多时候业务会直接影响架构）保证系统逻辑清晰简洁，模块清晰，各种场景处理尽量顺滑
至于 啥高性能，高可用，分布式 这些都是看具体业务场景是否需要着重考虑，不建议一来就搞得高大上，用不上还增加复杂度

[WilliamYang]

非常认同 1L ，新手不推荐阅读，甚至对自己造成困扰。这本书是作者几十年的编程经验总结而成的，要有一定代码行数后才能有所收获

[zmxnv123]

试试 grok_system_design_preview ？
就是比较功利，讲的面试题。

[magic3584]

@thevita #1
@WilliamYang #8
可是，我已经写了 8 年了。。。

[thevita]

@magic3584 没关系，我也工作马上八年了
仅仅是个人最近的感悟
---
不知道你有不有这样的体验：突然某一瞬间，你现实面临的问题 /状况 和以前看的书能对应起来了，当时看不懂的一瞬间豁然开朗了，

认知上有关 信息带宽 的概念，一个人接受新信息输入是与自己当前的认知状态有关的，只能高效的接受 信息密度在一定一定范围 /一定领域 内的知识，这就是为什么有的书看起来那么累的原因

适当选择相对高于自己水平（这个水平没有褒贬之分，抱歉我没想到合适的词）的书，让自己处在带宽相对搞的状态，有助于维持自己持续性的学习能力

对于看起来吃力的东西，也不用因为看不懂就失去信心，妄自菲薄，比如你一段时间回来看，相信你就回有更深的体会。

当然对于技术类的内容，我还是建议应该适当多 push 一下自己。

[magic3584]

@thevita #11
最近翻 CSAPP 的英文原版，读的慢，有疑问自己也没弄明白，题也不会做，只能先跳，跳着跳着就心累了[大哭]