对微软技术的典型误解和偏见

901-陈计节-微软技术的误解

任何个人或单位未获得明确的书面许可,不得对本文内容复制、转载或进行镜像,否则将追究法律责任。

到目前为止,软件授权费用仍是微软的主要收入来源。微软自己的软件卖的很好,同时,在他造就的平台中,提供丰富多彩也高效好用的开发工具,也十分注重培养开发人员的培养。直至今日,企业解决方案仍是微软强有力的现金流。近来几年,微软的路除了企业市场仍持续的稳稳当当,云服务在中国的发展只能说平平淡淡,其设备与服务方面也一路坎坷;甚至由于移动设备上整个行业的发展惊艳夺目,与此相比成熟稳重的 Windows 却难以再给人们太多的惊喜。这样的情景之下,趋利、逐热的媒体会做的自然也就是煽风点火,起哄不怕事大了。不少人,使用盗版的 Windows 去到互联网上,喷着从没用过的 Windows Phone,却又不忘捧一下那个他从没访问成功过的搜索引擎。这样的状况,不免令人感到可悲。

互联网化、云化,以及长尾化发展只会越来越深入;伴随着新 CEO 的上任,微软本身也提出“移动为先,云为先”的理念。近几年,微软在开源社区中也一改以往低调的形象。可是,神奇的是,微软的开发技术在社区里是说不得的。别看博客园、CSDN 等网站起初都是由 .NET 技术人员社区贡献起来的,至今 .NET 背景的人在它们的用户中仍占据一大部分。但把目光转到杂一点的技术社区,或是线下活动,一听说你是 .NET 技术背景的,周围的气氛一下子就变得僵硬了。人们尴尬。尴尬的是,大家都用着 Windows,却又深深地嫌弃着微软的技术;却又不好那么直接地与对面的说话者袒露出自己的这种感受,好像自己也觉得自己的这种嫌弃不是那么上台面、值得怀疑。
对于微软这样一个庞大的企业来说,“微软技术”一词的涵义显然太丰富,而我仅希望谈论其有关 Web 开发和云相关的技术。不少人将 .NET 体系,以及 Windows Server 系列,甚至是 Azure 模糊不清地统称为微软技术,所以我也顺便这样引用一下(就像有些人将 HTML5 称为 H5)。对微软技术的误解与偏见在社区里是很微妙的,不少人对微软的开发技术栈有一些由来已久的偏见。在这里,我列举几点,并指出为什么这些误解与偏见是多么的谬误。

误解:使用微软的开发技术将被绑在微软的产品体系里

软件很复杂,一个大型的软件通常需要多个组件的通力合作才能正常运转。最典型地莫过于数据库、运算逻辑,以及界面或终端设备了。实际上,无论是从法律角度等客观因素还是从目前的现实来看,上面这个命题都是不成立的。
Windows Server 可以运行大量的编程语言平台,部署多种数据库系统,由 Windows Server 提供的服务也不会限制客户端的种类与提供商。在 IIS 上,在 ASP.NET 之外,我们当然也可以宿主 PHP、Java 应用程序,甚至是 Node.js 和 Python 应用程序。而 ASP.NET 作为一种应用程序开发框架,从来也不会限制你使用的服务器类型(Windows 或是其他),也不会限制你使用的数据库,更不会限制客户端浏览器或设备。Visual Studio 会让你觉得拘束,脱离了它不能够开发了?这就更假了,以前大多数人在使用盗版,就算微软提供了免费的 Express 版本;而现在,大家更可以免费地使用官方提供的社区版了。
人们另一个担心是如果跟随微软的脚步走下去,哪一天微软放弃一种技术,自己就跟着走进了死胡同。我的看法是,你就是你,你不必跟随谁的脚步而导致丢了饭碗——如果确实发生了,那你得考虑一下为什么如此盲从以至于失去了自己的方向呢?微软的技术可能由于微软公司的决策而前途未卜,但其他技术更会如此。与微软推行的技术相比,一个开源项目死掉,或者不向下兼容的可能性要大得多。从微软技术的角度来考虑,这些项目被抛弃的原因并非微软随意决策,而是由于它们将退出技术舞台而不再被人们需要,所以它们被抛弃是必然的。而从开源技术上来考虑,一个项目死掉的可能性更高:核心团队的解散,没有经费继续支撑,技术需求过少社区氛围不活跃,碎片化过于严重等问题比比皆是。当然有人会说,如果一种技术开源了,至少自己可以继续使用,或者组建团队维系它的生命。这种毫无水准、巧言诡辩的说辞,我也只好笑笑罢了。

偏见:微软的技术不够开放

开放可以从两个方面来理解。其一,本身的内聚性,以及对关联产品的依赖;其二,开放源代码并且社区友好。第一个方面,在上一个误解里已经谈到。
对于不够开放的开发技术(框架或库),开发人员不敢过多地依赖,毕竟“难以了解它的运行细节,也不能对它进行按需修改”。这个理由是很充足的,开发人员确实在很多情况下,需要了解软件运行的细节,这对对开发框架的理解,解决问题时思路,以及调试程序等方面都有帮助。微软也意识到这一点,因此 .NET 框架的源代码很早就开放了,所有人都可以通过网络获取。不光可以查看源代码,还可以下载编译符号,从而直接调试 .NET 框架本身。
另外,从2014年宣布 ASP.NET vNext 之后,ASP.NET 的开源十分彻底。核心团队将代码迁移托管到了 GitHub 上,使用 Apache 协议授权使用,并接受代码提交。同时,微软还将 ASP.NET 5 及其周边的一系列工具打造成为能够跨平台运行的新型 Web 开发平台。
当然,对于绝大多数人来说,开不开放并没有什么区别。因为他只听说,不开源就是罪。

误解:用微软开发技术很贵

如果放在国外,这句话很真实。在中国的企业,说使用微软技术会贵的话,还是收回去吧,问问你买了几套 Windows,请问一套 Windows 8 Pro 多少钱?是的,微软的很多软件都是收费的,比如 Windows Server,Sql Server,Visual Studio 和 TFS 等。如果是企业里的应用平台,那么这些软件的授权费用确实不菲。微软的软件产品我不评论,自当有愿意购买它们的企业来买单。对于大型企业来说,花钱买软件和服务,还是花钱养人,这是一笔见仁见智的账。企业大了再想,也不迟。

如果是在互联网创业公司里,那么可以有更多选择来节省开支。但开发技术中,我们使用基于 C# 的 ASP.NET 应用程序框架的同时,可以使用 MySQL 和 PostgreSQL 等免费数据库,可以使用 GitLab 和 Trello 等免费的代码与项目管理工具,可以使用 GoJenkins 等免费持续集成工具。

偏见:.NET 开发人员只会拖拖控件

哦,这句话已经很老了,我甚至也不想提了。但这句话很可怕,它简单一句恶毒的话就试图形容一个巨大的群体。我还是不得不在这里说说对这句话,我如何看待。
首先,拖控件并是什么问题。拖控件也并非一种很低级的技术,而且也并不是只有 .NET 开发人员拖控件。相反,它是一种经过高度封装而存在的,非常高效的创建界面的技术。“所见即所得”是它的重要特性,直观而有效。问题出在“只会拖控件”上。如果一个人只会拖控件,那他根本还不能称之为开发人员,最多只能说是见过 IDE 而已。因此,.NET 开发人员只会拖控件这句话显然是不成立的。
微软一直致力于降低开发软件的难度:

  • 在本身就易用的操作系统中提供大量可编程的特性
  • 在提供的几乎所有的大型软件中提供可编程的接口和能力
  • 发明了多种编程语言,并支持多种设计风格与范式
  • 免费提供好用的开发工具
  • 足够大量的用户

这些因素让为微软的平台开发软件变得更容易的同时,也导致出现大量的技能低下的开发者。这是很自然的,也是再正常不过的。比如厨艺,只要有一个厨房,就可以开始,但显然并非所有人都是厨师。而人们总是自以为是的,以为自己会拖一个界面就成为了开发人员。那些井底之蛙们很自然地成为了大多数,顺便把另一批优秀的人代表了。

偏见:就因为它是微软的技术

微软有原罪。我终于无话可说了。
年轻人需要酷,这是容易理解的。微软的技术看起来好像没那么酷。微软并不是一家酷酷的公司,至少比不上另外那些看起来酷的。不过,酷能用来干什么?能吃么,能增加效率么?本质上,酷只是一种主观感受。而主观感受往往与了解它的多少而有所改变。看起 Mac 上的灯,以及整体银色的外表好像洁白无暇的公主般圣美,然而当你搬动它你会发现它笨重的惊人,它甚至还能将你烫伤。Windows 机器看起来中规中矩,却勤勤恳恳,随时为你效劳,帮助你把事情搞定。

结论

微软是一家商业公司,自然需要追求盈利。这并不是什么过错,也无需人们指责。但美好的事物存在了,从不因为他人喜恶而变化。工具也许并没有高下之分,只有适合与否。给你一根金箍棒,普通人也搬不动,更不谈降妖除魔;唯有孙长老才有能力将其发挥到极致。

可笑的人们却总是喜欢用自己那原本就是由屁股决定来的脑袋来教导别人,来宣扬那莫须有的己方,去抨击那空想出来的异已。

有空的时候,去读一读 C# 的代码,去看看 IIS 的管理能力,去试试 PowerShell 的魅力。你会讲一个比我更生动的故事。

Share

浅谈快捷键

又是一个小的分享,落笔成文。开始其实是想做一个文本编辑器的分享,不过在准备过程中,发现编辑器之争很多时候争的却是快捷键系统的设计。总觉快捷键系统的默认设计虽然是编辑器一个很重要的区别,但因为其可以通过插件或是配置的方式转换(例如Evil-Mode),所以快捷键系统的设计不再是某个编辑器的特性,而是一套独立于编辑器之外的系统。而运用好快捷键可以让日常工作生活的效率大幅提升,事半功倍,俗话说,天下武功唯快不破嘛。

回想第一次接触键盘应该就是小学时代玩过的打字机了,通过敲击键盘上的某一个按键,驱动一个撞针,将该按键对应的字符的字模打击到色带上,从而在纸上打出该字符,知道为什么我们现在叫“打字”了吧。回想那个时候其实是没有快捷键这么个东西的,连换行这种事情都不是通过按键而是通过手动去移动卷纸的那个机械轴来完成的。

1

随着计算机技术的发展,先后出现了电子打字机(又称文字处理机)和个人计算机(PC),打出来的字不再是印到纸上,而是显示在显示器中。既然是在显示器上,就使编辑功能可以更加强大,我们每按下一个按键做的事情就变成了两种:输入对应的字符或对电脑下达一个命令(移动光标,选择一段文字,删除一个字符等)。

2

而随着人机交互界面和鼠标的发展,我们对电脑下命令这件事有了一个更简单的方式。就是将命令做成可交互的界面元素,例如按钮,然后通过用鼠标点击的方式。这大大的降低了电脑的使用难度,也促使了计算机逐渐走进了千家万户。于此同时,键盘作为输入设备界的老大哥,被成功减负,又逐渐回归了字符输入的功用。

3

可好景不长,随着软件(包括操作系统)越来越复杂,用鼠标点选的效率问题慢慢呈现,毕竟一些常用操作每次都要去移动鼠标点击还是比较低效的。于是我们又想到了键盘这个老大哥,三顾茅庐,重出江湖,键盘又慢慢的替鼠标分担起一些对电脑下达命令的职责,也就有了众人皆知的一些快捷键,例如Ctrl+C。

5

一些电脑的重度使用者(例如程序员和文字工作者),经过对比,发现快捷键对于鼠标来讲还是要快捷得多。毕竟在键盘上按几个键比用鼠标在分辨率日益变高的显示屏上点击一个区域要快速的多,还不包括找到命令对应的按钮以及手从键盘移动到鼠标,再从鼠标移动回键盘所消耗的时间。而快速则保证了我们的思路不会打断,输入(IO)能尽量不托大脑(CPU)的后腿。因此,我们就开始追求起所谓的全键盘操作

正所谓理想很丰满,现实很骨感。随着软件的发展,一个软件能接受的命令动辄就是成百上千的,如何用区区只有100个左右的按键来映射就变成了一个需要解决的问题。率先面对这个问题的就是文本编辑器,所以我们来看看Vim和Emacs是如何来解决这个问题的。

Vim(江湖人送外号:编辑器之神),引入了模式。既然我们在按下一个或多个按键的时候,可能是输入也可能是发送命令,这本身不就是存在这个多个状态么?所以在Vim里就干脆直接加入了模式(又称模态)。也就是编辑器存在不同模式状态(普通、输入、选择),而按键也在不同的模式可以被定义成不同的功能。

Emacs(江湖人送外号:神之编辑器),区别于Vim,默认采用了另一套更容易被大众所接受的快捷键体系来解决快捷键设计的问题,也就是通过快捷键的组合来解决。例如打开一个文件的快捷键是Ctrl+X Ctrl+F。这种快捷键的设计好处是不需要关注当前的编辑器模式了,但缺点是需要按更多的键,可以简单的理解每次按下Ctrl就是在做一次短暂的模式切换。

这是两种快捷键体系设计思路,但是对于我们有什么用呢?随着Vim和Emacs多年的圣战和两者神一般的地位。这两套快捷键体系潜移默化的影响着之后众多的软件的快捷键设计。而我本人所使用的软件中,像Readkit、Airmail类似的软件的快捷键就是混合了Vim和Emacs的一些经典元素的,而Gmail、Trello和Github这种常用的有点逼格的网站都一定程度的借鉴了Vim或Emacs的快捷键,如果使用Chrome还可以使用cVim这种神器,而MacOS更是原生就支持Emacs的一些核心快捷键。所以说理解学习这两种快捷键体系,对我们将大有好处。

设计并使用好系统级别的全局快捷键,也可以大幅提高我们的日常工作生活效率。我使用的是MacOS系统,将日常常用的功能通过Quicksilver和Alfred软件的功能定义成为系统级别的全局快捷键。总之打磨出一套适合自己全局快捷键是一件费心费力但绝对值得去尝试的一件事,下面是我自己录的一段演示视频。(由于优酷上传的视频被屏蔽,所以只提供YouTube视频链接)

https://www.youtube.com/watch?v=ZA9S7GPuj1E#action=share

快捷键作为我们对电脑发号施令的一种方式,已经比使用鼠标点击的方式快捷的多。那还有没有比快捷键更快的方式呢?答案就是自动完成。

说起来很玄乎,但其实很简单。回想一下我们天天做的事情里有多少是在反复重复的:切换应用的时候切换输入法、讲PPT的时候经常要把电脑从休眠唤醒、离开电脑的时候要锁屏,回来的时候还要解锁、浏览各个网站的时候需要重复地输入密码。

而以上的事情其实都可以通过软件来自动处理。例如可以使用Keyboard Pilot软件自动完成软件切换时的输入法切换、可以使用Caffeine可以避免电脑自动休眠、使用MacID连接手机后可以根据手机与电脑的距离自动锁定解锁电脑、使用1Password来自动帮我们输入密码。这样的例子还有很多,为了让生活每天变的好一点儿,值得我们去不断探索。

同时需要记住,在达成同样目标的前提下,比“做的快”还快的就是“不用做”,快捷键如此,开发软件如此,生活亦如此。

-注:本文中引用的图片全部来自网络,视频为原创,由于优酷上传的视频被屏蔽,所以只提供YouTube视频链接。

Share

HTTPS背后的加密算法

当你在浏览器的地址栏上输入https开头的网址后,浏览器和服务器之间会在接下来的几百毫秒内进行大量的通信。InfoQ的这篇文章对此有非常详细的描述。这些复杂的步骤的第一步,就是浏览器与服务器之间协商一个在后续通信中使用的密钥算法。这个过程简单来说是这样的:

  1. 浏览器把自身支持的一系列Cipher Suite(密钥算法套件,后文简称Cipher)[C1,C2,C3, …]发给服务器;
  2. 服务器接收到浏览器的所有Cipher后,与自己支持的套件作对比,如果找到双方都支持的Cipher,则告知浏览器;
  3. 浏览器与服务器使用匹配的Cipher进行后续通信。如果服务器没有找到匹配的算法,浏览器(以Firefox 30为例,后续例子中使用的浏览器均为此版本的Firefox)将给出错误信息:

ssl-error-no-cypher-overlap

本文将讲述如何探究这一过程。

1. 浏览器

浏览器支持哪些Cipher?这取决于浏览器支持的SSL/TLS协议的版本。习惯上,我们通常把HTTPS与SSL协议放到一起;事实上,SSL协议是Netcape公司于上世纪90年代中期提出的协议,自身发展到3.0版本。1999年该协议由ITEL接管,进行了标准化,改名为TLS。可以说,TLS 1.0就是SSL 3.1版本。在Wikipedia上并没有SSL独立的条目,而是会重定向到TLS,可见两种协议关系之紧密。目前TLS最新版本是1.2。互联网上有超过99%的网站支持TLS 1.0,而支持TLS 1.2的网站尚不足40%。打开Firefox浏览器,在地址栏中输入about:config,然后搜索tls.version,会看到下面的选项:

about-config

其中security.tls.version.min和security.tls.version.max两项决定了Firefox支持的SSL/TLS版本,根据Firefox文档的介绍,这两项的可选值及其代表的协议是:

  • 0 – SSL 3.0
  • 1 – TLS 1.0
  • 2 – TLS 1.1
  • 3 – TLS 1.2

因此上图的设置说明当前浏览器支持协议的下限是SSL 3.0,上限是TLS 1.2。现在,如果把security.tls.version.min一项改为3,那么浏览器就只支持TLS 1.2了。前文提到,目前只有不足40%的网站支持TLS 1.2,比如Amazon就不在这40%之列,所以此时访问https://amazon.com,就会收到“Secure Connection Failed”的错误信息,如图2所示。

了解了SSL/TLS协议后,可以使用Wireshark(或类似的可以抓去网络包的工具)通过分析网络包的信息,来查看浏览器发送给服务器的所有Cipher。Wireshark是一款使用简单却非常强大的抓包工具。

浏览器会首先发起握手协议,既一个“ClientHello”消息,在消息体中,可以找到Firefox支持的Cipher。在Wireshark中,按照Protocol协议排序,然后从TLS 1.2协议的报文中找到一个Info为“Client Hello”的。选中这个,然后在下面的报文信息窗口中依次找到Secure Sockets Layer -> TLSv1.2 Record Layer -> Handshake Protocal -> Cipher Suites。例子中的第一个Cipher是TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,一共有23个:

wireshark-screenshot-clienthello

如果继续找一个Info为“ServerHello”的报文,可以在类似的位置找到服务器返回的Cipher,在本例中是TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:

wireshark-screenshot-serverhello

关于密钥算法这一长串名字的含义,后面说明。接下来,浏览器就要等待服务器响应它的请求。我们来看一看服务器端都做了些什么。

2. 服务器

让我们以Windows为例。若要查看操作系统支持哪些密钥算法,可以运行gpedit.msc,依次进入”Computer Configuration” -> ”Administrative Templates” -> “Network” -> “SSL Configuration Settings”,这时可以在窗口右边看到”SSL Cipher Suite Order”项:

gpedit

点击该项后进入”SSL Cipher Suite Order”。这里可以看到操作系统支持的Cipher的集合,以及对不同Cipher的排序

ssl-suite-order

如果需要调整这里排序,或者去掉一些弱的Cipher,可以点击左上角的“Enabled”,然后在“Options”中重写编辑Cipher的列表。如果喜欢命令行,可以通过下面的Powershell命令修改密钥算法套件:

1
Set-ItemProperty -path HKLM:\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\0001002 -name Functions -value "XXX,XXX,XXX"

那么Cipher的这一长串名字是什么含义呢?其实,每种Cipher的名字里包含了四部分信息,分别是

  • 密钥交换算法,用于决定客户端与服务器之间在握手的过程中如何认证,用到的算法包括RSA,Diffie-Hellman,ECDH,PSK等
  • 加密算法,用于加密消息流,该名称后通常会带有两个数字,分别表示密钥的长度和初始向量的长度,比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256
  • 报文认证信息码(MAC)算法,用于创建报文摘要,确保消息的完整性(没有被篡改),算法包括MD5,SHA等。
  • PRF(伪随机数函数),用于生成“master secret”。

完全搞懂上面的内容似乎还需要一本书的介绍(我已经力不从心了)。不过大致了解一下,有助于理解Cipher的名字,比如前面服务器发回给客户端的Cipher,

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

从其名字可知,它是

  • 基于TLS协议的;
  • 使用ECDHE、RSA作为密钥交换算法;
  • 加密算法是AES(密钥和初始向量的长度都是256);
  • MAC算法(这里就是哈希算法)是SHA。

熟悉了Cipher名字背后的含义后,让我们看看像IIS这样的Web服务器如何选择一个密钥算法呢?假如浏览器发来的密钥算法套件为[C1, C2, C3],而Windows Server支持的套件为[C4, C2, C1, C3]时,C1和C2都是同时被双方支持的算法,IIS是优先返回C1,还是C2呢?答案是C2。IIS会遍历服务器的密钥算法套件,取出第一个C4,发现浏览器并不支持;接下来取第二个C2,这个被浏览器支持!于是,IIS选择了C2算法,并将它包含在一个“ServerHello”握手协议中,发回给客户端。这就有了图5中的结果。

3. 选择

作为浏览器的使用者,你可以让浏览器只能访问支持TLS 1.2协议的站点,以获得更好的安全性,以及更差的体验。作为服务器的维护者,似乎将最强壮的Cipher排在前面是正确的选择。就在前不久,我们开发的一个Web报税系统在一次由第三方进行的安全检查中,被报出的问题之一就是服务器默认的Cipher太弱(RC4-based),于是我们使用了AES-based的Cipher,但是密钥长度只是选择了128,而不是256,背后的担忧主要来自于性能——加密与解密是CPU密集型操作,我们担心到报税忙季时,过强的Cipher会带来性能问题。

其实像Amazon和Google这些互联网公司都在使用RC4-based的加密算法。这又是一次理论与实践的交锋。至于这次对于的线上系统所做的调整会不会对性能产生影响,几个月后就能见分晓了。

Share

DHIS2:穷人的大数据

为乡村医疗工作者、乡村教师以及其他类似的深入边远基层的工作者设计IT系统时,数据采集、上报和分析是一类常见的需求。比如说,各个村的村医统计新生儿人数,或者各个村的教师统计学龄儿童人数,然后由村到乡、由乡到县、再到市省乃至全国逐级上报;某个中央机构(政府或者NGO)可以获得全国的分析报表,可以从各个维度分析,可以深入某个行政区域查看具体情况,等等。

dhis2-cloud

DHIS2正是为这种情景设计的软件工具。虽然名字来自“地区医疗信息系统”(District Health Information System),但DHIS2不仅是一个医疗信息系统,而是一个通用的数据采集、上报、分析和可视化平台。这个开源的软件平台在设计之初就针对低资源地区、基层工作者的特点,目前在46个国家(大多是贫穷国家)部署应用,堪称“穷人的大数据”。

DHIS2有几个最大的亮点:

  1. 丰富灵活的数据模型。DHIS2有一个灵活而且通用的数据模型,这个数据模型的核心是基于数据元素的采集。当管理员把需要采集的数据元素配置到一个数据集中,这个数据集就会呈现为一张表单,用户就可以用这张表单采集不同时间、不同组织机构的数据。在这个简洁的核心之上,管理员可以给数据元素设定若干不同的维度,从而获得丰富的信息供分析之用。
  2. 完全RESTful的数据上报接口。DHIS2提供完全RESTful的数据查询/提交接口,从而使前端采集数据的软件不必依赖DHIS2。比如说,你可以开发自己的移动应用,允许用户在没有网络的情况下进行日常操作,有网络联接时自动将数据同步到DHIS2服务器。由克林顿基金会资助,尼日利亚的医疗物流管理系统就是这么做的。
  3. 多样的数据分析和呈现方式。DHIS2提供了基于转向表的分析支持,让数据管理员可以很轻松地定义各个不同维度的分析。支持各种不同形式的报表当然就不在话下了,都可以在可视化的报表定义工具中定义,而且还有准备好的地理信息支持。如果自带的报表呈现形式还不够好,同样可以通过RESTful API得到报表背后的数据,然后自己做呈现。

根据与克林顿基金会无国界医生等组织合作项目的经验,DHIS2很好地满足了基层采集数据、逐级汇总上报、统计分析、决策支持等常见的数据需求,并且很好地平衡了简单性和灵活性,使得低成本开发高质量的国家级数据管理系统成为可能。

Share

开发软件有多贵

有个朋友的朋友想做一个公益的事。因为出资的都是教育水平较高的精英人士,所以对项目的监控透明度要求比较高。于是这个朋友的朋友就想了,信息时代嘛,IT工具不是可以促进交流提升效率么?于是他对我说:我们想做个app,可以干这个这个这个……我打断他说,别着急,做软件很贵的,你不一定玩得起。

做个软件究竟有多贵?我们可以做一个非常粗略的估算。市场上定制开发软件的人工成本按一人月20,000人民币来算,平均每人天1,000人民币。根据《软件估算》提供的经验数据,随软件复杂度变化,在整个交付项目期间,平均每个程序员每天产出的代码量在2行到200行之间。如果以平均每天产出100行代码来算,则编写每行代码的成本是10元钱。

把软件写出来只是第一步。软件要放在某个环境上去运行的。服务器端的软件要部署在可靠的服务器上,要有可靠的网络连接。客户端的软件(比如一个app)要安装在使用者的电脑或手机上。软件要维护要升级要管理要排错的。有了一个软件,有了一台服务器,就得有掌握这个技能的人来管理它的。根据Oracle引用Enterprise Management Associates的数据,60%~70%的IT预算耗费在运营和维护上。于是我们可以大致估算到,加上运营和维护成本,一行代码的成本就会达到30元。

那么一个app会有多少行代码呢?当然也随复杂度不同会有很大变化,只能举两个例子作为参考。RapidFTR是一个用于“家庭跟踪和团聚”的Android应用。当战争、地震、海啸等灾害发生时,国际援助团队可以用这个应用来寻找失散的儿童。这个软件大约有34,000行代码。另一个Android应用是克林顿健康倡议给非洲国家开发的基层医疗物流管理软件,乡村医生可以用这个工具来管理他们的药品库存。这个软件的代码超过46,000行。换句话说,这两个目标很单纯、功能并不复杂的Android应用,拥有它们的成本都在百万人民币以上。

而且上面估算的还只是软件本身的开发、运营和维护成本。在IT的基础上调整组织机构、优化工作流程、创造高质量内容、市场传播推广……那需要的人财物力就更加难以估计了。更不用说,移动互联网本身是一个充满变化与创新的领域,犯错与试错是家常便饭。所以你看,想开发一个新软件,这是多么贵的事。

软件这么贵,是不是没钱的组织、尤其公益组织就注定享受不到科技带来的强大能力了?不是。其实有大量的软件工具已经存在,它们非常成熟,它们经过了无数用户的检验、能很好地完成它们想要完成的任务,而且它们非常便宜甚至免费。要做个网站吗?Ghost或者WordPress都可以。要点对点的传播?微信和QQ是蛮不错的工具。想收集很多人的观点和意见?金数据就是干这个的。发邮件期刊?可以考虑MailChimp。需要客户关系管理(CRM)?其实一个设计合理的Excel表单就可以做得很好。

所以,一个机构想要用IT技术提升能力,首先需要的是互联网思维,是设计能力。首先理解自己的目标用户,理解用户的整个体验,理解体验之中的困难与挑战,然后选择适当的工具来应对这些困难与挑战。当你把问题细化到一个具体的设计挑战,往往就能找到现成的工具来解决它。至于开发一个新软件这种又贵又费神的事情,还是能不做就不做吧。

本文转载于:http://gigix.thoughtworkers.org/2015/6/3/how-expensive-developing-software/
Share