在it岗位上工作久了，看到许多陋习，也积累了许多的经验，通过这些经验可以提高工作效率，减少重复劳动、无效劳动。
1、早失败原则
项目中我们经常过度设计，自上向下，一步步进行，这样的好处是正规、系统，但是也有不可忽视的坏处，具体就是太迟实践，许多设计上想得天花乱坠的东西到了实践发现不可行，或者实现成本太高，只能舍弃。
所以才会所谓敏捷开发，对于设想好的内容早去实践，早去试错，就算出错也要早发现，早规避或者早放弃，减小舍弃以及选择的成本。敏捷开发还有其他好处，比如以实践的结果反过来指导设计，提高设计的可行性。不过，既然是敏捷开发，那就是一种尝试，试错；以行动辅助决策。
2、建立适当的”锚点“
在项目中我们会有各种阶段性成果，此时一般通过版本tag、产品动态等体现，通过这些动态、标签我们能够回顾历史、快速切换，还有其他好处：当多人开发时，其他人能够通过动态知道其他人负责部分的变更，便于协调一致，如果锚点对于便能内容体现得较细，提供了环境更新的相关脚本，本地搭建环境更新时也能更加快捷。
3、提高并行性
在项目中往往有多条线同时进行，为了使得这多条线顺利并发，需要为各条线提供“隔离”的环境，这在搭建环境、进行并行开发时都要注意：如何做到环境的个隔离性并尽量不去破坏它。
4、延迟优化
各人风格不同，一个程序员看到其他人的代码可能会有自己的见解；就算自己的代码，或因为时间紧迫，或因为试新的冲动，往往要进行重构，但是从项目的角度来讲，最好还是不要轻易重构，除非能够进行完整覆盖测试。轻易的优化往往是一种无谓的折腾。
5、细化规范、严格执行
小公司要讲究灵活机动，但是许多规则、制度仍然要规范，要认清人的积极主动性，但是也要防好人的懈怠性，切勿让小失误引起大损失，积累成大矛盾、低效率。管理者不仅仅要统关全局，还要激励手下人，推动手下人执行，培养手下人执行的习惯。
作为程序员，本人提供一些具体的实践经验
idea是一种java开发工具，使用过程中有不少坑点：
1、作为后台开发人员，对于前端接触不多，但是每次同步代码之后都要一直indexing，其中包括前端资源，大小很大的压缩js，更新起来很耗费资源，此时通过设置可以去掉这些索引的建立
将相应的file type去掉：
2、每次idea失去焦点之后，就会编译整个项目，并将当前的选项卡定位到第一个出错的页面上，如果停止idea的这种“行为”？可以通过如下设置：
3、idea 正常情况下不实时编译java代码，尤其开发web项目，如果要实时编译，而不是每次修改都重启，可以考虑使用jreble,使用方法详见:http://blog.sina.com.cn/s/blog_a890396f0102vvon.html
针对早失败的原则，需要做到：
1、每一阶段的测试（本地、测试环境、类正式环境，正式环境），都要切实走一遍，尽可能去暴露本阶段会出现的问题，好及早修改，越前面的阶段，bug修复、重新部署的代价越小
2、每一阶段测试自己的暴露任务完成的情况下，尽早部署到下一阶段测试，这样可以尽早地暴露到接近真实的环境中测试，及早修改掉有问题的地方。而不是在前面阶段做太多不必要的覆盖与折腾。
下面分享一下自己的开发新代码以及改bug时提高效率以及执行力的一些心得：
1、在起初上手、搭建环境的时候，要追求早失败、早解决，方法如下：及早让整个项目运转起来，先整体流程走通，然后细节各个击破；提高测试的方便性，每个小方法都及早进行测试，已测试来帮助我们暴露问题。
2、在遇到问题的时候，如果花了很长时间但是还是不能解决问题的时候，不要“卡”住，此时可以做些其他方面的零碎工作，此时不要做复杂、困难的工作，因为这样容易让本来就已经糟糕的心情更糟。如果其他人有空，可以拉上他们一起讨论，很多时候“思维定势”的问题还是存在的。
3、“黑箱”调试
这个主要针对bug修复，我持这样一个观点：相对于业务人员、用户，我们有能够了解内部逻辑的优势，但是很多时候我们不需要了解太多细节就可以修复bug。首先不急着去了解、看代码，而是先从推断、经验中理出需要看的地方，可能出问题的地方，像剥洋葱一样一层层去环绕着去探索，而不是像吃饭那样要咀嚼、消化掉所有的颗粒。
当没有解决思路的时候，可以投石问路，看一些可能有问题的地方的代码，尝试一些可能显露问题症结的做法，以调试法来定位问题。对于测试环境（非线上环境）可以通过多打日志，配置调试来得到这些尝试的详细反馈。