除了滴滴，哪个打车软件更好用，求推荐
每天被滴滴司机气个半死，定位不准确就算了，有的时候司机来接的速度特别快，你到上车点需要时间，司机可能在你赶过去的路上取消了订单，尽管你电话说了。现在滴滴保证司机权益，司机有偿等三分钟，然后拒载，然后我下楼最多2分钟！
吐槽一下我这两天的打车遭遇！
昨天比较着急赶着去完成工作。刚好遇上暴雨，怕司机不方便在门口才打车，第一个司机显示到达，我冲过去，发现没有车，赶紧返回门口看定位，司机直接开走了，连打三通电话接起来那边都没有声音，然后三分钟后显示我迟到取消了！
第二辆，从我门口经过，说车上还有订单没完成，完成以后来接我，我同意了等了快十分钟终于开到了，我又冲出去了！他直接右拐开走了，并电话我，叫我取消订单，说雨太大，他是新手不敢开！然后越开越远！！！
第三辆到时痛快，一接单就取消，没有耽误我的时间。
等到我的第四辆车来了，天放晴了。我的衣服鞋子也都湿了，强忍着做了三小时的事情才回家！
今天有点迟了选择打车，司机离我上车点只有二十几米，就在小区楼下，但是不能调头，绕了小区一圈。。我姑且觉得他不想我多走几步，然后接我的时候非要说有探头，不能停在我站的位置，也不能调头。。。。我在那打了那么多次车，第一次司机非说这个巷子有探头，晚上都是停满车的！又绕了一圈！！！然后我彻底迟到了......
还有绕路的绕路，这个个例虽然少......
可能我的气场和滴滴不对付吧。我遇到部分滴滴司机态度真的很好，但是两极分化过于严重，打车都是凭运气的！！！
求推荐！

我现在最怕的是别人跟我讲软件工程了，说起来头头是道，做起来另外一套。
我觉得软件工程的目的就是使开发过程性价比最大化。
所以，在中国，客户是上帝。销售把上帝忽悠好了，程序员可以省去非常多的麻烦。送点钱，吃吃喝喝也是软件工程中非常重要的一部分。
所以，软件公司的销售人员永远都比程序员受到重视！

软件测试底层逻辑是什么？我们先看一个案例：

之前我在一家公司面试时，被问到一个问题“就你刚刚座的电梯系统，你应该重哪几方面去测试他？“，多年以后我也以同样类似的问题面试过很多人。

面试者A：首先，测试它的功能：比如按一楼、中间楼、顶楼等按钮；电梯超重提示等，其次，安全性测试：停电、报警、物体防止脱落等~

 

面试者B：首先跟相关人员确认的测试的范围和验收标准，然后根据测试范围和验证标准制定相应的测试计划，测试方案，评估测试点。然后根据测试点从多个维度边界测试用例，比如考虑系统功能可用性、安全性、稳定性、易用性等多方面编写测试用例。在功能性测试上要考虑在不同位置按不同楼层的场景，电梯不同的表现等

 

面试中遇到的最多的是第一种，偶尔能遇到第二种，能回答第二种的，我认为就比较厉害了。

 

软件测试底层逻辑是什么？当我们在说要测试某某东西的时候，实际是要如何保证产品的质量。

要回答这个问题，我们得回到我们最初软件测试的职责是什么？是保证产品的质量！

那如何保证产品质量？用6个字概括：流程、制度、和方法



 用流程保证项目相关环节是可控的、有序运转的；用制度约束和激励项目相关人，保证项目的正常进度；用软件工程方法提升测试人员的测试效率、测试深度和测试广度。

软件测试流程是什么？：

往大了说：敏捷流程、IPD、H模型、W模型、瀑布模型等我们熟知的项目流程；

往小了说是：你的测试流程、测试计划、测试方案等等

制度有有哪些？：公司行为规范、绩效考核、员工的核心价值观考核等等

测试方法有哪些？：探索性测试、流程测试法（场景法）、边界值测试、安全测试、白盒测试、黑盒测试等等。。。

 

测试内容从哪几方面思考呢？

 1、基本的功能测试（电梯上下，开关门）

 2、安全性测试（断电等异常情况）

 3、易用性测试（按键等可操作性）

4、稳定性测试（持续运行时长）

5、负载测试（同时可以运行多少人等）

6、部署文档测试

7、可靠性测试（外部温度变化，对器材的影响）

故事背景
之前在一家小公司待过一年多，在里面做了什么呢？

去过现场采集客户需求，也就是跟客户沟通交流，主要还是做好记录，形成文档。
每次开会讨论需求（需求审核），不仅要理解同事们讨论的内容，还需要积极的记录会议纪要。有一次周末，两个领导和我在办公室讨论，一个会议纪要，他要求我修改了4次才算合格，现在想想估计领导想培养一下我。
还要整理需求文档。整理项目有哪些功能点，功能需求是什么，功能如何才能嵌入到已有的系统中去。
还要画实体图，利用实体图标注数据流向，其实就是一个利用实体来说明项目流程。
还要写用例规约。模范用户和后台服务这样的，比如用户在浏览器页面做一个操作，后台响应一个操作，如此往复地写用例规约。并且每个字段都需要把业务规则写的明明白白清清楚楚的。
为了理解得更好，我也会偷偷地画UML图，完全按照自己主观去做，没有什么规定，自己觉得需要画画才能理解得更好，就画出来。
编写代码。完成功能模块。
做测试。使用jmeter测试，修改一些sql,调整一些参数配置。
修改bug。
跑现场。看用户使用。


现在在一家创业公司，在里面又干些什么呢？

公司分布在各个城市，沟通全程使用语音。这个就增加了很大难度。
创业公司，做事是没有那么多条条框框的，不会写什么需求文档，概要设计，详细设计之类的，策略就是，小步快跑，快速迭代，反正都是工程师敲代码。一个需求，先弄出来，客户看看，不合适再修改。也不知道对还是不对，反正就是很反感。
询问需求。使用语音跟产品负责人沟通，问问这个功能要这么做吗？换个方式怎么样。
讨论需求。主要是和同事们一起讨论，主要是自己不懂，然后主动问问同事们，毕竟他们工作经验丰富，聪明。
讨论实现方案。还是和同事们讨论，说某个功能，这样做可以吗？询问一个比较好的实现方式，不然最后还是得修改回来。或者说需要反复修改。时间和精力都是资源，浪费了就没有了。
编写代码。
修改bug。
写文档。会写一些基础的文档。不过大都时候都是自己记录一些项目的重要事件。比如梳理核心逻辑，记录重要的时间节点。
上线，后期维护。


软件工程师具体的工作内容是什么呢？

熟悉公司技术栈。一个公司应该有自己固定的技术栈。这套技术栈会应对公司具体的业务需求。当然，创业公司的技术资源是比较少的，需要招聘人员从上一家公司带来一些。
询问需求。需求先跟产品沟通讨论需求，了解客户有哪些需求信息。
整理需求。以文档的方式把跟产品沟通后的需求，按照功能模块逐一进行梳理整理，需要写得尽可能详细。
讨论需求。就是需求评审，确认哪些需求是合理的，哪些需求是不合理的。进行有意义的需求评审，这个特别重要。
确认需求。再次跟产品确认需求，一方面是确认就是要做文档中呈现的需求，另一个方面也是检验开发者是否对需求理解到位了。如果发现开发者跟产品理解不一致，是需要作出修改。这个时候产品也需要跟客户再次沟通，确认需求是否是客户真实需要的。
整理文档。把项目的时间周期呈现在文档中。把项目中所有需要的功能模块，都需要用文档进行详细说明。
设计表结构。根据产品画的原型，抽象成软件设计的概念，现在大都是抽象面向对象概念。
画实体流程图。用实体流程图来说明项目的核心流程和数据流程。因为一个系统其实就是实体来描述的，而实体数据的流动其实就是核心流程逻辑了。
画必要的UML图。加强实体间相互关系理解，这样可以搭建一个好的类关系组织图。这里没有好或者不好，只是如果把这些需求当成工程技术那样严谨的思考，这些步骤还是可以做的。根据自己需要，灵活应对，如果自己理解力够好，经验够了，这些步骤可以直接在脑子里做。如果理解力不够好，还是该画就画。
画项目核心功能逻辑图。把项目中比较复杂的和非常重要的功能逻辑，画成图，目的：辅助自己理解。
用汉语把功能写出来。其实写代码就是写故事，用汉语可以先把故事写一写，然后用编程语言把故事在描述一次。做两次是非常好的，第一次会考虑到一些细节，因为当接触一个新的功能逻辑，其实是陌生的。用熟悉的汉语写成一个故事，是可以辅助理解的。其实，橡皮鸭的调试法就是这样的。用自己的话，用自己的理解把整个过程说出来。
编码。把前面的工作都踏实做好了，编码就是一件非常简单的事情。
单元测试。需要注意一下，哪些是必须测试的，哪些内容根本无需测试。
bug修复。
上线。
总结。一个项目做完后，把重要的bug，进行整理和学习。把做得不好地方进行梳理，下次需要改善。
学习新技术。这个也是工作的一部分，而且特别重要。


大厂的软件工程师都做些什么呢？

…
…
…
…

…


小结

梳理软件工程师工作内容。