zartouch

这东西还是需要些经验的。

1. 很多时候设计的不好很大一部分是对业务需求理解不够。设计之前多花时间梳理业务，整理 use case ，画流程图，然后再分模块。 如果业务没理解好，后面的都白搭。
2. 好的系统不是设计出来的而是迭代出来的，特别是复杂的业务系统，很少有人能一开始就设计的很完善，大部分还是根据业务理解加深和新需求的变化，不断完善起来的。你同事能做好也是因为之前类似的经验，踩过坑了。这里你可以自己想过以后多和你同事讨论。重点是思考为什么自己一开始想不到这些点。
3. 去 github 上搜你这个领域的代码，或者就是看公司好的项目代码，多思考为什么这么设计，特别是结合业务来看。 这本质是要提升你自己的思考问题的方式和角度，这个只能多想多练。

一些关于架构，DDD 之类的书，我建议有点自己的思考再看，你现在看了只会有个似是而非的印象，踩过坑之前，很难深刻理解那么做的意义。当然一些基础的设计概念的书籍如 clean code ，设计模式，重构这类的我默认是肯定读过的，否则完全没有理论基础单纯靠经验那也是扯谈，容易走成野路子。

我看楼上一堆言论都是和能力没多大关系，只是关系运气。 不可否认和领导关系好，跟对了领导作用很大，但不妨碍能力强的拿高绩效。有能力的，这个团队任人唯亲难道就不能换一个吗？ 我真没见过几个团队老板不看能力的，除非老板自己也躺平不想好好混了。

我要说的反而是，努力不代表结果，和高绩效更没因果关系，这个绩效既然是你老板打的，老板需要的是对自己重要的人，什么时候别人会对自己重要？如果都做的都是体力活，老板随便找几个初级员工，堆人也能做出来的东西，虽然老板会觉得你够努力，但并不会觉得你重要，因为这类人可替代性很强，在老板眼里最多算个工具人。 这里差异化很重要，你是能解决一类别人解决别人解决不了的问题，还是沟通能力很强能跨部门推进一些别人推进不了的项目，或者做出了某些创新提升了老板的 scope 。 单纯努力把事情做完，做的再快，对老板来也就是个干活利索的下属。

听歌反而是让我集中精神，因为公司的话不断有人说话其实更影响注意力。

就选纯音乐

何况大部分时间都是调试 CRUD ，其实大脑也没怎么动不是

TL 素质差呗，还能说啥.

老板找我也是老板来我工位。 这种就有效避免没有必要的当面沟通。

说个其他的点如果 lz 经常在和沟通问题的时候易怒，控制不住情绪，可能是肝的问题。可以去医院体检下。

我之前也有这个问题，特别是对经验少犯低级错误的人容忍度很低。 后来想想大家都是打工的，组里的人能力各有高低也正常。能把项目从参差不齐水平的团队带出来才是水平。后来我都会注意沟通方式，把一个水平不高，不太聪明的人教会也是有成就感的。

@3dwelcome 我没说你有问题，我说的就是说的东西有问题，或者至少是你翻译的条目有问题。我不在乎你到底是翻译还是什么，我只针对你说的条目 1 ，2 ， 就是毫无逻辑的。 我很难相信好的程序员会说这种话。

再往下看，4 和 7 是废话，不是程序员了解下背景知识都是显而易见的。3. 做创新的项目这种可能性是挺大，但你要说修个 bug 还能有这么大的误差，只有菜鸡才会犯这种错误。5. 前端大佬多了去了，这种结论傲慢且毫无根据。看的我犯呕（我不是前端） 6. 这完全是伪命题，我从来没见过代码写的优雅的会变得难以调试。只有代码写的一坨屎才会让人难以调试。这就像是说程序正确比测试写的全更重要，把一个相辅相成的东西应写成对立的东西，然后弄出个狗屁结论来。

还有搬运还是附上原文和出处。再强调一遍不是针对 lz 你，单纯是针对这堆狗屁不通的言论。最后，我口气可能是不好，但我恶心的是明明各种大佬关于程序设计的好书总结这么多，在论坛上基本看不到，论坛看到的都是这种狗屁不通的爆论。