1
时隔一年后，相同的坑进去两次，悲惨！
究其原因，还是一样的。各种分支代码的维护，导致一套架构在各个项目上千疮百孔，架构已从A迭代到W了，但还是拿着A在重构，不出问题才怪，说到底，还是管理的问题。
讨论架构设计有问题时，有个程序猿说了个很奇怪的言论，“老板难道不知道架构这么多问题吗？如果搞一套完美的架构，那测试等其他附属的部门是不是要下岗了？架构差一点，就业机会是不是就多了一点？”
什么？‘资本家’这么善良了？为了创造就业岗位，自己牺牲每个月几百万的流水？
这理由很难站住脚！也不过是能力差的说辞。如果啊，真的这么牛X的架构，砍掉其他附属部门完全可以，一套代码坐收渔翁之利，但那只是梦！现实是，一个架构引出N多分枝，然后分枝再分枝，修修补补，多到枝繁叶茂，却结不出果实。
“祝愿你们的代码少一些bug，多一些挚爱的用户。”
2
如何做测试，从而保证可以开发出可靠的、值得信赖的产品，一直是值得不断思考的问题。
有段时间奉行“少则清晰”，于是在测试用例及流程上进行删减，关注用户痛点，解决痛点，好处是确实能从大方向上把握，让一个产品趋于能用的状态，不足的地方就是，细节无法都关注到。导致有的BUG就在那等着你，然后默默的恶心下你。
所以，基础的东西还是不能丢，因为你没有一个支撑你丢的架构，也不应该丢，因为那是根本。学再多高大上的玩意，基础丢了，确实会出大错。
在《Google软件测试之道》中有这么一句话：质量不是被测试出来的。
但其具有两层涵义：
质量不等于测试，当你把开发过程和测试放到一起，就像在搅拌机里混合搅拌那样，直到不能区分彼此的时候，你就得到了质量。
如果某个产品出了问题，第一个跳出来的肯定是导致这个问题发生的开发人员，而不是遗漏这个bug的测试人员。
一个产品团队不能任意降低测试人员招聘的技术要求，从而雇佣更多的测试人员，然后再让他们做一些简单和琐碎的脏活累活。这些功能相关的脏活累活本应是开发人员的工作，不能简单地扔给倒霉的测试人员。其实反过来，一个团队也不能招聘一个和团队技术要求不符的人员，如果一个水平一般的开发，在不了解业务的情况下，就开始快马加鞭的写bug，那受累的是整个团队，而不是某一个人。
3
国家应该好好的治理下中介行业，这个利用信息差，可以随意赚取服务费的行业，真正实际的社会产出是什么？存在是有多少能真正帮助到该帮助的人？更多的是电话、信息骚扰，有个APP，你注册完以后浏览，不出3分钟就能收到电话，问您是否找房看房买房，精准服务，可能开发这个产品的项目经理觉得，你不看房买房，浏览它干嘛？既然浏览了就应该有需求，有需求就有必要赚点服务费，这样的设计确实精准，但是很讨人嫌。这妥妥让人意识到，这玩意不能打开，否则像被人监视了一样（虽然实际也是），大数据也意识到，打开了，那一定是有了赚钱机会，来，张经理负责电话跟进一下。
4
很多人在遇到别人做不好，或者做错事时，总会忍不住想要去指导或者评价一下。这个行为其实是在告诉对方，不太允许你。
如果可以的话，无论对方做什么事情（前提是没有踩到你的底线，或者涉及到对方的生命危险，人生规划等等），你尽量允许对方去做，允许让他犯错。不要去给对方任何的建议。即使你知道他的行为马上就会犯错，你也不要给他任何提醒。只管让他去做。
这个是为了给对方建立一个被允许的环境，在这个环境中，对方可以无压力地进行自我检验和修复。