美文网首页哲思想法
软件工程反思录(三)

软件工程反思录(三)

作者: Svapna | 来源:发表于2020-09-20 12:37 被阅读0次

    前面我们说过从人性的角度看软件工程。经验主义倾向于功利主义,幸福主义,实用主义等。个人利益,幸福的最大化。

    人性本利,利益最大化是功利主义者最终目的。收获最大,同时最少的代价。

    收获最大目的。这个实际上可以理解为是需求问题,也就是我们在做软件工程前,需要先分析工程本身的目的。有目的,才有意义,才有价值

    最少的代价手段。要代价最少,则需要合理使用资源。而在一个软件工程中,资源可以归纳为两点外部资源内部资源

    外部资源。可以简单理解为是硬件资源。古语云:

    巧妇难为无米之炊

    不管有多少人力资源,多厉害的人才,如果不具有硬件资源,也无法实现对应的需求。现代互联网很多高性能,高并发,数据吞吐量极大的软件工程项目,其性能的支持很大一部分来源于硬件资源的叠加。但作为软件工程,  最少的代价是实现利益最大化的手段,因此在硬件资源的选择上,也需要考虑资源的最优化利用,一个是选择性价比最高的硬件资源(经济优化),以及对已有的硬件资源最大化利用(性能优化)。

    内部资源。可以简单理解为是人力资源。有了好的硬件资源,没有人,也完成不了需求,也就无法达到软件工程的目的。人力资源的设计范围很广,下面打算简单粗略地说说,详细的后面的章节再说。

    人力资源的影响因素有哪些?如果用枚举法,把每个因素都进行列举,整个过程就是一个经验性的过程,不太好穷尽,也许随着整个软件工程的模式发生变化后,就会整个因素也会发生变化。因此,我使用另一种方式去说明。

    我把人力资源再按照职能从小到大划分:开发团队(仅开发人员)、技术团队(包括产品,需求人员,测试等职能)、公司团队(包括技术运维、运营)、整个项目全体(包括系统用户,最大相关人员集合)

    开发团队:代码规范、 技术选型

    首先说说代码规范。规范良好的代码可以降低人与人合作的成本。和机器交互,只需要0和1,而代码则是和人交互(包括自己)。代码规范的意义有很多,比如:降低新人接手成本;方便管理人员统一管理,降低管理成本;降低Bug量(包括自身Bug),不管是测试还是生产,Bug都是成本很大的一部分。

    技术选型对于人力资源的意义是选择与当前公司资源情况最为适配的技术栈。技术选型不当一般会出现设计不足设计过度的问题。设计不足的原因是技术选型不能满足当前需求,或者满足需求,但带来了很大的维护成本,比如选择了一个几乎没有什么人使用过的技术,一旦出现特殊问题,带来的人力资源成本也会很大。设计过度,主要是当前的技术选型,超出了当前公司的人力资源,可能表现为人员不足,或者人员平均水平不足。比如一个人维护的简单项目,却选择了复杂的微服务架构,这样对于维护人员来说只会增加维护负担,或者这个项目技术都特别难,普通人需要学习很长一段时间才能真正上手,这样也会带来很大的人力资源成本。

    技术团队:团队协作

    这个就是比较偏向于管理层次的一个问题,但实际上在软件工程里面,技术团队里面的不同职能人员,因为沟通和协作产生的问题,带来的成本也是巨大的。比如开发或者测试人员对产品的需求理解不一致,开发Bug的归属争议等。因此,如果要做好一个软件工程,技术团队之间的协作准备必不可少。在协作工具上,可以选择jiar或者禅道等作为协助工具。日常工作适当增加一些活动,促进不同职能人员之间的默契。发挥每个人的最大价值,减少人与人合作之间带来的协作损失。当然这些是管理学的方法论问题了,本章不详细聊。

    公司团队:后期运营

    这部分是上线后才能感知,实际上对于软件工程来说,这部分的成本不一定少于开发阶段。实际上作为一个软件工程人员,运营思维是必不可少的一部分,运营思维的意义在于:

    1、减少系统上线后,运营人员的工作成本(帮公司省钱)。

    2、减少因为生产问题而对当前项目的干扰。这个问题实际上很容易被忽略,很多时候,开发人员通过1小时或者几小时的安静思考入神后,突然一个生产问题,然后重要+紧急的程度,让你马上从入神中转入生产的问题处理中。解决完了,再重新回来,可能就需要同样的时间才能进入状态。当这种问题一旦多了起来,技术人员的工作时间就一直被这种问题“碎片化”干扰,最终影响了当前正常流程。

    3、减少运维成本,数据库归档或者迁移,服务器维护,网络升级等运维性工作,如果对项目能兼容这种运维性的工作,而无感应,这也是降低成本的一种方式。

    系统整体:可扩展性

    为什么软件工程设计的时候需要可扩展性?实际上如果一个项目设计出来的时候,如果未来都不会发生需求变更,则不需要设计可扩展性。

    唯一不变的是变化本身

    变化并不可避免,因此,可拓展则不能省略。可拓展性,实际上可以看成是降低技术-用户之间的交互成本。如果一个产品或者系统,每次用户需求一变,技术就需要翻天覆地的大改,那么则可能说明一开始技术-用户之间的交互就存在问题。可扩展性是有必要,但不能为了"可拓展性"而"可拓展性",否则就会走向设计过度。设计过度也会造成系统的维护成本增加,用户的需求变更一来,但会因为过度的设计而导致系统很难向用户真正的需求转移。

    软件工程性本利。为了利益最大化,因此一方面做好需求分析(目的),另一方面,则做好资源的优化(手段:最少的代码)。后面分析软件工程的整个过程,也会用"资源"思维进行分析。

    相关文章

      网友评论

        本文标题:软件工程反思录(三)

        本文链接:https://www.haomeiwen.com/subject/qtuesktx.html