19、密集恐惧症
代码不要写的密密麻麻，10行以上，看着吓死人。
21、Core和Not Core
合同系统 合同contract相关的逻辑 比较多，代码越来越多，分不清了。
把非核心的 数据导入、数据刷新、工具， 单独 分开。
23、需求是关键，技术通常难度不大，coding只是时间问题
咱们这种项目，关键点是 确认需求。
需求 清楚了，实现思路 才能 准确、简单、清晰，才能给 产品经理、前端、测试 等 讲明白。
24、error日志，不如 企业微信和邮箱
异常情况，都打印error日志。
看 error.log文件，发现 系统中的 各种异常情况。
25、除了分门别类，还要编号，不然看不清
没有编号的，不方便找，尤其是文字太长的时候
26、45度的代码，绝不会是清晰的代码
不清晰的代码，工作就不可能轻松加愉快。
28、不同类型的项目，开发方法论有所不同 （todo）
最近的开发心得：对外项目-客户服务平台、公司核心业务线项目-交付、内部项目-合同、非业务类项目-ehr，不同类型的项目 。
系统内部代码，系统对外接口。
开发方法论 有点不同。
不同点是啥呢？
30、好为人师
又好为人师了。
数学题，思考的多，解题过程简单巧妙。
同理，代码思考的多，写得简洁正确。
以上代码的现有实现。重复代码写100遍，没得卵用。
com.kit.JavaKit.splitAsIntList(String, String)
31、流程先行
想提高生产效率，需要先标准化，然后才能流程化。
流程化，先要线下 跑通，相关人员对于流程有了共识，配合默契执行了。
再搬到线上。
33、文档驱动，规则先行
写代码之前，先明确需求，业务逻辑、流程规则、配置选项，再搞定技术设计、代码流程。
先写简洁的文档，文档驱动，确认后再coding。
coding就是coding，原则上只是时间问题。
35、请给我一个理由
不能别人让咱们干什么 就立即干什么。
至少需要1个why！
为什么要这样做？这样做合适吗？这件事是咱们这个系统应该做的吗？
我觉得应该这样做：1、2、3。。。
36、三言两语，说清问题关键
交待上下文，基本的背景
压缩上下文，别废话太多
组织下语言，打下腹稿，精简话术，逻辑清晰，有条理
换个角度，如果你是信息接收者，能不能秒懂
38、提高个人修养
同时遇到3个疑难杂症的时候，会让人有点抓狂，心情烦躁。
类似的，其它烦心事比较多的时候，一个人的心情、心理、心态，容易爆炸，需要注意控制。
最根本性的方法是：不断提高个人修养。
39、闹钟响起来
“数据服务:数据库，k8s配置”
下次得加闹钟。
简单记记 还是忘了哎 可惜了
40、尽量避免：因为自己而导致项目延期
薪资小程序，下周二左右，会把后端接口 尽快提供好。
按照月底上线的目标去做。
是否上线，能不能上线，重点就看 pm和前端的进展了。
27号，有点迟 ，万一有问题， 就来不及了。
41、对于自己不懂的事情，不要一口咬定xxx
谦虚一点，谨慎一点。
对于自己未知的事情，不要随意下结论，不要一口咬定xxx，不要一口咬定和自己没关系。
都是别人的问题！
来源：oschina
链接：https://my.oschina.net/u/4354729/blog/4633335