程序员效率指南

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FKa1yKR0-1692977290141)(https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1542713457862&di=483af4bb44401c549f7cc472bcb96353&imgtype=0&src=http://5b0988e595225.cdn.sohucs.com/images/20170927/c03ff6e28f8c47248cb6273b0811a873.jpeg)]

1. 区分需求的轻重缓急

新手程序员最大的问题就是，在面对一堆需求的时候，不知道哪一个才是重要的，学会分辨重要的需求是需要一定的经验的，这需要在实践的过程中积累。于此同时，需求也有是否紧急的区分，合理安排顺序有利于提高工作效率，减少自身压力。

通常来说，关于需求轻重缓急的问题也可以和需求方沟通，但是主要注意的是，需求方不一定真正理解自己所提出的需求，也不一定能够给出正确的安排。

2. 学会发现伪需求

并不是所有的需求都是有现实意义上的必要性的，这种无意义的需求被称为伪需求，但又总会有一些这样的需求提上来。

例如，需求方要求你给一个列表做搜索功能，然而你发现这个列表的元素个数绝对不可能达到两位数，那么这用十个手指头就能数过来的列表，真的有必要做搜索功能？

对于伪需求，我们要做的就给出理由，并拒绝掉。

3. 深入理解需求意图

很多需求方在提需求的时候，是不会明确的表达真实需求的，而是把自己当成了设计师，自作主张的告诉开发者要做什么，甚至怎么做。

这种需求都不是真实的需求，只是需求方从真实需求的基础上，提出的自己对于这个问题的理解，以及解决方案。因此在接受需求的时候，开发者必须主动弄清原始的需求是怎样的。

这样做至少我认为有两个好处，一个是不会被需求方带到坑里去，另外我们自身可以从原始需求上得到更多的信息，在设计层面留下足够的扩展性。

4. 提高项目决策效率

对于一些项目会议，容易出现冗长的胶着的讨论，大家对一些问题看法不一，然后会议就没有一个终结的时间。因此，对于一个团队，必须有一个决策人，在必要的时候终止讨论，并给出结论。

民主还是专制？在项目开发上来看，让一个优秀的首领决断，比争论不休更有意义。

5. 不要重复造轮子

这是一个聊得挺多的话题，这里就一笔带过。

其实个人也不是说不喜欢造轮子，平时练习造轮子挺好，项目开发上来造轮子，百害而无一利（除非你能超越其他轮子）。

6. 使用配置代替编码

用配置代替编码，有另外一个意思——用代码来写代码。
其实这种思想非常常见，例如很早之前的百度空间（现在已经凉了），就给出了自定义模板的功能，我们只需要拖动一些界面元素，就能配置出自己风格的空间来。这里面就是用到了用配置代替编码的思想，开发者并不需要为每一个博客样式写一遍代码，只需要提供配置的信息，即可生成对应的博客样式。
具体在实际项目开发中，这种方式能大大减少代码量，并且降低出bug的概率。

7. 不要浪费时间在修bug上

这句话的意思不是说有bug不修，而是说尽量不要让代码出bug，如果出现bug也能快速定位问题。

《UNIX编程艺术》里面有强调一个KISS原则——Keep It Simple, Stupid，意思就是事情能够简单办好，就不要把它弄复杂。

对于一份代码，它可以是简单到明显看不出问题，也可以是复杂到看不出明显的问题。

日志系统有必须要对系统的运行状况进行记录，如果能直接从日志中就能定位问题的话，减少了很多调试上的麻烦。

在代码bug这个话题上，有一个比较特别的类别，就是系统限制问题引起的bug。也就是说，你的代码本身逻辑没有问题，只是数据一直增长，导致达到了系统的限制，而导致代码不能正常工作。

例如，腾讯QQ之前的用户QQ号码是用32位int类型存储的，因此它会有一个上限，在之后的一段时间内，腾讯不得不对数据库进行升级，使用64位int来存储。

为了减少系统限制类的bug，开发者有必要做出一些努力，例如良好的内存管理，以及对系统规模的恰当估算等

不过现在计算机基本上都是64位了，在大部分情况下，各位完全不用纠结是用int32还是int64的问题，用int64就好了。

8. 扩展性问题

由于需求总是容易变化的，因此面对变化的需求，程序员也需要做一些预案。

例如，参数能做成可配置的，就不要写死。如果一个变量可能存在多个，但是需求暂时只描述了单个，那么还是用数组，说不定哪天就需要支持多个了，现在就支持多个并不会增加太多成本。

扩展性问题需要紧紧跟随真实需求，程序员也需要有一些产品思维，在设计上预留出可能的方向，不要在变化来临时手忙脚乱。

9. 性能问题

性能问题是程序员都喜欢讨论的一个问题，也是一个学术意义上非常重要的问题，但是，在项目开发中，却通常是一个不用太在意的问题。
项目的开发，是成本导向的，我们需要用低成本来满足项目需求。
项目上线之后，首先要看效果，效果不行的话，自然没什么用户，因此也没性能优化什么事。
性能优化的时机，不是在项目开发，而是在项目维护。等哪天用户量上来了，系统负载越来越高，先加机器，再花点时间研究下性能问题，岂不美哉——至少又做成了一个项目。
性能优化有时候会带来一些负面效果，最常见的就是破坏代码结构，所以如果不是必须，就别去做性能优化。
另外有一种情况，就是代码写得太渣拖慢了速度，修改这类代码不叫性能优化，而是叫修bug。