软件工程是否可以提高代码质量？

软件工程从来不是天才们被束缚的借口

软件工程只是我们这些“ idiotic ”工程师的护身符。

当然，yinwang 是有点夸大了一点

一般批别人这样的，也是一路货色！
一切上规模的项目都需要科学的组织规划，所谓方法论是有必要的。

如果软件工程方法不能，那么，什么能？

软件工程很神奇，一方面是计算机科学与技术专业的一门专业必修课，一方面又是一个(二级学科？)专业，连教育部也弄不清他的定位

软件工程方法能制造出高质量低成本的软件还不够?

@zqx 数学也很神奇，物理也很神奇，化学也很神奇……

牛逼的程序员 without 软件工程 > 傻逼的程序员 with 软件工程 > 傻逼的程序员。
软件工程有用，但也并非神器。

只是网瘾同学从不考虑成本。

……你可以对照现代医学对疾病的治愈率来理解。

https://www.zhihu.com/question/268523561/answer/338633735
我觉得软件工程的方法是面对任何一个巨型项目的唯一办法

呵呵，牛逼程序员 搞搞一个完整的系统？ 吹出狗了

看来 AT&T IBM miscrosoft sun Google Facebook amazon 都没花钱请牛人，基本软件工程最牛逼实践，最前沿的就是按顺序来的几家了。

软件工程和代码质量关系不大吧，
软件工程是解决软件复杂度的问题

代码质量你得看重构，代码整洁之道，设计模式之类。

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


大致看了这段，就知道这是很简单的问题，
他把自己比作手艺人，传统的小作坊模式，
但是实际上现在大工厂的管理方式可能去用小作坊的生产模式吗。

富士康和街边手艺人有什么可比的。
可能我看的比较快，看错了

软件工程是一个工程问题，解决的是软件开发的过程管理，研究如何有序地可预估地开发大规模的软件。代码风格的统一和优化只是其中最简单的部分之一。

软件工程只能保证你能在规定的时间内编写完成可用的代码。至于代码是好是坏，它才不管。

看过《人月神话》就知道，软件工程不是银弹，天才们也的确不需要软件工程也能开发出好软件。不过大型的系统用 20 号天才开发要 20 年，用 20 个天才，加 1980 个庸才则可以在 5 年完成一个可用的系统，你叫老板选哪一种？软件工程只是为了控制项目复杂度而提出的方法论。你要让软件工程帮你将软件变得像数学公式一样正确有效，对不起，它做不到。

软件工程差不多就是码农流水线了，当然好处在于传统行业流水线改进成本巨大，软件行业流水线可以迅速迭代。
王垠看不起测试用例看不起软件工程自然有他自己的理由，普通人还是老老实实把测试用例写好吧。我自己开发的业务过段时间再看，细节逻辑很多记不清了。说白了我也只是个凡人罢

菜鸡的眼光

一个人写个小项目也叫工程？什么叫做工程，几百人上千人上万人写个项目才叫工程。

要是全信王垠的话，
那这个世界上除了他自己的 就没有不垃圾的东西，

但是王垠自己也没做出什么东西来

现在的人比较浮躁，讲究技术的实用性。

中国软件行业起步比欧美晚，认知也比较落后。

经常有人问，程序员到 35 岁，是不是要转管理层？

你看欧美技术大神，五六十岁的都有在搞技术的。如果没有对这个行业的热爱，只能在这个道路上越来越平庸。

理论任何时候都不会过时，等你融会贯通了，你就是大神级别的人物。

话说你们不觉得软件工程 更适合产品经理 项目经理们看看么。

大致扫了一遍...这篇文章没什么营养....就是典型的自己立个靶子自己打..
一番批判却没有提什么解决方案....有种自嗨的意味....没什么建设性..
我觉得这一块..概括为
对于软件工程，尽信书，不如无书..
足够了

本来想写一些软件工程方面的东西，从而说一说它的特点与优势，不过点进来看到你引用的时王淫大神的言论，我决定来说点别的。

相比于搜索此人的言论，不如去搜一下此人的经历，看完之后你会发现，全世界范围内筛选人才的方式，目前仅止于看你的学校出身，也就是看分数，分数高就是高端人才，面对众多的学子，要批量的筛选符合自己培养条件的人才，这也是目前没有办法的办法。但把某一个人拿出来单独评审一下他的方方面面，就可以较全面的评价之。

群众的眼睛是雪亮的，所以那些靠自己记忆力强，会考试，懂得如何拿高分上名校的人，就算你毕了业，有知名导师推荐，可以去国外留学，最后也只能灰溜溜的被赶出来，该上那去上那去。这样的人也就只能写一些神仙打架的事情糊弄一下不明事理的小白，本来可以成才的小白被忽悠之后很容易就飘起来了，受到这些不良影响，从而自己的职业规划道路也被毁了。所以提醒一下想要提升自己能力的各位，网络时代，提高技术能力的同时，也要提高分辨是非的能力，这年头，什么鸟兽鬼怪借着网络都能成神，要小心时刻提防，谨防上当。

计算机行业毕竟太年轻了，软件工程积累的经验不足

通篇看下来没有论据啊，只是在提他的观点，也没有具体的说法，这让人怎么信服

工业界需要

@zqx #4 一级学科

软件工程科班出身，它是一门工程学，私以为软工的目的在于*把个性化十足的程序员变成流水线上的装配工*，从而减少替换所带来的一系列问题。同时它组织了整个项目的开发流程，主要目的在于在给定的时间内按照质量完成任务。

与其说它提高了代码质量，不如说它更加关注性价比。软件工程扯淡的地方在于，它的需求期很长，自以为能够在一开始就把所有的需求确定下来，但是这是不可能的，也不符合当前互联网企业的开发风格。

当然了，开发流针对这些问题也做了一些改进，如迭代之类，但是对于现在的敏（快）捷（速）开发，仍然不那么有用。

说软工完全是扯淡的人才是在扯淡。

“可是你最后发现，无论你如何高效的使用这些工具，它们都只能起到辅助的，次要的作用。编程工具永远不是程序本身，对编程工具的熟练掌握，永远也无法代替真正的对程序和计算的理解。过分强调这些工具的使用，是本末倒置的，让工程走上失败道路的作法。”

看了这一句，就知道这是个用“嘴”编程的主。真正做工程时候时候，需要的是熟练掌握工具的，还是会 BB 的？

sense 和熟练编程工具为什么就冲突了？我觉得他们相辅相成。光说不练假把式，光练不说真把式，连说带练全把式。

终究把“腐朽”的软件工程捡起来了？前几年互联网不是号称要抛弃一切“老旧臃肿”的技术么~

看楼上一些人都是在说王垠是在嘴，但也没见谁拿出什么实质性反驳的论据来证伪，比如自己公司用了 xxxx 软件开发流程，提升了几倍的开发效率。

在大学听老师授课的时候，我就产生过类似的疑问，软件过程的作用是什么。参加工作之后，那些软件工程方法论给我的感觉就是可能有用，但并没有鼓吹的那么有用。以听到最多的敏捷开发为例，很多公司其实都是为了所谓的敏捷而敏捷，或者是简化了其中的许多流程。更不用提需要花大成本去实现的 CMMI。

再比如测试方法论里的 TDD 和 BDD，我曾尝试在大团队里推广 BDD(领导要求)，可能我司人员学艺不精，也可能我理解不到位，很多同事都产生了排斥的想法，最后也作罢。

很多软件工程方法论(我是指大部分)，给我的感觉就是繁复，偏于形式，所以我其实是同意王垠文章中的部分观点。如果花上大成本去维护一套软件工程流程，我觉得性价比完全不如把精力和时间投入到代码质量与需求评审上。

@lurenw 写的很好
1 是培养代码质量，如果团队里面的大部分人关注代码质量的话，他们也会关注工程问题
2 是需求分析和评审
3 code review
4 一些简单的，良好的辅助工具
5 一些必要的流程还是需要

抛开书本，软件工程是解决多人如何协作开发软件，更多的是管理。

当然可以提升代码质量
但工程的执行者始终是人
人自己就是不稳定因素

这玩意的效果是节省时间。去改一改 3 个月前写的代码体验一下就明白了（雾

我觉得软件工程既然是工程的一种，那么和土木工程类似，必然包括立项、勘察、规划、设计、施工、维护（迭代更新）等一系列步骤。在小的项目中它可能不是那么重要，但是在超级工程中没有系统性结构性的理论支持最后很可能会吃大亏。比如在老家盖个平房，请几位有经验的师傅把要求描述一下就差不多了，但是超级工程比如港珠澳大桥之类的肯定要严格按照工程理论的要求按部就班地做，这样能够尽可能消除不稳定因素。
另外我感觉上软件工程导论和软件设计与体系结构之类的课的时候认真听的人不是太多，很可能是因为现在用不到所以感觉没用。

@whileFalse 比自己牛的是牛逼，比自己垃圾的是傻逼

软件工程不可以提高代码质量，那需要软件工程干嘛
国内的 996，实际上是很多公司，忽视软件工程的建设

关于删除，似乎是这么说的：
https://web.archive.org/web/20180601060604/http://www.yinwang.org/blog-cn/2018/05/28/change
“很多人，不管他们是什么冠冕堂皇的头衔，应该像街头小混混一样被抛在脑后，被忽略，而不是被仔仔细细记录下来，进行深入的批判……停止批判他们，不是妥协，而是彻底的无视……”

对呀。证据呢证据呢。谁主张谁举证。
请大家评论时候带证据。不然就是灌水。

先声明非科班。

我觉得软件工程更偏向方法论的范畴，说白了，就是尝试用规约的形式来管理一个组织进行开发，目的是保证项目在**不崩**的前提下进行有效增长（增长包括但不限于代码行数、功能、性能等）。至于代码质量，我觉得不存在直接的促进作用，只是通过某种手段**强制**限定了代码质量不会崩盘而已。

这种乱抛“语不惊人死不休”论点的人，脑袋都有问题。。

1. Design Pattern 这名字就不对劲，设计模式？听起来就像在说一个导电的绝缘体一样。

2. DRY 并没有作者，来源应该是 Usenet，谁敢自称作者？

3. Agile 和 Scrum 并不是 “软件工程” 的方法，而是 “项目管理” 的方法。
不是工程，是管理，B.Eng. 和 MBA 能一样吗？有谁把 Agile 和 Scrum 放进 “软件工程” 大类里请重新读高中。
举个例子，我拿 Trello （ Scrum 工具）来做大件购物清单（愿望单）。购物清单显然不是 “软件工程”，但大件购物这一动作显然是个项目，符合项目的要素（一次且仅一次，有一个明确的目标，有黄金三角限制）。

4. TDD 和 BDD 我仍然没有明白区别是什么，没见过人说清楚的，只能瞎猜。BDD 更倾向于将测试以 “效用” 划分，比如业务用的、安全用的、管理用的、测试用的（瞎划的）。TDD 更倾向于以 “模块” 划分，比如充值模块、消费模块、抽卡模块、战斗模块（还是瞎划的）。但是那样的话难道不能在每个测试上标明它表达了何种效用，属于哪个模块，甚至更多种类的 metadata。

@halk 忽然想到你这句算不算

我们国家的 IT 环境是只要能写代码的（ CRUD ）。绝大部分人做的工作算不上工程，所以我们叫程序员，不叫工程师，所以培训班能大规模批量输出劳动力

@no1xsyzy 算

程序员和计算机工程师的区别吧

别的不说。“设计模式”个人还是感觉很好用的，我说的是那些不是为了用而用的人。也不是那些一知半解的人。
1.设计模式给了我们能够快速读懂对方代码意图的能力，很多开源项目，源码无从下手，但是这个项目运用大量设计模式，而且你刚好很懂这个，那么你阅读代码所花的经历会大大减少。因为你看到 Adapter，Wapper，Factory 之类的关键字都有一种非常收悉的感觉，自然而然的就知道怎么去读它
2.设计模式的确一定程度上把复杂的大问题分解成若干个局部问题，让思路更加清晰，某些时候也可以解决多个人员分工合作开发

“ Design Pattern ” 作为一个开发 10 年的老程序员，可以负责任的告诉你，绝对不是一个无用的东西。

@chinawrj 哥们留一个邮箱有偿请教无线组播问题