所谓软件工程

很多编程的人包括我,头衔叫做“软件工程师”(software engineer),然而我却不喜欢这个名字。我喜欢把自己叫做“程序员”(programmer)或者“计算机科学家”(computer scientist)。这是为什么呢?这需要从“软件工程”(software engineering)在现实中的涵义谈起。

  有人把软件工程这个领域的本质总结为:“How to program if you cannot?”(如果你不会编程,那么你如何编程?)我觉得这句话说得很好,因为我发现软件工程这整个领域,基本就是吹牛扯淡卖“减肥药”的。软件行业的大部分莫名其妙的愚昧行为,很多是由所谓“软件工程专家”发明的。总有人提出一套套的所谓“方法论”或者“原则”,比如Extreme Programming,Design Patterns,Agile,Pair Programming,Test Driven Development(TDD),DRY principle,…… 他们把这些所谓方法论兜售给各个软件公司,鼓吹它们的各种好处,说使用这些方法,就可以用一些平庸的“软件工程师”,制造出高质量低成本的软件。这就跟减肥药的广告一样:不用运动,不用节食,一个星期瘦20斤。你开头还不以为然,觉得这些肤浅的说法能造成什么影响。结果久而久之,这些所谓“方法论”和“原则”成为了整个行业的教条,造成了文化大革命一样的风气。违反这些教条的人,必然被当成菜鸟一样的鄙视,当成小学生一样的教育,当成“反革命”一样的批斗。就算你技术比这些教条的提出者还高明不知道多少倍也一样。

  打破这些软件工程专家们制造的幻觉的一个办法,就是实地去看看这些所谓专家们自己用这些方法论做出了什么好东西。你会惊奇的发现,这些提出各种玄乎其玄的新名词的所谓“专家”,几乎都是从不知道什么旮旯里冒出来的民科,没有一个做出过什么有技术含量的东西,他们根本没有资格对别人编程的方式做出指导。这些人做出来少数有点用的东西(比如JUnit),其实非常容易,以至于每个初学编程的人都应该做得出来。可世界上就是有这样划算的职业,你虽然写不出好的代码,你对计算原理的理解非常肤浅,却可以通过一些手段,得到评价别人的“代码质量”的权力,占据软件公司的管理层位置。久而久之,别人还以为你是什么泰斗。你仔细看过提出Java Design Pattern的四个人(GoF),到底做出过什么厉害的东西吗?没有。提出“DRY Principle”的作者,做出过什么好东西吗?没有。再看看Agile,Pair Programming,TDD……的提出者?全都是一群饭桶。他们其实根本就不懂很多编程的东西,写出文章和书来也是极其肤浅,一知半解。

  所谓“软件工程”,并不像土木工程,机械工程,电机工程,是建立在实际的,科学的基础上的。跟这些“硬工程”不一样,软件弄得不好不会出人命,也不会跟做芯片的公司那样,出一个bug立即导致上亿的损失,身败名裂。所以研究软件工程,似乎特别容易钻空子,失败了之后容易找借口和替罪羊。如果你说我的方法不好,你有什么证据吗?口说无凭,我浪费了你多少时间呢?你的具体执行是不是完全照我说的来的呢?你肯定有什么细节没按我说的做,所以才会失败。总之,如果你用了我的办法不管用,那是你自己的问题!

  想起这些借口我就想起一个笑话:两夫妻睡觉发现床上有跳蚤,身上被咬了好多大包。去买了号称“杀伤率100%”的跳蚤药,撒了好多在床上。第二天早上起来,发现又被咬了好多新的大包。妻子责怪丈夫,说他没看说明书就乱撒。结果丈夫打开说明书一看,内容如下:

本跳蚤药使用方法:

  1. 抓住跳蚤
  2. 掰开跳蚤的嘴
  3. 把药塞进跳蚤嘴里
  4. 合上跳蚤的嘴

  我发现很多软件工程的所谓方法论失败之后的借口,跟这跳蚤药的说明书很像 :)

  人都想省钱,雇用高质量的程序员不容易呀,所以很多公司还是上钩了。他们请这些“软件工程专家”来到公司,推行各种各样的软件方法论,可是发现最后都失败了。这是为什么呢?因为再高明的方法论,也无法代替真正的,精华的计算机科学教育。直到今天还有很多公司推行所谓的Agile,煞有介事的搞一些stand-up meeting, scrum之类的形式主义东西,以为这些过家家似的做法就能提高开发质量和效率。很多开发人员也很把一些软件工程的工具当回事,喜欢折腾Git,Maven等工具一些偏僻的“新功能”。他们很在乎所谓的版本控制,测试等东西,以为熟练的掌握这些就能开发出高质量,可靠的代码。可是你最后发现,无论你如何高效的使用这些工具,它们都只能起到辅助的,次要的作用。编程工具永远不是程序本身,对编程工具的熟练掌握,永远也无法代替真正的对程序和计算的理解。过分强调这些工具的使用,是本末倒置的,让工程走上失败道路的作法。

  编程真的是一门艺术,它完全符合艺术的各种特征,编程界也充满了艺术界的独有特征。有些初学艺术的人(比如10年前的我),总是挑剔手上的工具,非要用最新最炫的工具,用它们最偏僻最难用的“特性”,才觉得自己能够做出优秀的作品。很多人照不出好的照片,就怪相机不好。买了几万块钱的笨重高档相机,照出来的照片还不如别人用手机照的。这些人不明白,好的摄影师和不好的摄影师,区别在于眼睛,而不是相机。一个真正的艺术家,可以用任何在手上的工具创造出色的作品。有些甚至可以用一些废品垃圾,拙劣的工具,做出杰出的,别具风味的艺术品。因为艺术存在于人的心里,而不在他们使用的工具里面。

更多好文章

时间: 01-19

所谓软件工程的相关文章

软件工程——《构建之法》读后困惑

通过一周多对这本新书的快速阅读,发现自己存在很大的问题, 如下: 一.软件工程这门课与JAVA,C++等这些面向对象程序设计应该怎样对接起来? 二.软件工程这门课,除了在上课的时候认真跟着老师的思路走,课后空闲时间,我们该怎样单独,或者在团队里怎么学习? 三.提高我们这门课的能力是通过敲代码,还是提高自己的逻辑思维能力? 四.在即将到来的人工智能时代,软件工程师这个职业是否能一直活下去?

软件工程第二次作业--师兄采访

我采访的是李权师兄,虽然之前也有人采访过他,问题都是同样的问题,不过我挖掘出了和其他同学不一样的信息. 问题:    师兄,当时你们做的项目是什么,有多少用户, 现在还有人用吗? 李权师兄: 当时我们的项目名是约跑APP,当时用户有8人.在用户的手机上测试通过,能让用户找到一起跑步的小伙伴.现在已经没有人用了. 追问:该app给用户提供了什么样的服务? 李权师兄:app能提供给用户认识新朋友的平台.通过app,用户可以约人一起跑步. 第二个问题:师兄这个项目能否给我们团队继续开发,源代码还有么?

软件工程进阶

一直向往 it 行业, 不敢说有很深入的了解, 但一直有想法, 想做自己想做的, 想有我的 team 然而什么都计较那么清楚, 最后把自己吓傻了, 也不去做, 这种结局真的最没什么意思了, 曾经还有很多人还对未来充满决心, 2年内一些人陆续放下了梦想和计划, 上课,打游戏, 吃饭这些是多数人的轨迹, 我觉得可怕, 于是更坚持自己, 尽管知识浅薄, 但也在用心学习每个有帮助的课程, 老师说得对, 实际工作,沟通能力很重要, 软件工程这门课程我同样会用心, 希望有一天,以我之才,何须屈人之下. 也希

软件工程课程设计之XMAL

前言 最近做软件工程课设,因为需要用到可视化界面,经过仔细考察,在小组成员的建议下,最后决定使用XMAL做前台. 题目分析 题目:物理环境包括温度.湿度.大气压力.光照等参量.软件能够以图形化方式,实时显示各参量的状态,比如,显示温度的实时曲线图.具有参量报警功能,能够提供出行意见,具有历史数据查询功能.假设数据以存放在数据库中或文件中. 题目要求用图形化方式实时显示各参量状态,所以前台程序务必足够美观,选用XAML设计窗口界面,C#构建后台.这里主要总结一下XMAL.(我用到的,其实很少很水,

【集美大学1411_助教博客】2017软件工程开跑啦。。。

一.自我介绍 各位同学大家好,我是各位同学本学期软件工程这门课的助教,我叫郑蕊,现工作于吉林省长春市.很荣幸能再一次为<构建之法>担当助教,在之前担当助教的过程中,我已经获益良多,在此还是要感谢周老师和邹老师,感谢两位老师给我树立的优秀榜样,也感谢两位老师对我的教导和引导.很高兴这次能担当集美大学软工课的助教,在15年冬,我曾去过集美大学,那真的是一所风景非常优美的院校,从暴雪的东北到达绿意盎然的夏门,在集美大学的校园中漫步真是一件让人享受的事.希望本学期能和集美大学的同学们共同探讨软件工程,

云计算对于传统软件工程的影响

云计算对传统软件工程的影响 传统软件工程的概念 传统软件工程采用的一是结构化泛型,基本阶段按顺序如下:需求阶段.规格说明阶段.设计阶段.实现阶段.集成阶段.维护阶段.退役等,这是一种适用于代码量适中的传统软件开发方式. 而随着社会进步与技术发展,软件越来越复杂,计算越来越繁琐,代码量也越来越大,存储和处理的信息越来越多,软件规模也越来越大.而传统的结构化设计方法在大规模的软件的开发组织和维护方面困难重重,软件的复用性能也不好.于是发展出了云计算的概念. 云计算的概念 云计算是以数据为中心的一种数

敏捷软件开发VS传统软件工程

敏捷软件开发:又称敏捷开发,是一种从1990年代开始逐渐引起广泛关注的一些新兴软件开发方法,是一种应对快速变化的需求的一种软件开发能力. 与传统软件工程相比,它们的具体名称.理念.过程.术语都不尽相同,相对于"非敏捷",更强调程序员团队与业务专家之间的紧密协作.面对面的沟通(认为比书面的文档更有效).频繁交付新的软件版本.紧凑而自我组织型的团队.能够很好地适应需求变化的代码编写和团队组织方法,也更注重软件开发中"人"的作用. 本文将介绍敏捷软件开发的历史背景与发展,

10.2: 现代软件工程这门课已经上了好几年了,以前有很多学生做过团队项目(说不定包括本校的学生),请你们找一个以前的团队采访一下-------------答题者:徐潇瑞

10.2: 现代软件工程这门课已经上了好几年了,以前有很多学生做过团队项目(说不定包括本校的学生),请你们找一个以前的团队采访一下 - 当时的项目有多少用户,给用户多少价值? 现在还有人用吗? - 这个项目能否给我们团队继续开发,源代码/文档还有么? - 项目开发有什么经验和教训 - 对学好软件工程有什么建议 写成一个博客   #团队博客作业2 根据老师的作业要求,我们采访了以前本科认识的一个同学,他在读本科的时候出去实习,参与了一些项目.他参与了手机外卖app的开发,根据他的回答,当时用户有1

软件工程学期总结

软件工程. 我觉得软件工程的知识其实就是一个软件开发的方法论,给你一套前人总结出来的经验教训,让你少走弯路.做一件项目之前来个“可行性分析”(包括目的.要求和自己能力的估算) 这可能是我做事情之前缺少的一个步骤,然后到最后连自己要做什么都忘记了.这是做事的前提:先看事情是否应该做,是否值得去做,能否做成功.最后再去努力实现. 一个学期的软件工程,涉足java,web前后端和安卓...一个学期下来就一个感受:TM忙的屁滚尿流的.

《软件工程》课程总结

随着时间的推移,学期进入了尾声,我们的软件工程课也将告一段落.下面是我对这学期进行的总结: 通过这16周的学习,我收获了很多,学习上的漏洞.同学之间的沟通及配合.自己处理事情的能力和开发程序的宝贵经验.在上课期间,老师说过我们的软件工程课上所讲的东西和毕业设计有关,例如:可能性分析和需求分析.就拿需求分析来说,在一个程序的开发初期所要做的就是深入的了解分析形成需求分析.通过用户调研了解用户需求,明确用户想要用这个程序干什么,适用于什么人群去使用,之后再通过需求分析框架能明确程序的设计目的,只有通