盲目自信，自认为已经敲了几年代码，还看什么整洁之道啊。我那可爱的书架读懂了我的心思，很明事理的保护起来这本小可爱，未曾让它与我牵手
最近项目中的 bug 有点多，改动代码十分吃力，每看一行代码都带一句“这是什么XX代码啊，真XX难改”，这样持续了好几天，有天晚上坐在书房回想这几天发生的一切，仰头定睛思考，我终于和它重新确认了眼神💗
股票见涨你知道买了, 汽车撞墙知道拐了, 孩子死了你来奶了, 大鼻涕到嘴你知道甩了, bug难改知道愤慨了
马上翻开书，前言章节，映入眼帘的就是下面这一张图
代码质量的唯一有效度量是：WTFs（what the fuck）/minute
真的太精辟了，这不就是这几天我白天经历的吗？代码已然是 bad code 了，我们应该怎么面对这种情况呢？
每个公司的规范还不一样，本文是读书笔记，不会说明太多的代码规范，只是阐明我们应该怎样做或者抱着什么样的心态来写代码吧
如果你看到这里，我要引用书中的一句话：
第一，你是个程序员；第二；你想成为更好的程序员。我们需要更好的程序员
专业的态度
做国内项目/产品，通常都是指明deadline的，但是截止到deadline之前，需求量的多少是不固定的，说白了是“以deadline不变应需求万变”，美其名曰「敏捷」
我们经常要面对短期内开发出大量需求的请求，很可能为了快速完成这些需求，胡乱的堆叠代码，上线之后一声长叹庆幸这个功能开发的结束。过了好久，有关这个功能的需求有所变化，重新查看代码时，直接就 WTF 了…，再一看是自己写的，你说尴尬不？
如果是因为任务多胡乱叠加代码，我们就应该在接受需求的时候提出我们的看法：
过多的需求在短期内上线的代码质量不能得到保证
假如你是医生，病人要求你不用洗手就可以给他做手术，因为洗手浪费时间，你会答应吗？医生绝对会拒绝，因为你比病人更了解疾病和感染的风险。如果医生照做，那是绝对不专业的做法
作为程序员，如果遵从了不了解混乱风险经理的意愿，也是不专业的做法
“你以为可以不听经理的？不听经理的，是会被炒鱿鱼的”，经理能否听的进去，我们都要提出我们的看法。提出多次还被无视，也不要灰心丧气，继续提出我们专业的看法… untile die, 为了部落
如果你有底线，守住就好；如果没有，适应就好。只为很久之后看到代码说 WTF 时，避免主角是自己的尴尬
我们是作者
Javadoc 中的@author字段告诉我们自己是什么身份，我们是作者。如果类上没有标注日期和作者，alibaba代码检查工具会给出提示，就像这样：
这里建议大家在 IDE 中安装该插件，如果你不知道作为作者应有的规范，那就让这个插件辅助你吧
据统计，读代码与写代码花费的时间比例超过 10:1， 因为我们在写新代码时会一直在读旧代码，项目越到后期这个比例越明显
我们是作者，就有责任和读者做好沟通。每次写代码的时候，记得自己是作者，要为评判你工作的读者写代码.
这些读者可能是你现在组内的伙伴，也可能是将来要接管你的任务的新伙伴，避免别人嘴里 WTF 的主角是你，定期 Review 自己的代码，你定会发现可以改善的地方，比如用策略模式更改过多的 if else等，代码整洁了，又学会了设计模式，岂不是两全其美
心有余，力要足
很多朋友说，我也想写出整洁的代码，但是目前实力不允许啊。
写出整洁的代码的功力不是一蹴而就的，需要持续不断的学习和修正
学会设计模式，了解 RESTful 接口规范，了解命名规范，注释，函数大小等等太多的东西都是书写出整洁代码必不可少的知识，我们该怎么办？
还记得小时候写作文的词藻不够用，老师让摘抄好文好句。如果程序写的不够整洁，我们可以慢慢学习和模仿好的写法与设计，慢慢改善和积累，有朝一日肯定能写出高分作文的
不做破窗效应第一人
不要说现在的代码很烂了，没必要再改善了，如果你是这样的心态，即便一个全新的项目开始让你去做，你也很可能会成为第一个打碎玻璃，带来破窗效应的人。
如果严重一点说，大家都知道你写的代码带给别人的是一种负担，你可能很难有开始一个全新项目的机会了
如果同事因改善你的代码带来了一些意外的影响，请你不要抱怨甩锅，这些改善就是修复玻璃的开始，终将会给团队带来极大的好处
总结
编写整洁代码的路途漫漫，我们一起求索，推荐大家看下面这两本书，你一定有有自己的发现，让我们悉心照料我们写的每一行代码
灵魂追问
- 工作上你接到过什么奇葩要求？
- 工作中遇到了哪些无奈或者你觉得XX的事？
- 你是怎么应对那些不好的问题的？
欢迎在留言区讨论，你们项目中的情况，你是怎么看待代码整洁这个问题的