软件开发的核心

标签: 软件开发 核心 | 发表时间:2015-12-21 06:17 | 作者:
出处:http://kb.cnblogs.com/

  「我们一直这样做开发,时间做久了,便忘了当初的本意。」

  有关软件系统开发,我们谈些什么?
  我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程。
  我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化)。
  我们谈规模,大容量、高并发、大数据。
  我们还谈可靠性、可用率、n个9、响应时间等等。。。
  这一切的核心是什么?

  先讲个电力行业的一个故事,电力的项目我没做过,对电厂的原理虽有所了解,但看见那些大规模的电站还是感觉挺复杂的。 故事是这样开始的:

  记得有个给我们上培训课的主讲老师是个须发皆白的老先生,进门后掏出一堆零件放在讲台上, 一盏酒精灯、一个小水壶、一个叶片、一个铜光闪闪的小电机、一盏小灯泡。 老先生往壶里倒了些水,点燃酒精灯,不一会儿水开了,从壶嘴里喷出了蒸汽,带动叶片旋转,然后小灯泡就亮了。

  他说:这就是电厂。
  他还说:如果烧的是煤炭,这就是燃煤电厂;如果烧的天然气,这就是燃气电厂;
  如果获得热能的方式是核裂变,这就是核电厂;如果带动叶片的能量来自水从高处流向低处,这就是水电厂。
  老先生说:你们或许会问 “那我们看到的电厂怎么这么复杂”,答案其实很简单, 电力项目需要复杂系统的目的,一是为了确保安全(Safety),二是为了提高效率(Efficiency)。

  安全和效率的平衡,是所有工程技术的核心。

  看完这个故事,我就感觉到所谓 “大道至简” 大概就是这样的。

  开发软件系统的根本在于满足需求,不能满足需求的系统本身是没有意义的。 就像一个再安全、有效率的电厂不能发电又有什么意义呢。 所以软件系统开发也就是围绕根本的基础上确保安全与提高效率。

  需求作为软件的根本差异很大,需求是多样,需求也是复杂的。 一个大型 ERP 系统,一个大型仓储系统,一个大型网站系统,到底谁更复杂,没有一个定量标准,甚至都不好定性分析。 所以前面我们谈软件系统开发那么多内容都是关于 “安全” 和 “效率” 这两个围绕根本的核心。

  所有软件开发的方法论,像瀑布、敏捷到极限编程围绕的是开发活动的效率问题,而编码规范、流程制定、同行评审等等则是有关开发的安全问题。 那么 SOA 化或进一步微服务化其实同时考虑到了安全与效率,服务化拆分有利于大规模开发团队的并行开发,提升了开发效率, 但上线部署复杂了降低了运维效率,但运维效率可以通过自动化来得到弥补,而开发则不可能自动化。

  同理,可靠性、可用性和容灾设计这些活动都是围绕 “安全” 这个核心,而性能优化,提升响应性则是围绕 “效率”。 有些关键的软件系统必须同时兼顾 “安全” 和 “效率”,例如用在飞机、汽车内用于控制起落、刹车、油门的软件系统, 不安全或无效率造成事故是会死人的,而另外一大部分软件系统因为不安全或无效率造成的事故则死的是钱。

  没有人去争论建设电厂到底是不是一门艺术,但肯定有人在争论软件开发(程序设计)到底是不是一门艺术, 但终究大部分的软件系统开发还是更偏向于工程技术。

相关 [软件开发 核心] 推荐:

软件开发的核心

- - 博客园_知识库
  「我们一直这样做开发,时间做久了,便忘了当初的本意.   有关软件系统开发,我们谈些什么.   我们谈过程,编码规范、开发流程、同行评审、结对编程、持续集成,从瀑布到敏捷再到极限编程.   我们谈架构,企业级、J2EE、容器化、SOA(面向服务架构)、Microservices(微服务化).   我们谈规模,大容量、高并发、大数据.

软件开发的“三重门”

- - 酷壳 - CoolShell.cn
自从上次写了“ 程序员技术练级攻略” 以来,就觉得似乎还有很多东西没有谈到,但当时没有继续思考了. 而春节前有人问我,是做底层技术,还是做业务. 这问题让我思考了很多,不由自主地回顾了一 下我这十多年的软件开发经历,并顺着整理分类了一下自己解决过的若干问题,还发散想了很多,经过了一个春节假期的发酵,产生了下面这篇文章.

软件开发模型综述

- - CSDN博客推荐文章
                     软件开发模型概述. 最早出现的软件开发模型是1970年W·Royce提出的瀑布模型. 软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架. 软件开发包括需求、设计、编码和测试等阶段,有时也包括维护阶段.

软件开发的人文关怀

- - 极客公园-GeekPark
我是极客公园黑板报认证值日生. [核心提示]软件可以没有活力,而软件开发却不能没有活力;程序可以像机器一样,程序员却不能像机器一样. 要改变这种状态,就应当增添更多的人文关怀,把开发人员当成活生生的人,而不是视为程序或者工具. 编辑注记:本文来自余晟的博客 乱象,印记. 作者从自己的经验出发,提出了一些给软件开发人员提供人文关怀的可行措施.

软件开发中的两种态度

- - 外刊IT评论网
一种态度认为,应该对程序员在软件开发中的行为进行约束( DirectingAttitude). 持这种态度的人认为大部分的程序员水平都不高(谣传说有50%的人低于平均水平),所以应该对他们所做的事情进行管教约束. 要防止他们做一些可能会给他们正在开发的系统带来危害的事情. 通常,这种态度体现在一些系统设计和工具中时,你会发现它们会试图阻止程序员去做某些事情,限制程序员的一些做法,以此避免他们陷入过于复杂的境况.

软件吞噬软件开发

- - PingWest中文网
软件蚕食世界,自互联网特别是移动互联网连接线上线下服务后,已成为不可逆的趋势. 每一项实用的服务可以由小团队来完成. 以WhatsApp为例,这款被高调收购的IM应用,拥有4.5亿月活跃用户,70%的日活跃率,至今还保持每天新增用户1000万的速度. 但这些服务居然由32名工程师支撑下来了,所以有了业界八卦“每位员工价值20亿”的说法.

防火长城内的软件开发

- - Solidot
对于软件开发者来说,防火长城不只是屏蔽网站过滤流量这么简单——它是痛苦之源,尤其是如果你想开发针对中国市场之外的软件或想利用广泛使用的服务和软件库的话. 上海聊天机器人创业公司Rikai Labs的创始人DC Collier认为,中国的软件开发者写代码的时候一只手是绑在背后的. 防火长城的屏蔽范围日益扩大,这意味着越来越多的服务被永久性或不定期的屏蔽.

自上而下的软件开发和自下而上软件开发

- - 外刊IT评论网
自上而下(Top Down)开发模式是指从一个应用的最高点开始开发. 从最高点逐步往下层编码,直到开发完所有的任务. 一旦写完了最下层的代码,开发任务就完成了. 使用这种方式,你需要设计、编写出所有你需要的但还没有实现模拟接口、服务、伪代码. 自下而上(Bottom up)开发模式是指从一个应用的最底层开始开发.

软件开发团队主管易犯的十个错误

- Frank Cai - 36氪
本文是Roy Osherove在Skills Matter的一次发言,他介绍了团队领导经常会犯的十个错误,并提出了一些解决方案. Roy首先提出几个团队领袖可能遇到的一些问题:. 我如何说服的我团队做某件事情. 我该拿团队里的那个专门搞事的家伙怎么办?. 我们为什么无法远离无谓的争吵呢?. 他说这些问题其实缠绕他多年,接下来他也逐一做出解答.