2019-02-21可读性，可扩展性，性能，可维护性。我写代码围绕这 三点。老师讲的我认为可以划分在可读性。除了了老师讲的业务命名，可读性还有：适当的注释，方法内适当的拆分以保证方法内主流程简洁，减少多层嵌套判断，规避复杂判断条件，采用公司统一编码风格等等。扩展性：采用合适的设计模式，遵循各种规范协议，比如java的草案，采用主流框架，比如java的spring全家桶。性能：有意识的去减少网络io，规避长事务，敏感的时间复杂度和空间复杂度的变别能力，jvm的运行原理，快速精准的测试能力。可维护性：规范的日志记录（其他监控什么的跟编码无关了）。代码规范的书：阿里的<码出高效>和<阿里开发手册>很不错，推荐。作者回复: 很好的补充。
但我不是只在写可读性的角度，我讨论的是大家思维中的盲区。我知道，很多书和文章也会告诉你那些基本知识，我想给大家补充的是，一条主线，一条把这些知识贯穿起来的主线，这是你在别的书和文章中不容易找到的东西。缺少了这条线，你虽然很努力，出了问题依然不知道是哪出的问题。 9
2019-02-20英语是很重要，有时候定义一个属性名称，还得去理解一下类似的词的意思，比如说state和status，class和category之类的，还要考虑下哪个词短一些、哪个是领域内或者老外常用的、哪个更好让英语不好的人看懂(包括自己)……感觉对我这种英语不算好的人来说，挑个词挺花时间的(算强迫症吗？)作者回复: 多练习
5
2019-02-20在一些特定情况下，我还用中文甚至中文短句命过名。虽然看起来有些古怪，但考虑到如果不用中文就要用复杂的英文名还要辅助注释才能看明白，就两害取其轻了。毕竟代码是让以后的人看懂，不管是自己，还是交接给别人。另外，代码最好能在几十行以内。还有，可以通过写容易懂的测试代码来展示复杂代码所要表达的逻辑，有些时候比注释管用作者回复: 对程序员来说，加强英文学习是一项必修课。我们以为中文好用，一个原因是没找到好的英文说法。在我的实践中，我会先去找到这个领域模型的英文表达做成词汇表，然后再开始写代码。
用测试当注释倒也是我经常使用的手段。 4- 2019-02-22order 这个例子举得特别形象，深有体会。我们这边就是写代码的时候一个地方把task名字占用了，然后其他地方的task懵逼了
作者回复: 起名字难，难在起一个具体的名字，很多人太容易随手起一个通用的名字。
3 
2019-02-21领域驱动设计确实是写出合适的代码结构的一项训练，程序员会不由自主地按照自己的习惯，也就是按照计算机运行逻辑去设计代码，这样的代码很容易陷入难以维护的坑。在开始动手写代码之前跟用户交流清楚，理解设计的概念、流程、使用场景、特殊情况，这些都很重要。另外我特别关注的一点是可变项和不变项的分离，因为我们的业务场景对可扩展性要求很高作者回复: 分清可变和不变，这是很赞的做法！
2
2019-02-20在了解业务的基础上，我觉得写好代码之前要做两个铺垫：设计和分解。设计可以是整体的，也可以是局部的，厘清思路为适度。分解即任务分解，保证代码铺开有章可循。新人入行，有了一闪而过的灵感往往就动手了，随着深入再往返折回很是忙碌，经验不足是客观存在的，但习惯还是早培养早受益，经验不足者那就做些简单的设计，等丰富了再做细致的设计就好，个人倾向于前面多花点时间。写代码要通俗易懂，条理清晰，阶段性项目内部review，让不同模块编写者来执行。另外我是不建议用中文命名的，此时用中文注释补充也未尝不可。作者回复: 有益的思考
2
2019-02-21补课追上来了，写test，有注释，命名经常和接口作用相近类似，尽管有的时候命名会比较长，但是通俗易懂，加上简易几句中文解释，跑完junit，完成一个小小业务实现。刚好最近看了下代码整洁之道，老师也推荐了，确实很不错作者回复: 继续加油！
1
2019-08-09代码也是一门语言，语言的本质就是降低交流成本。
2019-06-20关键代码和我的做法都要写好注释。- 2019-05-22转golang的表示 golang好反人类，好些第三方库都是很简单的一个字母. 比如map m； request r 之类的
2019-05-08【实际上，我们很多没写好的程序有一些原因就是名字起错，把一些概念混淆在一起了】
根本原因是概念混淆，老师讲出了为啥没有起好名字的深层次原因，受教受教！我之前理解的起一个好名字还是低了一个层次。
2019-03-13代码主要是为了写给人看的，而不是写给机器看的，只是顺便也能用机器执行而已作者回复: 这个说法很到位！
2019-02-20取个好名字可以界定清晰概念和辩解太重要了，不好的名字会有很强的误导性
2019-02-20更新了，来学习