关于工程化的个人理解

• 工程与科学
  • 工程和科学面对的问题
  • 工程师和科学家在思路上的差异
  • 工程师和科学家所需要解决的问题方式上的差异
• 工程化的问题的由来. -> 软件危机的前端表现
• 工程化要解决的问题. ->
  • 从面向过程编程-到面向对象编程的软件工程思想说起.
  • 可维护问题(面向过程的编程是 OK 的,但强依赖于人. 如果人(大牛)离开,怎么让出了问题的时候问题可维护.)
  • 前端工程化 问题的由来,涉及的方面(好吧,其实是方方面面)
  • DRY(Don’t Repeat Yourself)

工程与科学

工程化是一个很泛化的命题,我们先从工程说起吧. 单方面说工程也是一个很难下口的问题.我们把工程与科学对比一下就清楚了.我们从工程师和科学家的视角对比一下各自的思考方式,问题就明确了.

很早以前在知乎看到过一个问题,对于工程和科学里面有很多精彩的回答:

https://www.zhihu.com/question/20402148

摘抄几个精彩的回答

Scientists study what it is, while Engineers create what never was.

工程师跟科学家更重要的区别可能是更懂得妥协。

这里的妥协并非是贬义词，而是一种真实的状态。科学需要有一往无前、尽善尽美的精神，需要执着甚至于偏执才可以成功。而工程中需要考虑各个方面的因素，不论是成本，还是最后需要达到要求的各项参数，最后的结果也许每个参数都不优秀，但是方方面面都可以满足，就是好的结果。这不是得过且过，而是纵观全局之后的取舍。

.作者：陈章鱼

链接：https://www.zhihu.com/question/20402148/answer/15028338

来源：知乎著作权归作者所有，转载请联系作者获得授权。

工程师说，世界应该是被改造的
科学家说，世界应该是被认识的

工程师说，世界应该是和谐的
科学家说，世界应该是多彩的

工程师说，世界应该是幸福的
科学家说，世界应该是真实的

工程师说，世界应该是人类的
科学家说，人类应该是世界的

工程师说，我想成为这个世界的上帝
科学家说，我想了解这个世界的上帝

工程师说，我只相信统计
科学家说，我还相信奇迹

作者：苏芸

链接：https://www.zhihu.com/question/20402148/answer/15042350

来源：知乎著作权归作者所有，转载请联系作者获得授权。

工程师的思维方式更接近于what—>how，科学家的思维方式更接近于what—>why

科学家是一种观察，发现的角度；
工程师是一种构建，创造的角度。

工程师解决的是具体问题，科学家研究的是抽象问题。
工程师往往是问题驱动型的，先由问题再想办法解决，科学家往往是主动构造问题，也就是所谓大胆假设，小心求证。但也不完全，工程师，比如软件工程师在解BUG的时候也会先假设再求证
现代社会分工明确，两者的工作内容不同层次不同，导致思维习惯不同。以前的年代，比如瓦特，特斯拉，他们是科学家还是工程师？

作者：Kelvin Li

链接：https://www.zhihu.com/question/20402148/answer/16779545

来源：知乎著作权归作者所有，转载请联系作者获得授权。

科学家: 他们遇到的问题是开放的，他们做事情的目标通常也是模糊不量化的. 工作方式和思维方式也是发散

工程师: 他们遇到的问题是封闭的，做事情的目标一般也是清晰量化的。 通常工程师的工作方式和思维方式是收敛的，他们会在上述大树里面砍掉各个分支，找到一个够用的叶子（@陈章鱼说的妥协）

回到我们的工程本身,工程中的问题是具体的 , 明确的. 工程师需要解决的问题也是实在的. 工程师的出发点是how. 怎么解决问题. 在技术没有质变之前,问题在这儿摆着的情况下,如何解决问题. 这里面或许还会有很多折中,妥协的地方. 但目标是明确的完成了解决问题 的目的. 另外就是成本问题, 时间成本,人力成本.这些是有限的.举两个具体的例子吧

第一个例子 工程化和科学家是思考模式有点像 机器学习和数据挖掘 .
机器学习:是通过大样本训练,然后对一个特定目标进行匹配判断. 也就是说, 机器学习的目标和结果指向是明确的. 我通过对一百万个苹果样本进行分析处理(自学习),当下一个图片需要我来识别的时候我能够给出一个是或否的答案.

数据挖掘: 我通过对大量的数据进行分析统计,建模, 但是我不确定我能分析出什么内容.我的不确定我能收获什么样的结果.

第二个例子, CMD ,AMD, CommonJS 规范 和 ES6的 export moudle

CMD/AMD/CommonJS 诞生和存在的原因是在当时 ES5环境下,我们缺少(浏览器端和服务器端都是如此)对应于模块机制,但是我们又实在很需要模块机制. 所以我们在现有的条件下 (ES5 ), 实现了CMD /AMD/CommonJS 这种机制,这是一种妥协,因为我们只有这样的当前环境. 这个机制为我们解决了那个时候的问题. 我们可以更好的管理我们的代码了,我们的模块可以书写的更加清晰也更加好扩展和维护了.个人感觉 AMD/CMD/CommonJS 是工程化的一个经典实例. (按照相同思路的babel 也算).但是这就 OK 了吗? 额,没有.我们知道,我们 require 的时候,有可能会导致 循环加载 的问题. 这是很难避免的，尤其是依赖关系复杂的大项目，很容易出现a依赖b，b依赖c，c又依赖a这样的情况。这意味着，模块加载机制必须考虑“循环加载”的情况。

再看 ES6 .为什么我觉得 ES6 的 export / import 的 moudle 机制算是科学呢?

我们知道我们在 通过 require 关键字引入新的模块是整体作为一个实例对象被引入到当前环境的,加载完成开始执行. 而如果引入的对象恰巧与别的模块之间形成了加载回路 , 这就会造成循环加载的问题. 问题出在了引入机制上.(这里问题有额外的方式来克服,此处不议.) CommonJS输入的是被输出值的拷贝，不是引用.

而 ES6模块是动态引用，使用 import从一个模块中加载变量,那些变量并不会被缓存,而是成为一个被加载对象的引用. 这种逻辑设计很好的避免了循环引用的问题.且export 的粒度 更加细化. 这是一个对 ES5 AMD /CMD/CommonJS 质变的地方.

这个例子中工程师的解决方案,和科学家的解决方案的差异. 同样有问题导向,工程师 how & make a solution, 科学家 create a new way

工程的主要目的是解决问题.浪漫一点的表述是让世界变得更美好. 而这个过程是中需要考虑诸多方面,我想到一点说一点

• 现实因素的限制 | 在没有质变条件下面对问题的一种折中
• 成本(包括人力成本,时间成本) -> 从这个方面思考,我们需要考虑效率问题, 以及自动化
• 工程,当引入新的机制或约束时, 对于产生的新的问题的解决.
• 实用. 需要考虑问题解决,并且稳定实用.

loading….

很久很久以前,小时候,老师问你将来想成为什么, 小孩儿们在底下大声说科学家. 这辈子这个目标渐渐地渐行渐远,努力成为一个工程师吧,起码要具备工程师的思维.

By wanglinzhizhi