我想这个例子很好的说明问题：古希腊叙拉古被罗马围城，几个希腊士兵想用一个杠杆抬起一块石头，这时候阿基米德高呼，用个短点的杠杆。周围人不仅凄然：“阿基米德真是心力交瘁了，连自己发现的定律都不清楚了”。只有阿基米德清楚，根据杠杆原理，的确是力矩越长越省力，但是在实际情况下，杠杆本身也是有重量的，如果杠杆增加长度带来省力还不如杠杆本身重量的增加，那就是力矩越长越费力了。
自然想到了许多听起来意气风发的名词UML，ISO国际标准等。但是使用这些，真的在我们实际工作中是最高效的途径吗？一个简单Excel能说明的问题，有必要用UML来描述吗？一个Excel 就能完成的进度管理工作，有必要再耗时费心的去学所谓“正规”的进度管理软件吗？
实际工作中的开发，不是为了开发而开发，更不是为了炫耀自己是多么的专业。主要目的还是为了能够开发出最大盈利的产品，需要结合当时的情况，在开发周期和盈利周期取得一个整体最优的平衡。什么所谓的设计模式啊，标准流程啊，如果一切都按照教科书上的一板一眼，基本上也就是一个现代的纸上谈兵的下场。在这里还是要提那句老话：实践是检验真理的唯一标准。
而在整个这个过程中，遇到的问题，按照教科书里面提到的方法，未必能最有效解决当下的问题，甚至把书翻烂了，也未必能找到一个靠谱的建议。这时候怎么办？本书的作者阿朱给出了很好的例子，开发和实施，开发和销售，文案的培训，这些现实中客观存在的挠头问题，就算翻烂所有的软件工程方面的书籍，也无法找到答案。但是阿朱却用自我发明的土法子一一化解，并且得到了很好的效果，虽然过程中也走了一些弯路。
虽然他列举了许多具体的方法，但是我并没有刻意记住太多。就如同《笑傲江湖》里面谈到的，招数再多，也有不灵的时候。最重要的是看破《独孤九剑》里面的用之四海而皆准各种式，例如“破剑式”，“破枪式”等。阿朱的独孤九剑我总结下来，更加简单，就是两点：客观了解本质原因和主动积极的行动尝试。
正如阿朱说的：自己如果不救自己，就更不能指望别人来救自己。现实情况的确有很多不完美的地方，但是如果万事俱备，还用你做什么？有很多网友感叹阿朱点子多，我想他也只是做好了本职工作，遇见问题，就主动想办法解决问题而已，而不是被动等着老板给自己给自己架桥铺路。
在任何一个公司里面，软件开发过程中必然会遇到诸多非标准化的客观条件，无论是资源还是规则。这时候我们就面临两种选择：坐等客观条件都符合标准之后再工作还是基于现有条件，提出一个非标准但是有效的解决方案。
所谓的名门正派的“正规”标准，真的值得我们劳民伤财，削足适履的去坚持吗？