[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(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。