我眼中软件工程里的常识

背景

提及工程人员/团队应该具有的“常识”，真正促使我认真思考这个问题，仍是由于知乎的一篇贴跟没有常识的人聊天是一种怎样的体验？，里面笑料百出，各类因为“常识”不足致使的尴尬癌真真是忍俊不由。但笑过以后我发现，所谓的“没常识”，可能由多种缘由致使，这点在知乎里多位答主都提到过：

1. 信息不对等 － 你们所处环境不一样，对“常识”这样一个相对概念自己囊括的内容就有不一样定义

2. 道德水准低下 － 虽常被归类为“没常识”，但经过仔细甄别是能够分辨出来的

3. 逻辑混乱 － 可见于24种常见的逻辑错误 – 做者：谢至理

抛开第二种暂且不论，就一、3而言，在咱们软件工程中，这些缘由是否可能致使沟通成本提升、工做效率变低呢？下面结合我本身的痛苦经从来谈谈“常识”的故事！若是我下面所述你早已烂熟于胸、甚至还有补充，恭喜你，你为本身所在团队增添了一抹幸运！若是你对里面的部份内容还不清楚，或许那正是你须要的。

操做系统是不一样的

Windows 与 OS X

你们能够看获得，左边是OS X的finder，右边是windows的explorer，不管从UI设计仍是功能设置，他们都有很大的不一样，譬如：一样是小叉叉，但在两个操做系统上功能是有差别的。

iOS 与 Android

盗图，侵删(若有冒犯，先行致歉)

如图，一样是facebook的应用，左边是iOS版；右边是Android版。

有我的喜爱没有问题，但若是生硬的将之带入工做中，并执拗的忽略操做系统间的差别就会影响到工做质量。

我曾不止一次看到有测试人员为OS X应用提了bug － “[OS X]点击关闭按钮应用没有彻底退出”；

又有人为windows应用提bug - "[windows]ctrl + q快捷键不起做用"。

可是大哥，真心的，若是你实在懒得不想去了解两个系统到底有哪些不一样，也最好静下心来听别人说说，至少你得认可操做系统是不一样的。

这个问题上，我认为，做为一个软件工程人员，首先应该理智的认可——操做系统是不一样的。

Web不仅是前端的事儿

跨域问题

近年来由各大巨头公司猛推的先后端分离炒得火热，不过我发现实际操做中一些团队都受困于对跨域问题的理解。举例：因为先后端团队对跨域问题的理解程度不一样，甚至有时候是都不了解，致使当错误发生时，前端找后端要求支持cors，后端反问“那是什么东西，你都说不清，我不能帮你”。搞得最后连post、put、delete等方法都要上jsonp，试图绕过跨域问题，可jsonp毕竟是有局限的，这里咱们不过多深刻，各位能够参考构建public APIs与CORS。

restful

以前合做过一位后端“大神”，他说本身的API设计扩展性超强，是真正健壮的restful接口。因而我请他讲解，其滔滔不绝道，个人接口直接把前端和数据库打通，大家直接传数据库字段和对应值，我一一帮你录入数据库。当我问及，那会不会被人利用黑咱们数据库，致使大量废数据产生，“大神”鄙夷的看我一眼说，你本身都说是废数据了，业务不通，是不会显示在用户界面里的，怕什么！可我想说的是“大神”啊，坏人能够分分钟干爆你的数据库，这么“透传”真的是扩展性好么？

还有一事，对于一个数组字段，没有值的时候究竟是返回null仍是[]又成了一个问题，一位友人和我强调他们后端就是要返回null，理由是"java语言设计了null，那么返回null就是最好的选择"。因而我又默默的去一边呵呵了。

咱们并不是要求每一个人都对restful的各类约定、要求滚瓜烂熟，但网上关于restful接口设计的经典案例、最佳实践，一搜一大把，并且内容都很少，既然都说本身在用restful了，那么看看别人的最佳实践，不过度啊！

URL

盗图，侵删(若有冒犯，先行致歉)

一个URL到底由哪些部分组成，各部分的学名又是什么，我猜你可能已经发现周围有人不知道了。我曾见过两个在讨论subdomain问题的人，然而1个多小时过去了，也没什么结果，吵得不可开交。后来我让他们画下本身说的究竟是URL的哪一个部分，结果发现二人说的所谓subdomain根本不是同一个东西。

既然你们都在互联网圈子混，可以准确指出URL各部分都叫什么名字，专业且沟通成本低，不过度啊！

渲染？

常常看到有朋友问及相似：“AngularJS里有模板，咱们公司用Node作服务端也有模板引擎ejs，两者可否混用，如何混用？”，其实这种问题多见于初入门者，没搞清楚的“前端渲染”和“后端渲染”有什么区别，并且基本能够判定对一个URL从敲在浏览器地址栏起，到页面最终显示出来，都经历了哪些过程并不清楚。因此你可能须要知道当你输入一个网址的时候，实际会发生什么?。而后还须要搞明白“后端渲染”究竟是什么，最后再回想你关于"混用"的问题。

复用

“复用”这个词咱们每天见，就像“大宝”同样(年龄暴露)，但复用都有哪些层次，这个问题就有点意思了，我想了想，大概可能有如下几种吧：

• 拷贝、粘贴 － 这应该是最多见，也是最简单粗暴，容易理解的那种了。你写好，我来拷贝、粘贴到个人项目里，复用达成！

• 运行时复用 - 之前网站开发中常见的模式，一个css文件，全部的页面样式都在里面；一个js文件，全部页面的业务也都在里面。好处是你真的不用关心谁配谁，反正一共就俩文件，坏处也显而易见，当你要优化网站时，可能想要需加载、可能想剔除没必要要的代码、也可能只是想按业务拆分代码，立马让你抓瞎。

• 开发时复用 - 在browserify, webpack, rollup之类打包工具的诞生之后，前端圈子也愈来愈注重这个层次的复用。各类资源均可被定义成“模块”，在开发过程当中按需引入，rollup甚至还具有了tree-shaking这类神同样的优化能力，使其更显逼格。

至于你在项目中须要采起哪一种复用，这就看你本身对复用的认识和项目自己的需求了，但不管如何，复用真的分不一样层次，这点做为软件工程人员你是须要知道的，并且在团队沟通中，最好统一你们的认识，以避免驴唇不对马嘴。

自我驱动

“学而不思则罔，思而不学则殆” － 孔子在2000多年前就讲了学习和思考的关系，咱们活在当下，又怎么能超脱！？

咱们经常在工做中遇到这样那样的问题，有时候人们是这样回答的：“咱们的业务很是特别，对于这个功能，没法支持”。首先我相信世界上有些功能的确作不到，但这种话听多了就会奇怪，你的业务真的就那么“特殊”么？或者说，你遇到的技术问题，就那么“惟一”，网上一点痕迹都找不到？

其实我想说的是:

盗图，侵删(若有冒犯，先行致歉)

但为何你就是找不到问题的答案呢？总结了一下我多年的工做经历，我发现如下几点是形成“无解”假象的主要缘由：

1. 第一名就是不会善用搜索引擎，尤为不会善用google。还记得多年前曾带过一个实习生，他说没办法在servlet里获取请求的query参数，我大惊并质疑其答案的正确性，他说反正在google没找到结果，随后即猜想应该是必须引入框架，仅凭servlet应该是没法拿到参数的。对话进行到这里我基本判定是他的搜索姿式不对了，由于就问题而言真的没有那么special。当让他展现搜索过程时，他在搜索栏写到"i have an issue about retrieving url parameters, which is balabalabala"。也许你可能会笑，但这是咱们工做生活中常常遇到的可爱的人，或许他们真的觉得网络的另外一头有一个大神正戴着耳机，眉头紧锁的盯着屏幕回答来自世界各地的问题呢(尽管他本身也是个工程师，但仍然会迷信的认为后面有什么鲜为人知的大招儿)。在使用搜索引擎时，准确的分解、抽象问题，而且使用友好的分词组合是很是重要的手段，也是在人人平等的搜索引擎里，你如何脱引而出的根基。

2. 坐井观天必定稳坐第二把交椅，很多朋友对于新知识是深恶痛绝的，他们善于利用已知的(仅有的)知识来解释本身未知的领域，譬如常见的观点有：管他什么声明式仍是命令式，我都不关心。我就是要写$(...).show()/hide()，多直观的代码啊！你去搞什么Angular、React、vue，弄些什么数据驱动，都是吃饱了撑的。这些框架最后不也都乖乖的作DOM处理？与其等框架处理，我本身写很差么；管他什么模块不模块，我一股脑的写完脚本，最后concat -> minify一下，不也是一个文件么，乱七八糟的又是commonjs、又是ES6，还有什么AMD，看的头都大。＝＝＝＝＝＝有自信是好事，但在不了解背景缘由的状况下，生硬的拒绝并非高明的表现，或许数据驱动不适合你，但你肯定已经掌握数据驱动要解决的问题了么？或许模块化不适合你，但你又搞明白了ES6是怎么解决循环依赖的问题？AMD最先是为何被提出的？

说实话，没有谁是与生俱来的the one，咱们大多数时候遇到的业务模型，也没那么举世无双，不耻下问、兼听则明，只有不断的鼓励本身多学、多看、多听，多想才有机会跻身前列，或者说，起码能够作个对得起本身职业的人。

忙碌 !== 高效

下面绝对是张你们相识已久的图，我就很少说了：

盗图，侵删(若有冒犯，先行致歉)

有位朋友是这么评价图里推方轮子的人的，“你永远无法叫醒一个装睡的人”。

对于尸位素餐者，想必也不会来看我这篇东西，也就不用给出什么提升的建议了，由于他们“不关心”

但对于团队管理者，以及团队其它成员，大家要注意的是，团队如今的情况，究竟是高效率的忙碌，仍是使劲推着方轮子在赶路。

责任边界

图片是从百度搜的，侵删(若有冒犯，先行致歉)

有朋友可能会对该图产生疑惑，其实这里我想说的，软件工程团队讲求合做，合做首先要求每一个人把份内之事作好！

咱们常在工程师论坛看到人们抱怨PM的不专业和拍脑壳，总须要开发擦屁股、背黑锅。但话说回来，这个事情真的没有改进空间，没有避免的可能么？

咱们先假设工程师说的都是对的，问题就是出在PM身上，那做为一个团队，除了抱怨，你就没有责任帮助他提升么？你可能说PM的专业技能包含好多，我不会怎么帮？但沟通技巧、注意事项老是能够帮的吧？有人又说，PM趾高气扬，即使我想和他说说沟通的注意事项，他也未必听个人。接下来我想说的就是针对这类牛逼的合做选手的腹黑手段(固然也会迫使对方自我提高)。

我经历过一个团队，每次要从PM、设计师那里拿到需求和设计，可是因为PM和设计师的不专业，他们提供的需求里每每仅包含正确逻辑，譬如：一个登陆页面，只告诉你用户名、密码都输入正确时的应对场景；但没有说，用户名没输入怎么办，输入错误怎么办？密码没输入怎么办，输入错误怎么办？用户名、密码的格式要求是怎样的？这些交互上的其它问题他们都无论了。因而咱们的开发就和爱心妈妈同样，本身把可能遇到的问题，以及UI该是怎么样的，所有都开发一遍，而后demo给PM/设计师，让他们挑选一款，其他的再删掉！我去，这是多大的开发资源消耗啊！团队给个人答复就是，他们不懂，没办法，只能咱们作了给他们挑。因而开发进度被拖慢，谁之过？PM说了，开发团队不给力，作的太慢！开发质量不够高，经常一堆冗余代码删也删不干净，由于不知道以前哪一个设计待选稿里加的，删除时忘了，谁之过？PM说了，开发团队不给力，多版本处理不当。设计、交互不够好，谁之过？设计师说了，开发团队不给力，作东西东拼西凑还老是错。

我去，这让我想起了东郭先生和狼的故事，咱们辛辛苦苦帮你PM、设计师作大家该作的事，完事还被反咬一口！但仔细想一想，问题的缘由不是他们坏，而是开发团队模糊了团队协做时每一个人的责任边界，咱们固然须要亲密无间，但这不表示个体之间责任能够混乱。能者多劳当然牛逼，但任何角色都应该按质量完成本身份内的工做，这里开发团队只要咬死需求缺东西、设计不完善，迫使责任人修正就行了，而不是一味的帮他人善后。

自动化测试

提及自动化测试，经常有人会站出来反驳道，反正作不到100%的覆盖率，并且花费时间甚多，何须浪费时间写各类测试用例。这是一个重大误解，自动化测试及其意义咱们能够看到如下几点：

• 更省钱 － 对于稳定的功能(常见于回归测试)，能够作到一次编写，屡次运行

• 更快速 － 对于相同的测试内容，自动测试显然要比手工测试快

• 更可靠 － 对于相同的测试内容，自动测试的结果显然也比手工测试更可信(人是有可能犯错的，譬如：分神了)

• 更低风险 － 对于项目转手的状况，若是有自动化测试，更利于再维护

• 更强大 － 自动化测试能够模拟1w甚至100w人同时访问的并发情况，手工测试则仍然须要借助工具，不然没法完成

markdown

markdown做为一种轻量级的“标记”语言，愈来愈受欢迎，不管是Github，stackoverflow仍是segmentfault，都支持markdown编写、提问、回答。

不要被“语言”两个字所吓到，其实markdown超级简单，容易掌握，并且话说回来，不会写markdown，你就连在stackoverflow、segmentfault上提问都作不到格式整齐，还期望别人根据你混乱的描述回答你？别闹了好么，你们都挺忙的！

没有银弹

不管你遇到了什么问题，须要引入额外的技术手段，或者流程来解决，都必定要先了解即将引入的技术、流程的背景，工做原理，而后正确、准确的使用，不然事倍功半。

我见过很多人/团队，据说AngularJS好，都没仔细看明白人家到底解决了什么问题，就直接一股脑引入到本身项目里，胡乱使用，在controller里操做DOM，在service里也要操做DOM，出现问题后反而处处抱怨说Angular就是狗屎，咱们用了半天，什么问题没解决，反而出了一堆错。

也见过有团队据说scrum有助于提升团队工做效率，就引入了，甚至都没有作系统的scrum培训。结果致使连最基本的形式流程都作的缺斤短两，更别提深层次的理论结合实践再创新了。结果就是场面一片忙乱，但效率却丝毫没有提升。因而又处处批评，scrum就是一帮闲着没事的人搞出来的蛋疼产物，除了耍人，没有卵用。

这种思惟方式就是《建党伟业》里辜鸿铭说的：“孔子教人之方法，如数学家之加减乘除，两千年前是三三得九，今日还是，不会三三得八。自家学艺不精将题目算错，却怪发明之人，毫无道理”。

开发和测试的关系

当你认为开发和测试是敌对关系时，你就进入误区了。开发、测试没必要你死我活，也没必要互相仇视，你们是在一个团队，为同一个产品贡献力量，正确认识团队，正确认识合做，才能使咱们走的更远。

结束语

关于软件工程团队里的“常识”，我相信仍有好多内容须要普及，所谓普及，并非要求诸位关于上述的每一项都成为专家，而是时刻怀有敬畏之心、进取之心、钻研之心。坦白讲我不是什么高手，但我热爱个人工做，我但愿把它作好，也鼓励入行者都热爱程序员这份职业，以上篇章或有疏漏、错误，欢迎指正！

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝分割线========================================

后记(补充)

最近看到一些朋友的评论，质疑本章并不是软件工程常识，而是前端／web常识。我大胆猜想一下，几位朋友应该是看到本文中大量的前端／web词汇而有此结论，那么我想有必要稍微解释一下，本文并不是关于工具、技能、技术的整理，我原意不止于此。

一般咱们诉诸文字亦或语言来试图阐述一个观点、讲述一个道理时，会使用举例的方式使观点、道理更简明易懂，主旨并不是例子自己，而在于其背后的寓意。 就好像成语“唇亡齿寒”那样，咱们从中学课本里看到抗美援朝的缘由是“唇亡齿寒”，你不会真的觉得50多年前几位国家领导人由于本身牙齿不舒服，就派兵去朝鲜参战吧？

我之因此使用大量的前端案例，仅仅是由于我近几年工做重心于此，拿来顺手而已，若是因为个人例子过于贴近前端／web而给部分读者形成了误读，那我得为我自己知识的局限给你们道歉！同时也建议同窗们学好语文！

再有一个须要解释的东西，前端 !== web， 准确的关系是 前端 > web。

下面我来分别解释下我每一个章节都具体想说什么(语文很差的朋友，权当此补充为"总结中心思想"吧)

操做系统是不一样的

若是你纠结于于例子中的finder和explorer，facebook app，就认为我是在讲前端常识，那若是把举例对象换成shell和cmd呢？不会又以为我在讲命令行常识吧^^。本章的主旨在于，工程人员由于工做环境的缘故可能涉及不一样操做系统，因此必定要从心里中承认她们是不一样的，不然本身使用不愉快、和他人交流不畅、错误描述不许确。。。均可能影响你的工做。

复用

若是我不用browserify、webpack...而换成make、ant、maven会不会好些？软件工程界都会涉及复用问题，不管你写什么语言，作何种业务。

自我驱动

例子1中的servlet是但愿把读者带入具体场景，更容易理解问题。中心思想是，准确、正确的使用搜索引擎以及其余诸如stackoverflow、segmentfault等工具来解决你的问题是很是关键且重要的技巧。换句话说，难道不作前端，搜个delete row in mysql就不能够了？

例子2中，若是不用jquery和angular等举例，命令式、声明式编程，数据驱动的概念总仍是存在的，不信你去Wikipedia上找找Data-driven programming，不见得就是前端／web特有的吧？又好比后面提到的ES6等模块化概念，重点不在ES6，而是模块化的应用，关于代码的组织规范，总不见得只有前端／web才关心吧？

本节主要想探讨对于知识的渴望、运用与敬畏，若是你只能看到ES6和angular，^^....

忙碌 !== 高效

这节若是还能联想到前端／web，我就无能为力了

责任边界

本节我我想讨论的是团队协做中，责任边界的重要性。不管你是否开发一个登陆界面，在团队中都须要与他人合做、沟通，如何把握责任是相当重要的一点。

自动化测试

我相信大部分公司都没把UI自动化测试提上议事日程，因此本节不能说我在讲前端／web吧

markdown

我并不认为markdown是一种前端／web技能，难道做为一个常和matlab打交道的数据分析工程师/科学家，就不能用markdown写博客，不能用markdown在stackoverflow、segmentfault上提问了？不能由于和web有关系，就硬说这是web开发常识，不然，“你是学计算机的，那必定会修电脑喽？来给我看看个人显示器怎么了!”

没有银弹

若是我把AngularJS换成Berkeley DB呢？关于慎重引入新技术的这个话题，你还以为是前端／web么？

其实本节的中心思想在原文中已经给出了：“孔子教人之方法，如数学家之加减乘除，两千年前是三三得九，今日还是，不会三三得八。自家学艺不精将题目算错，却怪发明之人，毫无道理”。我不是在谈数学哦

开发和测试的关系

别告诉我，你只见过前端／web有测试，作别的内容都不须要测试？

其实认认真真在讨论web开发的，就只有Web不仅是前端的事儿，但若是你仔细读一下会发现，里面仅仅是一些词汇，我并没过多的介绍web开发技巧，所谈的无非是 做为软件工程师的职业操守罢了