当前位置: 首页 > 新闻资讯 > 行业新闻 > 关于软件开发,都应该知道的5个常识(下)

关于软件开发,都应该知道的5个常识(下)

发布时间:2020-01-14        阅读:222

    上次我们讲了“关于软件开发,都应该知道的5个常识(上)”,这次我们来了解一下关于软件开发,都应该知道的5个常识(下),让我们进一步了解软件开发的5个常识。

本文列出了管理者应该知道的5个常识:

1、feature大小并不能预测开发时间

2、伟大来自于成千上万的小进步

3、技术债很讨厌,但不可避免

4、软件不会自己运行(软件需要运维)

5、复杂的系统需要DevOps才能良好运行

 

6. feature大小并不能预测开发时间

 

    feature大小(用户感知到的)与创建feature所需的时间完全无关。小feature可能需要几天或几年的时间,大feature(用户感知到的)也可能需要几天或几年的时间。

我们的工作是创建并支持一个软件开发过程,该过程接受这个事实,并且不是拍脑袋评估工程量。工作量评估本身可能需要令人惊讶的很长时间。

 

    鼓励通过沟通来解决工作量评估的问题。工程师可能会给出一个令人惊讶的很长时间的工作估算,但是也会提出对需求进行更改,从而大大缩短时间。记住工作量评估要包括测试、培训、部署和意外的假期(例如病假)。

 

    在没有与工程部门协商工作量的情况下,永远不要承诺某个feature。这并不是我们在公司的权力标志,这需要的是一个专业流程,在这个流程中,开发人员的请求得到认真对待,评估工作量,并按时交付(或出于诚实的原因延期)。

 

7. 伟大来自于成千上万的小进步

 

    伟大来自于在很长一段时间内所做的成千上万,也许是数百万的小进步(变更)。如果变更的效果都被测量是负面的,那么变更将被回滚。

 

    谷歌也不是一天建成的。谷歌的搜索引擎是数百万个人改进的结果。搜索质量小组每周开会一次,工程师们走上讲台,提出他们的修改建议。他们展示了在模拟的环境中会有多大的改进,委员会进行辩论并投票表决。几周后,将对测量结果进行评审,并决定保留或回滚更改。

 

    谷歌搜索是迭代开发战胜“数据大爆炸”思维的胜利。谁都不可能在一开始做出一个好的搜索引擎。只有在好莱坞电影中,一个聪明的极客才会想出一个惊人的新点子,并且第一次就能完美地实现它。在现实世界中,一夜成名需要数年的时间。

 

    无论试图实现的目标是一个为客户提供更好服务的系统,还是一个更高效、错误更少的系统,还是一个运行更顺畅的系统,都是如此。

 

    我们的工作是要求系统的设计能够容易拥抱新的变化,并定义相关的KPI(关键性能指标),这些KPI可以在更改之前和之后方便地进行度量。最重要的是,必须有一个流程来检查结果,并决定保留或回滚变更。回滚不应被视为失败或受到惩罚。从每次回滚中学到的与在每次保留的更改中学到的一样有价值。

 

    托马斯·爱迪生声称在发明灯泡的过程中测试了1000根灯丝。当一位记者问他:”失败1000次是什么感受?“他回答说:”我没有失败1000次。灯泡是一项有1000个步骤的发明。”

 

8. 技术债很讨厌,但不可避免

 

    技术债务是将来需要做的工作,因为我们现在选择了一个更简单的解决方案,而不是使用一个需要更长时间的更好解决方案。任何合理规模的软件项目都有技术债务。技术债务让所有的进步都变得更慢,越忽视它,它就越像滚雪球一样越滚越大。

 

    有金融背景的管理者听到“债务”时,会认为这是一种未来会有回报的投资。技术债务恰恰相反,它是有毒和痛苦的,并且是一个定时炸弹。

 

    1972年,Fram为它的滤油器做了一个电视广告,在广告中,一位汽车机械师解释说,一位顾客为了节省4美元而不更换滤油器,后来,这位顾客不得不花200美元更换一个昂贵的主轴承。汽车机械师总结说:“你可以现在付给我钱,也可以以后付。”

 

    有一个软件项目,其中有一个子系统与供应商通信。最初系统只与一个供应商通信,所以非常简单。然后又接了一个,然后另一个。有些功能必须实现三次,每个供应商一次,这是不可持续的。当要求支持第四个供应商时,开发人员表示反对。是的,他们可以在大约一个月的时间里把它移植上去,但是软件架构开始吱吱作响,就像飓风中的老房子一样。这些权宜之计积累了大量的技术债务。

 

    开发人员的建议是花两个月的时间重构供应商架构,使其成为一个插件系统。然后,新的供应商可以在一周内而不是一个月内支持接入。

 

    管理者们并不高兴。为什么下一个供应商需要两个多月的时间来支持,而之前的供应商是在一个月内支持的呢?花两个月的时间来偿还技术债务将使未来的支持更快,代码更稳定,并使添加新feature更容易。很难衡量确切的好处。

 

    “你可以现在付给我,也可以以后再付给我"。

 

    我们的工作是分期偿还技术债务。失控的技术债务降低了添加其他feature的能力,并导致软件系统不稳定。偿还技术债务应该与业务目标挂钩,类似于非功能需求。

 

9. 软件不会自己运行(软件需要运维)

 

    虽然供应商和开发人员可能会试图告诉你不同的情况,但是软件并不会自己运行。任何基于软件的系统(特别是网站和web应用程序)都需要运维人员和运维流程。否则,软件就像一本合上的书,必须有人打开它,管理它,以及照顾它的需求。

运维比软件开发本身更重要。代码只写一次,但运行可能会是数百万次。因此,粗略地衡量一下,运维的重要性是否要高出几百万倍呢?

 

    我们的工作就是期望运维成为任何软件系统的一部分。它必须像其他任何项目一样被计划、预算、管理和有效地运行。

 

    运维功能(通常称为非功能需求)对用户是不可见的,除非作为二级需求。数据备份是非功能需求中一个很好的例子。没有用户请求数据备份,但是,用户确实要求恢复已删除的数据。遗憾的是,没有备份就没有恢复。恢复是功能需求,备份是一种运维(非功能)需求。

 

    让软件服务易于维护或高效运行的功能需求从来不会被用户提出来。然而,他们确实享受着一个低成本、高可靠的系统所带来的好处。客户会离开那些不靠谱的网站,再也不会回来。

 

    持续改进的需求不仅包括新功能需求,还应该包括新的非功能性需求。因此,我们的工作不仅是为客户提出的功能需求分配资源,还要为运维需求分配资源。在两种相互竞争的需求之间取得平衡是困难的。

 

    但是,一个成功的产品是业务需求和运维需求的权衡结果。

 

10. 复杂的系统需要DevOps才能良好运行

 

    复杂的系统最好通过DevOps进行改进。DevOps有很多定义,但是DevOps通常看作是通过快速迭代加速交付价值(feature、bug修复、流程改进等等)。要做到这一点,每个相关人员都必须参与。也就是说,他们必须跨职能团队进行协作。DevOps这个名字来自于移除开发人员和运维(IT)之间的隔阂,这对于实现快速的发布是绝对必要的。然而,优秀的DevOps环境将其扩展到跨所有职能团队的端到端工作。

    DevOps被误解为开发人员来做运维。这种“构建它,运行它”的策略是跨职能团队工作(消除隔阂)的一种方法,但它不是唯一的方法。

 

 

    一个复杂的系统需要三件事:良好的流程、所有相关人员的良好沟通以及尝试新事物的能力。

在线客服

  • 销售客服1: QQ
  • 销售客服2: QQ
  • 027-59761867
  • 17786528309