软件公司生存的一些想法

1. 如果你选择用某一种技术是为了这个产品更好卖，那基本上可以说你不上道。
2. 一个开发模式或者设计模式，是否适合引入到你的项目中，也不取决于这个设计模式多先进，而是取决于使用这些模式的客户，也就是开发人员是否能够理解和掌握它们。如果不行，那就不是一个合适的技术。这个时候你有几个选择：1、教育你的员工；2、换一批员工；3、放弃这个技术。对于一个新公司来说，可见选项1和2成本都是非常高的，而选择3也许会让你很不爽，但是却是一个较为可行的方案。
3. 企业级框架的部署和应用具有极高的风险成本。很多时候，对于一个创业阶段的小公司，其生存能力取决于他的应变能力和执行能力。打一个比方说，某天突然中国移动和你达成一个合作意向，前提条件是你能够提供该服务。这种合作背后有两个潜在的逻辑：a)很可能某天突然有第三家插进来，比你更早提供该服务，于是正式的合作合同就泡汤了；b)更重要的是，即使你提供了该服务，出于其他客观原因，最终该意向还是很有可能不了了之。于是，你可能辛辛苦苦做出来的东西，最后却是毫无作用。要知道，庞大的东西如果毫无作用，反而可能会是一种负担，这个时候就会很尴尬：拆除他还是不拆除？通过做Branch的方式也许在面对一个这样的合作还有可能，如果同时不定期的进行多个项目，用Branch来避免拆除问题就比较不切实际了；
4. 企业级框架，甚至设计模式对于很多开发人员来说仍然是一种天书。千万不要以为开发人员都会像那些搞出设计模式或者TDD开发模式的先知那样聪明，如果真那样的话恐怕你我之间都是比尔盖茨了。根据我的经验，以一个小企业所能够找到开发人员来说，能够理解这些东西的人不会超过33%。也就是说，你在这里面如果应用这些设计模式、开发模式，无非就是面对如下两个结果：a)那66%的人需要你去告诉他你写的到底是什么（对于他们来说，你在写天书）；b)那66%的人会干脆绕过你的代码，重新写一堆很烂的代码，这种情况居多。这实在不是一件什么好事，比如你会看到一堆恶心你心情的代码。此外你可以想象原本好好的MVC代码，一层层剥离的很好，没过一段时间可能就会有人直接在V上面写一堆的SQL语句和业务逻辑。我在这个时候宁愿没有MVC结构，这样我就不会浪费时间调试M层明明正确的Sql和C层明明正确的业务逻辑了，更不会搞不清楚他到底什么地方乱写一气，什么地方有突然调用了底层的代码了。当然，这是最糟糕的情况。在最好的情况下，随着时间的推移，乱写一气的代码总会不断的堆积并占绝对多数。也就是说，你的努力最终都是白费的。