软件工程在工作中到底起多大作用?

软件工程在工作中到底起多大作用?

  本人今年6月cs毕业,年后面了三家公司,A上市公司,B小公司,C比B大点。 面B时,面试官竟问我MVC还可以和三层一起用?C公司让直接上班,所以有幸看…

  不讲软件工程的项目,就像上面的图一样。 团队成员搬砖很努力,楼的高度也有,但是你敢住么? 它有上下水么? 你在顶楼入厕,一冲水,会不会把整个楼给冲没了?

  那么,为何有些不讲软件工程的公司也似乎混得风生水起呢? 你把上面这个楼房放到一千年前,也是方圆几百里的一朵奇芭,也能拿几轮风投的。 软件行业的一些局部领域和建筑业相比, 就是建筑业几千年前的水平, 大家刚刚从洞穴里面爬出来,看到一个广阔而变化快速的市场,也不知道寒冬什么时候到来,那就各显神通了,赶紧活下来再说! 众多竞争者只能在 {快,好, 便宜} 这三者中选一到两个优化。

  在面试的时候,看不了源代码,怎么了解对方公司的软件工程水平呢? 可以问他们这10个问题:现代软件工程讲义 源代码管理问完之后,可以给他们的CTO,项目领导人打个分。

  前几天上软件工程课程,软工所的大Boss也谈到了这个问题,为什么现在这么多互联网公司的开发模式不按照软件工程来?“其中根本原因还是

  ,你们本科时候软件工程的课多无聊,也就是背背书考考试,做其他课程的大作业时候你们根本想不起来用软件工程的方法,大作业?在ddl前熬几个夜做完的,谁还写注释啊,更别说文档了。”大量这样的毕业生到了工作单位,软件工程的思想早看不上了……

  他是90年代的大学生,电子专业,本科毕设好像是做一个测试芯片结构的程序。那个年代,都是那种体积巨大的那种机器。他和一个师兄都做这个题目,但是各自方法不同。他用软件工程的方法,头两个月先花流程图,写文档,给他导师急得……最后花两个星期写代码,最后一次编译通过,没有任何bug。在验收的时候,发现结果不对,直接就敢判断是某两根线接反了……果然是这样!

  他师兄呢,则是直接写代码,一个月写完,两个月调试,最终效果还是一样的,不过这位仁兄就痛苦的多。

  大叔级 OO 程序猿、软件架构狮,特级资深 Agile 2 敏捷开发教练

  题主的这一问很好,真的,问到了根子上。软件工程在实际工作中到底有没有用?如果没什么用,我们为什么要学呢?

  This is a fundamental question,值得仔细掰一掰。

  软件工程对不同的市场、不同的企业起到的作用与效果不同,所以要看你去的是哪一类企业。

  对于世界一流的软件企业,软件科学、软件工程的作用非常大,因为这些企业普遍具有崇尚科学、工程的价值观和企业文化,逻辑是这样的:没有内部成熟的软件工程管理,他们不可能超越几乎所有对手,研发出如此复杂、如此精妙的世界一流、领先的技术和产品。

  软件工程对于一流顶尖企业有多重要?这里我仅举一例。你们知道在 Apple 负责软件研发的大 V 是谁吗?就是这位:

  senior vice presidentofSoftware Engineering

  . Federighi oversees the development ofiOSOS Xand Apples common operating system engineering teams. His teams are responsible for

  delivering the software at the heart of Apples products

  , including theuser interfaceapplicationsandframeworks.

  Federighi 先生是 Apple 的软件工程 SVP,作为核心人物领导 iOS、OS X 的研发以及 Apple 的公共操作系统工程团队,并直接向 Tim Cook 汇报,可谓一人之下、万人之上。

  ,我在国内很少听说这样的头衔,CxO 倒是一大堆。这件小事例说明了什么?Apple 为什么要这样命名呢?

  这说明了软件工程对于苹果公司的极端重要性,软件工程在苹果所有产品研发中的显赫地位与关键作用,这无疑是一家崇尚科学与工程、充斥着工程师文化的企业。

  对于二三流企业(例如国内的江湖),尤其二流乙等以下的,软件工程不重要,也完全不是决定性的主要因素,而是次要因素。道理是这样的:

  企业的第一要务当然是赚钱,这是企业生存的根本。然而赚钱,赚大钱,真的要靠很好、很成熟、很先进的管理与技术吗?非也。

  在不成熟的市场经济中,大搞关系,善用潜规则和漏洞,善趟灰色地带,精通各种猫腻和作弊手法,强化各种忽悠、炒作、洗脑式营销,这些才是更为重要、不能忽视的、“敏捷”的赚钱术(而且合法),赚钱效应远比靠提升企业自身的软件工程管理与技术水平来得更为直接和有效。前者,能迅速为企业带来短期可观的赢利,属于收入项;而后者,纯粹是企业内部需要在一段较长时期内大力投入的开销,属于成本项;哪个更划算?不言自明。

  在中国流行了也快 20-30 年了吧。先进的软件工程对于国内多数企业来说,可能用处不大,这是由经济规律以及软件人(尤其老板、管理者)的观念、意识决定的。

  在中国,这种开发模式人称“糙快猛”方法,虽然它与教科书上所讲的一板一眼的正规软件工程方法大相径庭,看上去有点乱糟糟的,到处不合理、有漏洞,但确实简单、有效啊,还能赚很多钱(只要不捅大篓子)。

  在学校里想的工作后的项目都是先需求分析文档总体设计等等流程走下来,各种抽象各种解耦,然而事实不是这样的。

  学校里教的软件工程内容来自哪里?主要还是来自美帝,来自美国的产业界、学术界的研究成果和成熟经验。可是不要忘了,虽然都是江湖,但美帝的江湖与中国人的江湖是大不同的。美国人的许多做法、规则和规律在中国是行不通的,包括软件工程的那些所谓最佳实践。

  我个人估计,我国的民用软件工程水平大概至少还比美国落后 8-10 年以上的时间(我说的是平均水平)。当然,像 BAT、HZ 之类的一流企业中的核心产品研发部门,软件工程的管理与技术还是相当领先的,可以说世界一流,你在那里可以看到完全不同的状况,这是事实的另一部分。

  看了代码,简直没有规范可言,没有文档,耦合很大,业务逻辑到处有,命名各种首字母,要靠猜的,数据库字段也一样,没有文档,猜字段。

  近两天有新功能要做,想着以前就算了,新功能总该有个文档吧,我们我们头技术还是很高的,然而什么都没有,给几个模块,让我做,然而原型图和数据库里的字段都对不上,问过之后,原来数据库完全建错了。

  如果是普遍现象,这类企业连 CMM 2 级也没有,属于 CMM 1 级(最烂级)吧,自然更谈不上什么软件开发过程了。A 是上市企业大公司,估计 CMMI 3 级早过了,可 A 股里面的烂公司还少么?

  话说回来了,只要企业、部门还能持续赢利,人员基本稳定,内部研发管理差点、软件工程落后点问题不大。许多这样的二流企业撑个 10-20 年没问题,作为码农能进入上市企业、大公司也不容易,好好待着吧。

  能在细分行业前三的企业做tech leader的人,你说他完全不知道软工为何物,那是不可能的。

  软件工程试图解决的问题,所有参与工业规模软件开发的开发者都会遇到。你管理的代码越多,功能越复杂,需求越不稳定,这些问题就越尖锐。

  一个tech leader,哪怕他不是SE科班出身,也会在工作中使用各种软件工程方法,一些方法可能来自于自身的总结,一方面来自于对网上书上的最佳实践的学习。即使他满嘴对软件工程的不屑,最终他还是会或多或少地用软件工程的方法去解决问题。

  如果你系统学习过软件工程,那么你就会发现软件工程解决问题的手段只有一种:我们姑且称之为“物化开发者”。

  通过复用最佳实践经验,来把开发者变成生产线,实现大规模软件开发的并行作业。

  就像雷老板造手机一样,高通的CPU,天马的屏,他们自家的广告UI,是由不同的人在不同的地方,同时生产的。

  。这,并不如你们想象的那么容易。特别是在这个互联网大爆发,各家都在扩张需求的时期。

  打个比方,你去拿5000块招聘熟悉设计模式和软工过程的开发者,那是不可能招到的,绝对不可能,除非你能给足够吸引力的其他利益,否则连我这样的都不会鸟你。

  但是很多公司迫于成本的压力,不得不招募一些廉价的劳动力来填格子,你给人家的那点钱,也只够做这点事不是?

  所以很多CTO加一帮格子工格局的公司,最初的代码都精炼而优雅,越往后越是一团糟。那是因为最早的代码,framework和core functions是CTO(们)写的,那就是他们那个水平的开发者的正常发挥,后面的功能都是格子工依葫芦画瓢附会上去的,所以各种坑也是正常发挥。

  什么是软件工程? wiki之Software engineering, 然后再看一下什么是Engineering.

  所以说, 如果你说软件工程是你大学或者蓝翔教的课, 确实不重要, 而如果你认同wiki定义的enginnering以及software engineering, 那肯定是重要的. 就好比年轻人经常问的, 算法在工作中有啥重要的?当然重要了! 这些都是所谓的principle以及building block. 你必须要有一个工具箱, 里面有锤子, 钉子, 夹子等等, 你干活的时候更要知道拿什么工具处理什么事情.

  通俗的例子: 弹吉他, 如果你是一个好的吉他手, 你可以不用弹200, 可是你要有弹200的能力.

  冒着要被@曹政急的事实, 以及以后在新加坡也不能蹭上饭的风险, 我还是理智的写下了一些东西.

  , indeed, 不需要做到老板我们也需要知道, work is everything, till shit happens.

  3) 甚至日常生活也不需要架构, till shit happens.

  第一次第二次shit来了, 没事, 每个人都是这么成长了, 不过以后你每次写个东西, shit 随时happens, 怎么办?

   确实, 谁跟我说架构, 我也跟谁急, 我只认同show me the code, benchmark一下, 我面试过超过200人, 见过不少人在简历上写重写架构之类的, 我就一个问题, 多少improvement? 答不上的请出门右拐直接gg.

  最后, talk is cheap, code is also cheap. 我们建立一个团队, 建立一个公司, 公司发展当然是首要的, 但是也不能忽略团队的建设, 水桶原则 vs 人往高处走.

  再最后, 软件工程其实简单来说就是proper engineering, 不要over engineering也不要under engineering, 当有个人跟你说software engineering不重要的时候, 你真的要清楚了.

  按照我的经验, 衡量proper engineering的方法挺简单的, 每天听到WTF的次数心里就有数了.

  真的最后了, 如果你是一个软件工程师, 其实我只是单纯的希望, 你每过一年, 都能对自己负责而已.

  根据我的工作经历,我觉得软件开发产业的管理瓶颈不在于开发流程(当然开发流程确实能减少开发过程的很多问题),而是最基本的业务流程和成员激励的问题。一个没有什么流程的团队可以做出很棒的软件,一个流程严格的团队也可以一无所成。

  软件行业在我看来最大的管理弊病在于,很多时候是外行管理内行,一群对技术模模糊糊知道一些的管理层来管理具体做事的员工。对于走技术路线升上去的经理,情况稍好,然而期待他能懂组里所有人做的事,也比较难。

  外行管理内行的最大害处,在于不能以产出来衡量业绩。比如,一个BUG,也许很难但是我一天就改好了,可能还不如一个不那么难但是让人觉得工作态度端正的人花几天改好的人评价好。

  5,训练好PPT技能,经常做 knowledge share,英文 presentation 能力强。

  为什么要这样,是因为这些东西领导看得见并且易于评价。真正的业务部分,是难以评价的。比如,你花几个月时间改一个BUG而不向经理强调它有多么难解决,也许经理不会认为它难而是认为你蠢。

  更进一步问,为什么公司不强调业务能力还能活的好好的?因为软件开发和维护过程中,真正的难题不会超过其中的 10%,大部分人从事的工作都是区分不了业绩的,至少是很难区分业务水平的。认为软件行业是智力密集型行业的说法正确,然而认为软件行业智力越高会混得越好,则是错误的。

  做了半年的PM和PM,大概能认知到,计算机系统的建设,有一根金线在那放着,这根金线就是软件工程的要求。所有的文档,架构设计,敏捷方法论,都是为了达成这根金线而努力。

  而软件工程的受重视程度,跟技术负债的偿还成本是成正比的。如果你的产品(软件)生命周期很短,很多负债来不及还系统就不会再用了,那自然不会在乎这个偿还成本。互联网公司试错型的发展逻辑,和一些非核心的业务功能,显然就属于这种情况。损失20%的质量节约80%的时间这种事,大家喜闻乐见。

  但是百度的搜索排序,网易云音乐的播放数据流这种核心功能,大家还是会妥妥进行完整的测试,充分的设计,留下足够文档的(搞不好还要发论文)。

  作为一个新手(不到半年)“Tech Lead”,我觉得我可以试试回答这个问题。

  重要的事先说三遍:执行好的软件工程实践,需要花费大量的时间和金钱!重要的事先说三遍:执行好的软件工程实践,需要花费大量的时间和金钱!重要的事先说三遍:执行好的软件工程实践,需要花费大量的时间和金钱!

  项目就是一个很复杂的事,涉及到: 时间,成本,周期,技术栈等等。我们是乙方,所以我们从不考虑成本的原因。然后先说说我们在软件工程方面的实践,我不敢说是国内最好的,但我相信至少是数一数二的。我们采用的是敏捷的工作流程,不过我相信那些对于尝试过敏捷的人来说可能会有些反感。

  测试(TDD)与测试覆盖率。大部分公司的代码都是没有测试覆盖的,即使是BAT也是一样的。如果我们花一天写功能代码,那么至少还要有半天的时间要写测试。

  持续集成。你要经常提交你的代码,还要有测试,还要和别人的代码集成——而且是一天多次。

  进行Code Review。每天大概会有三十分钟到一小时的Code Review时间,而且是集体Review今天的代码。

  技术债。在我们的上个项目中,由于是新的开发框架。在后期,我们发现我们积累了一些技术债——主要是代码质量问题。然后,我们一周抽时间来一起重构代码。

  每周两次的技术Session。技术Session的主要目的是提高团队成员的技术水平。

  我就不对上面的优点展开了。现在,让我们来算一下我们需要多付出多小的成本。

  假设,我们现在有四个人,每个人独立工作,可以在一周内完成。即一个人需要 8*5 小时的工作时间。

  这就意味着,我们可能要四周才能完成这个项目!!对于一个短期的项目来说,这简直是不可接受的。

  这就意味着,我们可能要四周才能完成这个项目!!对于一个短期的项目来说,这简直是不可接受的。

  这就意味着,我们可能要四周才能完成这个项目!!对于一个短期的项目来说,这简直是不可接受的。

  采用敏捷就意味着,生产力是固定的、代码质量较高、技术平均水平较高!采用敏捷就意味着,生产力是固定的、代码质量较高、技术平均水平较高!采用敏捷就意味着,生产力是固定的、代码质量较高、技术平均水平较高!

  因为采用结对编程,所以每个人对整个项目的代码都很熟悉。这就意味着,不用担心有人离职要影响项目的稳定性。当有一个人离职时,整个项目的产出率也不会因此而变化。并且新人会因为采用结对编程而上手更快。因此只要不是一起离职,即使一年后,这个项目的人都已经换了一遍,项目仍然可以继续下去。

  同样的有Code Review、测试和结对编程的存在,组内的代码质量会达到相当高的水平。虽然这在早期可能意义不大,但是请注意一点:Bug在越后期的修复成本越大。

  复杂度超过上限就会出现项目雪崩现象,即bug修不完且互相影响,同时新功能扩展困难。

  题主是学软件工程的,但对软件工程的真正理解还需要好好打磨几年,现在你理解的“软件工程”其实并非软件工程。

  什么是软件工程呢?软件工程是写软件的方法。我们写一个编辑器,做界面,做正则表达式解释,做用户界面优化,这些“写软件”,如何安排模块之间关系,选择什么接口和协议,选择什么部件,这叫“软件构架”,但谁来写什么软件,进度间如何配合,如何进行质量保证,如何安排软件生命周期,这是“软件工程”。

  软件工程并非CMM,并非需求分析,并非width-band delphi方法,更不是编程规范,文档写作或者流程规范。

  软件工程是最优的组织软件开发的的方法——即使只有一个人开发软件的时候。

  所以不管你在学校学了什么,请首先搞明白企业中真正导致这个企业活下去的原因是什么。你在学校里学的是理论,是面面俱到的理论,但理论不是用来实用的,实用的东西是基于这些理论进行的力量分布,真正的经验也是知道在特定的行业中,什么实践才是为其生存提供最大贡献的要素。这才是软件工程的本质,软件工程的本质就是对资源和力量的调整能力。

  2000年左右的时候,印度ODC公司和我们谈合同,还在关心CMM,现在和我们谈合同,CMM一字不谈,只谈成功经验,以及长期合作的筹码,你可以掂量掂量这其中的差别。

  所以,我建议题主谦虚点,先清空自己,写好自己的程序,实践自己的方法,欣赏自己所在的公司如何生存,这对谁都有利。

  工程,任何时候都是取舍的问题,永远没有绝对的标准化,只是不断地博弈,和人,和环境。

  软件工程亦是如此。书上说的东西,考试的东西,大多都是一些基本原则或者参考样例,并不是标准答案。

  一个大型软件项目不是一天构成的,一个公司完整的工程流程也是如此。公司需要根据自己实际的资金能力,员工的技术水平技术背景做取舍。举个例子,敏捷推崇结对编程,可是对于仅有几名程序员却工作量巨大的公司来说,结对编程只会让公司死得很难看。

  理想和现实总有不同,如果你能思考一下一家公司工程制度为什么这个样子,以后你除了做好自己的事情以外还能如何推动它改善,那会给你带来很多收获。

  工程是管理过程的 是管理模式的复制使用 模式是不断反复沉淀为了复用抽象提炼的

  所以我们看到工程 模式都是以复用为前提 如果我们做的项目 没有复用的前提 传统软件工程的美好就会大打折扣 同时业务总是第一位的(即使再强调软件工程 也总会让步业务) 商业目标往往压倒一切 当项目不是为了复用(例如苹果的产品、微软的office等大规模复制的软件产品)那软件工程的目标降低为质量高 维护成本低 blahblah 所以需要大范围的剪裁 否则模式过重 会严重制约业务目标达成(有限成本作出符合商业需求的项目)

  例如敏捷模式就是抓住精髓 在某些场景下的大范围剪裁 看看敏捷宣言 表明的就挺到位

  因此在现在这个各行各业皆需要软件 互联网 云计算 工业4.0在强调软件核心地位的“动荡”年代 不是追求复古的 传统的 完整的软件工程的好年代 很像孔老夫子哀叹 没有礼 国不存 但是事实证明完整的周礼不存在了 但是国家还是会继续存在与发展 有了法律 道德 潜规则等规范和制约

  因此不是说不需要软件工程了 而是现在软件工程面对软件需求爆炸的年代跟不上节奏了 当然纵观近30年历史 软件工程一直处在跟不上节奏的状态 呵呵

  最后用一句总结就是 无之以为用 有之以为利 共勉 破除执障 祝你早日进入到不困惑有方法的境界

  软件构建是需要方法的。比如说 scrum, refactor 都是一些提高软件质量的概念。但是「软件工程」是一个有很大误导性的概念。因为软件和传统的工程有很大不同。

  时间跨度不同,单位时间跨度里构建出来的复杂度也不同。拿航空发动机来比较,航空发动机确实非常复杂,但是以航空发动机积累的时间来看,在单位时间里航空发动机复杂度的增长没有一个软件系统快。

  类似的,单位投资对应的复杂度也不同。传统工程一般是投资封顶。就算工程师能想到一些复杂的点子,投资者也不会让他开始去做。就是说不管能不能做出来,连启动资金都没有。而软件系统是复杂度封顶。只要程序员能想到,不管最后是不是预算超支或者延期,总有启动资金支持你去做。

  软件工程适合搞软件。互联网不算软件,按传统软件的流程去搞,别人黄瓜都吃了,你才播种子。传统软件可能按月甚至是年计算工期,而互联网是按天或周计算工期,按月计算工期的项目很难活下来。项目设计文档?对不起,有数据库字段说明文档就谢天谢地了。

点击这里复制本文地址 免责声明:本站内容由程序自动采集于互联网,无人工干预,只作交流和学习使用,本站不储存任何资源内容,如有侵权请联系qq邮箱798244092@qq.com立刻删除,谢谢!

支持Ctrl+Enter提交

电气工程及其自动化专业大学排名 © All Rights Reserved.  
Powered by 多多资源网 Themes by 多多资源网
联系我们| 关于我们| 留言建议| 网站管理