当前位置 : 主页 > 编程语言 > 其它开发 >

在追赶产品上线的路上,我们是否为在为将来“埋雷”呢?

来源:互联网 收集:自由互联 发布时间:2022-05-25
在追赶产品上线的路上,我们是否为在为将来“埋雷”呢? 不知道别的公司啥情况,就自己带过的3家公司来说,基本都存在一种普遍的“赶工期”的现象,之所以说是普遍现象,这也
在追赶产品上线的路上,我们是否为在为将来“埋雷”呢? 不知道别的公司啥情况,就自己带过的3家公司来说,基本都存在一种普遍的“赶工期”的现象,之所以说是普遍现象,这也有一些朋友的亲身经历,似乎这就是一种IT行业的特色,毕竟随着互联网化的长足发展,对产品的更新速度是一个空前的挑战!时间就是利润啊,这个道理想必大家都懂,这里就多说了。暂时不考虑这些外部因素的影响,但从产品研发周期上来讲,我们大家在疲于奔命的无休止的为了产品上线,而不断地以铲地皮的速度累积功能的同时,我们也在为我们产品的未来埋下N多的“定时炸弹”!

不知道别的公司啥情况,就自己带过的3家公司来说,基本都存在一种普遍的“赶工期”的现象,之所以说是普遍现象,这也有一些朋友的亲身经历,似乎这就是一种IT行业的特色,毕竟随着互联网化的长足发展,对产品的更新速度是一个空前的挑战!时间就是利润啊,这个道理想必大家都懂,这里就多说了。

暂时不考虑这些外部因素的影响,但从产品研发周期上来讲,我们大家在疲于奔命的无休止的为了产品上线,而不断地以铲地皮的速度累积功能的同时,我们也在为我们产品的未来埋下N多的“定时炸弹”

都有哪些可能的隐患会悄悄地溜进我们的产品中呢?这里结合自己目前正在参与的一个项目,来作为一个引子,谈谈自己的一点个人理解:

1. 不同的编程风格侵入:如果没有事先进行一些编码规范,习惯性规约方面的准备工作,极有可能会造成大家按照自己的风格思路来完成分配的任务项,这样行进的后果很直接,也很显而易见,那就是对后期的二次开发和维护造成致命的苦难!

2. 对某些重要功能进行重复修改:对产品的一些核心的功能部分,如果没有事先考虑得足够透彻,就很有可能会出现在需求的不断演进中,我们要不断地去骚扰这些本应该是最为稳定工作的功能,重复修改这些代码,对每个人都是一大考验,因为光要能摸清它的来龙去脉就要花费很多的时间和精力,而且还要保证与其关联的各种功能的正常运作基础上,添加新的内容,其本身就是一种无形的折磨,极容易引入一些隐性的bug。

3. 缺少产品代码标准库:众所周知,有一些通用的功能代码,应该尽量保存在某个固定的地方,作为一个程序库来使用,这样做的好处就是能够极大幅度地减少程序中的冗余代码量,同时能够给团队成员一个完成相似功能的“参照”,越是做得通用,越能够减少他人使用的难度!反之,不仅会大大降低团队的开发进度,还会造成相同的功能不同的代码思路,这个非常可怕,简直就是后期维护的噩梦!

4. 含糊不清的需求联系:如果针对一些重要的需求功能,总是迟迟不能有一个完整、具体的需求说明,那就势必会造成在版本的不断演进中,不断地出现由于需求调整,导致程序员好不容易搞好的一个功能变成无用的垃圾,这个不但对整体进度造成了影响,更对程序员的心情造成了很大的负面效应。虽说不能完全避免,但一定要有一种预防此类事故发生的意识,越早发现越好。

5. 缺少程序模板的概念:这点似乎和程序标准库类似,但是也略有不同,所谓模板,可以理解为一个程序架子,其涵盖了此类功能通用的功能元素,对开发者最大的好处就是能够让大家只关注于不同功能的区别点区开发,而不用在那些通用的地方花费多余的经历,这也是一种严谨的变成习惯。当然,就算不用,产品一样能够完成开发,不过同样是以牺牲产品代码的简单清晰和引入潜在bug的代价作为前提的。

6. 既是“天使”又是“魔鬼”的脚本大爆炸:这个可能会具体一些,也就是我们再开发一些web应用的时候,往往不注重编写脚本的规范,比如应该如何命名全局的变量;应该如何划分不同的脚本功能块,并尽量行程单独的脚本库;如何处理浏览器兼容问题;如何与CSS协同工作 等等,千万不要小看脚本的力量,它已经用它的巨大影响力证明了自己的价值,而web应用中超规模的脚本代码量也向我们证实了其重要性,所以,我们有必要用合理的编码规范、清晰的程序结构、简洁精炼的代码来减少为我们自己“埋雷”的风险。

上面节点主要是源于自己对当前参与项目中暴露的一些问题的思考和延伸,可能对一些从来没有编程过的产品经理,里面有很多东西可能并不十分了解,但依旧有必要和团队的技术负责人一起保持一些基本的关注度,如果放任不管,或只抓人追活,随意安排任务项的话,那迎接你们的极有可能就是一场有去无回的惨烈战斗!


上一篇:C#与闭包
下一篇:没有了
网友评论