被技术经理指出代码“人一种想到哪写到哪的感觉”，该补科班课程了吗

那就补补对象编程和设计模式。

别在计算机科学导论上浪费时间。
一般推荐你看这本书的人自己都没怎么看。为了显得自己牛 b 才去推荐的。

光看科班书确实没啥好看的，《导论》这种书更是味同嚼蜡。

理论实践相结合还是需要去跟一些名校公开课，比如 MIT 、UCB 、Standford...很多课的精华都在 lab 、project 上，完整跟下来肯定是有很大收获的。但是这个时间值不值得花也是看人...

说个最近的体会。

基础框架对代码的规范作用往往被忽略了。
像 Web 框架 Spring 、Nestjs，已经内化了很多概念、很多经过多年验证的模式、best practice 。
选这样的成熟框架可以很好的帮助提升代码的组织结构。

方向错了。计算机导论、算法不属于你作为后端的技能点。以前听别人扯淡提到过类似观点， [程序员如何避免青春饭-哔哩哔哩] https://b23.tv/npQo6N

计算机科学导论、编译器原理、TCP 协议等属于底层基础，你干活是应用层的事，中间隔着好几层对于你没有任何影响。
算法属于八股（至少对后端来说是这样），只在面试会用到。考算法和高考、考研没太大区别，考完可能完全用不到，是学习能力的一种考察方式罢了。

设计模式可以读读，但平时写的时候可能想不起来。建议多翻一翻自己常用框架、库的源码，看看行家们是如何设计项目的，能对应到哪种设计模式。近朱者赤，近墨者黑，研究行业大师们写的东西总能混到点经验。注意自顶向下，从应用层往下打。一些反例：研究框架原理直奔 socket 连接创建；研究网络协议直接 TCP 。

写 10,000 个小时就好了

Be pragmatic

感觉我回的还是有点歪了，业务上的设计问题，框架、库关系好像也不大。设计好项目还是得参考现成的、流行的同类型项目源码。

想到哪写哪是逻辑不清晰，结构混乱，多看看优秀框架源码，多动手实践，和刷题、计算机基础关系不大

和科班课程没关系，你这个属于是缺少最佳实践的经验和理解
写之前多想想，想明白整体上要写的代码逻辑是什么样的

多看看其他优秀同事的代码，这样学习效率会比看书来得快得多。mentor 说你代码不行不就意味着有其他同事写得比你好嘛，看他们的代码，先模仿着写，然后不理解的地方当面咨询。工程问题的很多 insight 并不是在科班课程能教会你的，科班更多的是解决学术问题~

@Kobayashi 看了半天都在摆弄窗口。

@forgottencoast 你是说那个 B 站视频，我记得本来价值就不大，没有大纲比较嗦，倍速随便听听就好。

mit ocw

就模仿队友里面代码比较好的同事，如果有 Code Review 就更好了

有人帮忙用通俗朴素的语言描述一下 “给人一种想到哪写到哪的感觉” 吗?

听起来只是需要增加一下可读性？《代码整洁之道》或许有点用？

@TomVista 大概就是在着手开发前缺乏整体设计 然后又没有使用通用且方便理解的代码结构去完成功能？

直接看队友的代码，模仿就行，看书是长期回报，短期不明显

谁牛逼就抄谁的

模仿那些不是想到哪儿写到哪儿的同事的代码风格和模块设计，写多了就好了

《 clean code 》《 refactor 》这几本书真的每个搞软工的都该看看。而且 OO 也要多找好的资料看看，接口，虚拟类，继承多态，设计模式这些也不是前人为了搞玄学搞出来的，是真的管用。

@TomVista 大概就是功能没有想清楚就开始动手写，代码很嗦，存在一些重复的逻辑自己也没发现，该抽象的时候也不抽象，完全没有可复用性；改这些代码的时候只能在后面按照原有的思路加一段逻辑。

做业务不就是这样嘛，真正做到面向对象活用设计模式没个七八年沉淀不行吧，行业 top 水平了，不能拿来要求大多数人