码畜总结一下主观经验清单：
强调自己只写某某语言的程序员，80%情况下，代码都没法看。
每个语言都是一个思维体系，每一种不同编程范式更是迥异的思路。只接触一类编程模式，很难打开眼界，让自己有新的提升。
当然，我有拉黑两个语言： Php、JavaScript。
大部分的通用性设计最后都会沦为无用的代码，毕竟，架构师级别思考的需求出现的概率小于1/10000。
为了通用性，需要更多的精力去思考额外的设计。这些精力，在我看来，还是好好分配给API设计 & 变量起名上吧。
不要一套代码里面各种代码风格，一会下划线函数名，一会驼峰，驼峰还能出现首字母大小写不一的。
有些语言也提供了官方的指导，比如，Python就是PEP8。Java按照主流IDE写出来的也都是统一风格。
从编程的角度来看，API设计才是最核心的工作。
最基本：接口名称、参数顺序、参数名称。
进一步的，在思考API的过程中，会迫使自己更好的思考代码中的功能划分。就像Test Driven的过程中也会迫使自己设计更清晰、易用的API。
所以TDD的目的不是为了那几个test case，而是让你反思自己的API，提升代码的易读性（也就是 eating your own dog food）。
不要用handler这种没有意义的类型名&变量名，没有一毛钱的易读性可言。英语非母语，但是可以查查词典再决定用哪个名字比较好。
变量名的简写，也要符合惯例，能往惯例上靠的，就不要自己发明简写了。
能交给编译器检查的，不要自己操劳了；能交给类型推导的，省点力气，少打几个字母也好。
编译期就尽量把能处理的错误都覆盖掉，比跑起来半途调试要省力很多。有些代码想用通用类型包装抹掉类型，得不偿失。
既然已经使用OO特性了，就一定要利用好： 能包装的都包装好，能不暴露就不暴露内部。
设计好符合使用场景的API很重要：API设计的不好，又需要把一些比较基本的类型暴露出来。暴露数据结构中的变量与使用全局变量没什么本质区别，只会让人想把你弄死。
做不到的话，那还不如不用OO，多了包装，易读性还没提升，图开心么…
有比较标准的三方库就直接用，不要自己搞一些幺蛾子。自己写的东西八成不如人家的，而且还增加了维护成本。
业余自己可以造轮子玩啊，当然996的这种人可能不明白业余造轮子的乐趣，毕竟可能他们连性生活都没有，虽然我也没有，呵呵。
清楚简单的代码比套用设计模式更重要。
设计模式只是提供了一个guideline，以及行业共识，方便沟通和现用。
但不是为了设计模式而设计模式：代码里面套一堆模式只为实现一个功能，实际上很简短的代码就可以完成。
绝大部分情况下：易读性 > 一切。
程序员么，就是个文字工作者。写出来的东西别人读不下去（或者自己也读不下去），是不是不太符合文字工作者的自我修养？
这样的函数不管是调试还是阅读，都容易让人产生骂人的冲动。（我的）理想的函数就是：1+N输入（1可能是被修改的，N不允许被修改），1输出，完成1功能，错误流程可以用异常。
已经是现代社会了，写代码要关注的还是生产力水平。IDE整体上还是代表了先进生产力的方向。
Emacs、Vim、甚至VSCode，都不能称为一个完整的IDE。
一个技术型公司，理应在这些方面为员工投入，其实相对程序员的人力成本、公司的运营成本，这点钱根本微不足道，顺路还避免了法律风险、提升了生产力、增加了员工好感、还能有商业支持，真的，血赚的买卖。
举个例子，同样一件事：
Python和Java同时都能做，选Python。
Java和CPP同时都能做，选Java。
不要谈性能、不要谈性能、不要谈性能。
能够通过更底层的语言对硬件有更精细的控制，带来性能方面大范围提升。这样的程序员百里挑一，先掂量掂量自己组里有没有这个价位的人。不论是个人还是leader，对自己的状况要有基本的AC数。
真碰到热点了，可以用底层代码写个接口给上层调。相比整体替换底层语言，这对个人或者团队的技术要求低几个数量级。
工具就是技术的杠杆，你买房知道贷款、炒股知道融资，写起程序来就不管不顾工具开发了，想不开？何况工具带来的自动化、标准化，就是工程方面的追求方向。一个工程师，不去追求自动化、标准化，难道追求“工匠精神”，天天弯腰驼背在工位上磨玻璃？
雄性动物对于尺寸的追求有一种魔怔，追求对了领域和方向也没什么问题。
但是，一天到晚只追求代码行数、新feature数量、项目越复杂越high，是不是就有点…emmm… 当然，谁X大，谁说了算。