中间层
计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决，遗憾的是,这句经典的名言出处无从考证
参考文章
计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决
现实例子
各种中间件，比如分库分表中间件
重启
重启可以解决计算机系统99%的问题
现实例子
比如iphone系统卡死
分类： 软件开发定律和心得
软件工程中的开发方法
如何准确的评估工期
——视频出资微博视频大佬 蛋疼的axb
问题1，过于乐观评估,导致延期，会被leader认为不靠谱
估计三天写完，但是遇到了问题，又花了三天，又遇到问题，又…
问题2，过于保守的评估，也会被认为不靠谱，leader预期一两天就完成的任务
你处于保守估计给出了一周甚至更多的工期，问你哪里有问题，你又说不明白， leader觉得还不如自己做。
以上问题会导致有重要任务就不找你了。
保守评估时给出技术难点困难， leader信服。
解决方案
1.客观正确的评价自己的能力
不要一上来就编码，花2/3的时间设计和测试（测试驱动开发），1/3最多1/2的时间用来编码
2.正确的认清你要做什么事情
如果事情以前不是由你主导到，首先要花时间了解来龙去脉，尤其是注意有没有坑。然后再花时间去预估工期
3. 将开发评估工时当做一种必要的习惯来训练。相似度非常高的项目可以套用，工期评估更准确。
具体的方法
将具体需要的完成的工作列出来，比如划分成多少个模块，需要建多少个表，完成多少个接口，写多少测试。
如何避免成为一个不靠谱的菜鸡程序员
软件开发的绝大部分时间都在和风险打交道，要提升自己预防和对抗风险的能力。
知道自己的能力有限（比如理解慢反应慢思考慢），掌握的知识有限，掌握的信息有限，在做相应事情之前要做充足的提前准备；
在对方案之前你需要了解更多的关于方案的背景知识；
在提交测试之前，一定要自己多测试几遍，因为你写的代码一定会有bug；
做设计之前提前想好各种问题的解决方案；
过于追求完美导致的风险
想做代码重构导致上线推迟了；
想修复bug发现不是bug是feature；
越是追求100分的程序员越是需要知道60分的可贵，先做到可用的状态然后再进行优化，避免过早优化，过早优化是万恶之源
举例说明花十天工期完成1个项目
方案一，花9天开发到一个完美的状态，1天内完成测试联调上线这一系列的工作，
方案二6天完成一个基本版本的开发测试联调上线，剩下4天时间逐渐做迭代，应对风险能力强。
风险优先开发原则
按风险评估开发的顺序，风险越高，后果越严重的越需要往前排，这样能让你更早的遇到问题，即使你解决不聊这个问题，你也可以提前去查询资料，求助同事，或者把这个风险告诉主管提前得到预警。
程序员如何优雅的讨论排期
和产品达成共识，目标是提升整体事情的运行效率，推动事情发展。并不是一直加班就能解决问题，提示效率和兼顾质量和可维护性才是重点。
个人的经验总结
项目维护
接手旧项目时，不理解的代码，一定不要去乱碰。nginx配置也是一样的。你不知道它在哪里被用到了。不能抱有侥幸心理。
项目永远不会结束
不要相信客户和产品经理以后不会改需了这类话。产品(项目)存在意义就是解决人的需求(市场)，让更多的人使用它，人的需求是变化的(市场竞争)，项目只要存在就会有需求改动和功能增加。但是不能任由产品乱来。类比，好多人会追问生命的意义，生命的意义就是好好活着，生命一旦不能生存就只有死亡没有什么意义。
容灾
运营的项目一定要有容灾能力，服务，数据，文件 ，安全。不能抱有侥幸心理。这是常识。写在这里是为了提醒自己不再犯错。
关于测试
所有想法和解决方案，都必须经过代码的实践测试，不要相信没有经过测试的代码
我亦无他，惟手熟尔
遇到一个我认为是坑逼的程序员，认为他坑是接手了他写的项目，全是bug和问题，给公司造成损失了。框架工具没有熟练掌握，代码写的很敷衍，大部分代码都是复制粘贴别人项目里的代码。但是他花了十几分钟解决了一个我花了一天时间没有解决的问题，一个php5.5的比较古老商业CMS系统。因此想起了这句话。
作为一名程序员应该放下对”大神”和”大牛”的偏执，以及对”坑逼”的成见。不要以这些词汇来衡量技术水平。技术领域广阔，技术栈繁多，人的能力是有限的，所谓隔行如隔山。技术应该专业和专注，静下心来，专注于业务，问题和代码，放下情绪。能解决你擅长领域的问题的程序员就是好程序员。
诺维格定律 (Norvig’s Law)
破窗户效应
墨菲定律 (Murphy’s Law)
或许是所有的定律中最广为人知的，因为它不仅仅适用于软件开发领域。
凡是可能出错的事就一定会出错。
衍生定律：说脏话是唯一一门程序员用得都很流畅的语言。
推论：计算机会按照你写出来的方式运行，而不是你臆想出来的。
防御性编程、版本控制、测试驱动开发、模型驱动开发等等都是预防墨菲定律很好的做法。
布鲁克斯法则(Brook’s Law)
霍夫斯塔特定律 (Hofstadter’s Law)
霍夫斯塔特定律是由道格拉· 霍夫斯塔特(Douglas Hofstadter) 提出，并且以他的名字来命名的。
不要将这个定律与《生活大爆炸》中的伦纳德·霍夫斯塔特混为一谈。即使他的话对你们一些人或许有用。
这个定律是这么说的：
事情总是要花费比你预想更长的时间，即使你把霍夫斯塔特定律也考虑在内。
这条定律的递归性反映出，即使付出最大的努力，也知道任务是复杂的，去精确地估算它依然是非常难的，所以要给估算留一个缓冲区出来。
康威定律 (Conway’s Law)
软件的任何一部分都反应了创建它的组织结构
康威定律 (康威法则 , Conway’s Law) 是马尔文·康威1967年提出的：
“设计系统的架构受制于产生这些设计的组织的沟通结构。”——M. Conway[1]
即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式。
康威定律源于模块的设计者需要互相之间频繁沟通。而跨部门交流比较难。[2]
埃里克·雷蒙在《新黑客词典》中，称康威定律指出了软件架构与软件团队架构的等价（congruent）。例如，“如果你有4个团队在做一个编译器，你会得到一个4遍处理的编译器”。[3][4]
James O. Coplien与Neil B. Harrison在《敏捷软件开发的组织模式》中写道:
“如果团队、部门、子部门等的组织结构没有紧密反映产品的必要组成或产品组成的关系，那么项目将会遇到麻烦。因此，应该确保组织结构兼容于产品架构。”[5]
康威的原文中提出的各定律[1]：
- 第一定律 组织沟通方式会通过系统设计表达出来
- 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
- 第三定律 线型系统和线型组织架构间有潜在的异质同态特性
- 第四定律 大的系统组织总是比小系统更倾向于分解
Eric Hollnagel在2009年的《Efficiency-Effectiveness Trade Offs》一书中类似的论点：
Problem too complicated? Ignore details. Not enough resources?Give up features.
或者更清楚一点：
组织形式等同其设计的系统架构
许多组织都根据他们的技能来划分团队。因此会有前端开发、后端开发和数据库开发组成的团队。这会导致某人想要修改一个不属于自己领域的东西会很难。
最好是按照有边界的上下文(bounded context)来规划团队，并且越来越多的组织者也正在这么做。像微服务这样的架构围绕服务边界而不是孤立的技术体系划分来组织他们的团队。
康威定律带来的具体的实践建议就是：你想要什么样的系统设计，就架构什么样的团队，这会带来事半功倍的效果。