某IT公司员工发帖：
我是今年刚进公司的一名程序员，
每天都是最后一个走的，
写代码慢吞吞的，测试了又测试。
结果试用期快到了，
领导把我叫到办公室说：
"你写代码太慢了，不适合我们团队，
建议你另谋出路。"我当时就懵了！
没想到第二天，
公司的核心系统突然崩溃，
排查代码发现全是bug。
最后只有我写的模块还能正常运行，
而且经得起大量用户访问的压力测试！
领导立马改口说："看来是我看走眼了，
你来当技术主管吧！"
这段经历让我想起自己刚毕业那会的遭遇。那时候我在一家外包公司干活，每天面对的都是各种各样的项目需求。别人都是拿到需求就开始写代码，一天能写几百行。
而我呢，拿到需求先要分析半天，画各种流程图，考虑各种极端情况。等我开始写代码的时候，别人都已经提交测试了。
项目经理看我进度太慢，没少在周会上点名批评我。直到有一天，我们接了个银行的项目。这个项目涉及到资金安全，银行的测试特别严格。结果呢，其他同事写的代码，一个个都被测出问题来。
而我的代码，愣是一次性就通过了！从那以后，项目经理再也不说我慢了，银行那边还特意发了一封表扬信。所以我后来总结出来一个道理：在IT行业，"快"真的不是最重要的。
我见过太多因为"求快"而埋下的坑：
第一种坑：重复造轮子
有的程序员为了赶项目进度，随手写一段代码就完事。结果一个项目下来，相似的功能写了好几遍，后期维护特别困难。
而那些看起来"慢吞吞"的程序员，往往会先整理现有代码，把通用功能抽象出来重用。表面上慢了一点，但是代码质量和可维护性都很高。
第二种坑：边界条件没考虑
很多程序员写代码只考虑正常情况，异常情况完全不管。等到系统上线后，各种奇怪的bug就冒出来了。
比如有个同事写了个处理用户输入的功能，正常输入没问题，但是用户如果输入特殊字符或者超长字符串，系统就直接崩溃了。
第三种坑：没有做性能优化
有些程序员为了快速完成任务，写出来的代码虽然能用，但是效率很低。等到用户量上来后，系统就扛不住了。
我之前就见过一个例子，一个查询功能，别人写的代码要跑10秒才能出结果。我重构后，只需要0.1秒就能完成。
所以说，在软件开发中，真正重要的是：
1、代码质量
好的代码应该像搭积木一样，每个模块都很稳固，可以随意组合。而不是像贴膏药一样，到处都是补丁。
2、系统可靠性
系统要能应对各种异常情况，不能说用户随便操作一下就崩溃了。这就需要在开发的时候多考虑一些边界情况。
3、性能表现
代码不仅要能用，还要用得好。该用索引的地方要用索引，该缓存的数据要缓存，这样才能保证系统在大量用户访问时还能正常运行。
其实不光是写代码，很多工作都是这样的。看起来"慢工出细活"的人，其实是在未雨绸缪，在考虑更多可能出现的问题。
而那些看起来"快"的人，可能只是在给自己挖坑，等到问题暴露出来再返工，那才是真的慢！
就像我们经常说的：磨刀不误砍柴工。写代码也是一样，前期多花点时间在设计上，后期bug少了，维护起来也容易了，这才是真正的高效！
所以，当领导说你做事太慢的时候，不要慌。重要的是让领导看到你"慢"的价值：
第一步：做好文档记录
把自己为什么这么做，考虑了哪些问题，都详细记录下来。这样领导才能理解你多花的时间都用在哪里了。
第二步：做好单元测试
写完代码要做充分的测试，把测试报告保存下来。这样可以证明你的代码质量确实比别人高。
第三步：数据说话
统计一下修复bug的时间成本，用数据证明你的方式虽然开发慢一点，但是后期维护的成本大大降低了。
最后送大家一句话：在IT行业，不是跑得快的人赢，而是走得稳的人赢。因为代码写得快，只能说明你会写代码；代码写得好，才说明你懂软件开发！
