题
写代码也有一些年数了。虽然写来写去也都不是什么高大上的代码，像支付宝这种日流量上亿数据的处理从来没有碰到过，不过想自己整理一下自己的心得，或者说，总结一下自己的得失，分享的同时，也是提醒自己。
・我不是一个伟大的程序员。
・但我是一个思路清晰的程序员。
・我也是一个不偷懒的程序员。
・我要努力做一个优雅的程序员。
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
・我不是一个伟大的程序员。
可能是我知乎之类的逛的多了，感觉现在很多程序员有一种心理膨胀的感觉，尤其是体现在年轻程序员。
膨胀的心态有各种各样。比如，我现在用的是最牛的语言。又比如，我写了一个很牛的程序。
从一个只会写hello world的菜鸟，升级到一个写个程序能轻易处理千万级数据的高级程序员，确实是很了不起的事情。只不过，回头看看自己写过的代码，8成的代码，可以总结成两种。一种是模仿他人的现有解决方案写出的代码，一种是重复自己过去写过的代码。其实仔细想想，一个程序员会碰到哪几种问题？比如以后台开发为例，批量数据整理，数据库及文件操作，多线程管理，定时批处理等等几大类。大部分的需求，已经有了很完善的解决方案。人与人的区别在于，谁掌握或者精通了更好的，更通用的解决方案而已。毕竟，大家用的，都是同样的基本类库，类似于搭积木，好的程序员，知道如何更加合理的去搭积木。但是，我们很少在创造代码，我们是根据需求在实现，他人的梦想而已。
程序员，大部分是一个工匠。
・但我是一个思路清晰的程序员。
犹如上文所说，程序员，是一个工匠。但是工匠也有高低之分。为什么同样的需求，同样的实现思路，结果上效率和强壮度差了几个维度？很多时候，不是程序员笨，而是程序员的思路不清楚。
很多程序员写了很多年了，写东西从来不思考，只是为了写而写，为了满足需求而写，内部逻辑一塌糊涂。当然，结果论来说，只要出来结果正确，代码再烂不是问题，尤其是对于一个上线的项目，只要不出问题，只要效率没有低到一定程度，运营上不会没事去做修改。但是，这样真的好吗？对于二期，三期或者说新进来的程序员，看到如此思路混乱，逻辑不清晰的代码，只能强忍着恶心去改，甚至，为了维持原来代码的风格，越写越烂。
写代码如何表现出思路清晰？
首先，IO法。I就是input，O就是output。我们先理清楚进来的数据是什么，最终出来的东西是什么。这个很重要。这个不搞清楚，很容易在写代码的时候，逻辑发生绕路或者多余的现象。如果能掐头抓尾，至少在写的时候，不容易迷失方向。
其次，Step法。看到很多程序员写东西喜欢一口气吃出一个大胖子。比如说，大概思考一下，就直接从头写到尾。写的中间，不会去调试自己写的代码，不会去反思自己写好的代码，是不是有冗余的现象。什么是Step法？先根据需求，整理出大概整个逻辑是几个步骤，然后做一个提纲性质的东西，比如说可以写个大的注释。类似于，
用户登录。
1，提交数据的基本确认。
2，数据的合理性和存在性等确认。
3，取得结果的整理。
4，结果的返回和程序的终止。
以上我也就是随手写的，基本来说代码里面这四句注释先写好，然后一步步去实现。实现的过程中，每做完一个阶段，不要急着进入到下一个阶段，而是简单调试写完的代码，回头看看有没有什么问题，尤其是多个步骤实现了之后，思考一下各个处理有没有实现方式不统一或者重复逻辑的，先维护好写好的代码，再进行下一步。其实，不只是写代码，比如我现在写这个文章的时候，我也在不停地回头看我写完的部分，思考有没有问题或者偏离主题内容的东西。
・我也是一个不偷懒的程序员。
不管再优秀的程序员，都会有偷懒的毛病。比如说，当测试的时候出现个小问题，比如数据更新的次数比预期多了一次，但是结果是正确的，就不会去细究问题。又或者，提交代码，发现有个注释没有写好或者根本就没写，觉得没有问题，然后就直接提交了。说起来都是小问题，甚至不是问题，但是往往在最后上线运营或者已经运营一定时间之后，在这个地方出问题了。对于任何细节，不能放松。该写的注释，不能漏，不能随意。数据验证的时候，一定要全部结果都验证，而不是主干数据验证。
比如，正好上个月我就碰到这个问题。因为服务器变更的关系，有一套程序要重新写。其中有一个逻辑，是对一个业务数据表做更新。原来代码对这个表更新的时候，更新日期并没有做修改，只是修改了更新次数。很多时候，我们会觉得，原来写代码的时候疏忽了，这次重写就把这个问题修改了。但我并没有这么做，而是把这个问题提交给了原程序员，确认一下为什么这么写的原因。得到的回答就是，这个表实际的业务数据没有做任何修改，只是做导出的处理，同时把标识符更新成导出完毕的处理。而别的系统根据更新日期来判断有没有业务数据变更的场合做相应处理，所以特例只对表的更新次数做处理。一个简单的确认，避免了一个大错误。
为什么我要专门提出这么一点？因为我在这个上面跌倒的次数，太多了。
・我要努力做一个优雅的程序员。
写程序很多时候是一个机械的事情。很多时候，我们程序员就好像流水线上的工作，高强度机械式地不停重复着同样的事情，同时面对客户不停更改的需求和运营上千奇百怪的疑难杂症，很容易陷入一个暴躁的状态。粗话，脏话，暴脾气，什么都出来了，甚至有很多程序员，以爆粗为荣。
这样并不好。写代码是一个很细心的活，必须要保持一个心平气和的情绪，才能犯比较少的错，或者更高效的去完成任何任务。而且，绝大部分，我们是以一个团队的形式在进行一项工程的开发。如果整个团队充满着戾气和暴躁，那很多事情地协调，根本无法进行下去，每个成员的积极性，也会极大程度的被打击。
其实不止程序员，任何工作，在做事前，首先要先会做人。比如写这个文章的时候，天津权健的某张姓年轻球员因为醉驾进了派出所。很多人都觉得他很好，是中国男足的希望。但是我从来不这么看，从天津和上港两场比赛可以看出，是一个脾气暴躁，素质很差的球员。一个不知道洁身自好的人，很容易因为自己的言行举止，影响到自己的工作。
培养一点小爱好，斯文地做事和交际，是一个优雅的程序员必备的素质。
待续。
