一个创业公司，在开始一个项目，往往涉及一个技术选型的事情。即便是大公司，开新项目，也涉及技术选型的问题。

这个话题往往会引发很多没有结论的纠纷，因为不同的技术路线爱好者都有自己的判断，不过我还是那句话，脱离场景谈技术都是耍流氓。

微信公众号不能修改已经发布的内容，这个很不爽，其实我挺希望写一些开放式话题让大家参与讨论，然后一点点修订增补，形成一个真正的知识库文档，然而微信现状是不能这样的，所以我还是抛砖引玉说点自己的一些看法吧。

1、尽可能不重复造轮子，但也要根据实际情况而定。

我挺喜欢开源社区，我觉得很多优秀的项目和优秀的代码都可以拿来主义，比如做游戏，客户端有cocos2d-x，可以一次开发，多平台发布，减少很多开发成本，而且效果也不错，干嘛不用。 服务端有大牛 云风的 skynet开源，我能招到比云风牛的程序员么？显然不能，差一点的能不能？差一半的都招不到，云风的代码免费在这里，而且完全开放授权，我干嘛不用。

不重复造轮子需要满足几个前提，第一是市场上提供的代码和系统基本满足你的需求；第二是授权和使用成本（如果涉及商业软件）和预期收益相比非常的低。第三是尽可能在遇到问题的时候可以找到技术支持，包括官方的，或者哪怕官方不提供支持但是第三方使用很广，你可以方便找到熟悉的人来解决使用中的问题。

第三条很容易被忽略，但出问题和状况的时候特别头疼，实话说，绝大部分人选用第三方技术方案或开源系统的时候，是不会去做源代码分析的，这就导致一旦出现诡异的技术问题，自己去分析和跟踪的难度极高，往往需要官方支持，而有些开源系统早就找不到官方，这就麻烦大了。

有些情况也必须硬着头皮自己造，比如市场上没有符合你基本需求的代码，或者虽然有但是改动成本过高，或者无法得到有效的技术支持，有时候我们会发现一些特别简单特别小的开发任务，因为选择了一套复杂庞大的第三方架构，结果是比自己从头开始做还要可怕。

这里要特别强调几个选择误区

误区1是求全，选择功能最多的开源软件，其实你根本不需要那么多功能，而其性能可能极为糟糕，又或者二次开发的难度太复杂。 这个错误我也经历过。

误区2是需求定义过于自我，某些场景下，你的业务模式的竞争力并不在几个细微的产品设计上，但为了满足某些你自以为不错的产品设计，放弃了某些本来比较好的开源系统或选择了对原有代码做较为复杂的二次开发，结果发现得不偿失，耽误大量的时间成本和开发成本，而对业务其实并没有帮助。

 

2、不要为过于长远的东西考虑过多。

大家都希望自己的系统低耦合，通配性好，可以完成任意的后续功能的组合，但这也要有个度，当然这话题要是讨论起来就没完没了。

简单说，如果你技术架构能力很强，（主观判定），知道代码在编写中低耦合高扩展，你可以在设计的时候，在满足现有需求的基础上，以不额外增加开发成本为前提，（注意这个前提！！！），做一些扩展预留的考虑。

如果你技术架构能力不强，满足现有需求即可，尽量做到低耦合，代码要尽可能简洁，并写好代码注释。

我有个观点，与其做一套通配的结构，不如让自己的代码更容易被修改。特别是对于技术架构能力不是特别高的开发者。

我特别佩服一些草根创业者，明明没什么技术背景也能把一些我认为很头大很复杂的问题处理掉；有些处理方法你可以认为是很low或者说是很粗糙的，但是管用人家就把业务做起来了，也从来不强调说自己是技术产品；但很多技术创业者反而容易因为自我感觉太好在一些很小的细节把自己陷进去，为了追求技术的完美或扩展性，消耗大量的时间和精力，拖累整个项目。

 

3、因人而异选择技术路线

有什么人，做什么事，有些技术方案很好，你的技术人员不擅长，你也只能看着。 技术方案，在相差不大的情况下，尽量选择你所信任的技术合伙人擅长的领域。

说个秘密，直到现在，我直接主导的项目还都是用apache做web server，而不是性能指标更胜一筹的 nginx，为什么呢？因为我发现nginx+php 在高负载的时候会偶尔出一些500错误，而这个问题的原因直到现在我都没搞明白。 在没有能明确这个问题之前，我就只有选择apache，因为我确信apache用了这么多年没出过这个问题，而且我知道apache参数如何调优，至少单台线上每秒钟跑了1000次php请求是抗的住呢。其实我也不用担心性能是个瓶颈。（技术评测往往夸大了不同平台的性能差异，这是另一个话题，今天不展开，实际上在常用的动态网站处理中，apache和nginx的性能差异并不会特别大。）

说这个秘密啥意思呢，因为很多人都说nginx比apache好，性能卓越，这必须承认，但问题没搞清楚之前我是不会用的，如果有人说他能搞定或者肯教我我也愿意换过去对不对。

对你的开发也是如此，有些技术方案或者技术平台确实不错，但是如果你的人只是觉得不错想去尝试，那么他作为技术人员，他尝试当然会有收获，下一份简历多一项技能，但是对于公司而言，这个风险成本是要仔细斟酌的。

你说java好，我说php好，这事永远扯不完，但是如果你身边有一个高手就是java的，那你还是选java比较保险。

 

4、参照标杆选择技术方案

如果你团队还没有技术合伙人或者技术合伙人是个多面手，并没有明确的方案偏好，或者你希望团队未来不依赖于单一技术合伙人，那么建议参照你们所处领域大多数企业或者领先企业所选择的技术方案。

这个参照标杆，只是参照一些常规的技术方案，你说你一个准备开个网店赚点钱的你非要照搬淘宝的技术方案是不是有点扯。

所以，这个参照别真陷进去了，巨头的开发逻辑和一般的创业公司或二线公司差异是杠杠的，你多看看和你近期目标类似的企业大部分用什么技术方案就好了。

这个参照还有一个好处，因为在人力资源方面，你挖人，招人也容易招，既然同行很多用这个技术方案的，那么这样你招人相对比用冷门方案的会好招一点。

 

5、数据结构建议请专家看一眼

这一条大概有点离题，严格来说不是技术选型，但是基本上你技术选型后下一步就是定义数据结构，具体的技术问题我之前有系列文章，这里不赘述，但是想说一个概念，数据结构是整个产品非常重要的一个支撑结构，即直接体现了需求的满足度，也是未来扩展性的一个重要考量，不是说你数据结构做的特别灵活就是扩展性好，而是如果你数据结构做的特别死，以后可能改起来就特别的累。

做过研发的应该很多都知道，一旦数据结构要调整，没有小动作，改的地方大了去了，所以数据结构这块要特别引起重视，前期结构不一定需要考虑太多扩展，但是有些灵活的考虑要做到，未来有扩展尽可能不要改前期结构，比如用新增结构扩展需求。

我以前的习惯是，新项目可能代码我不会去看，数据结构一般都要先看一眼，没有大问题再让团队做开发，最近比较偷懒了。

希望一些非技术创业者理解一句话，数据结构出错的改动成本比代码出错要大的多的多的多！

 

6、非业务核心可外包

中国很多公司不太相信外包，其实我也会有这个担心，确实外包公司良莠不齐，而且实话说，外包开发的公司一般不太会有最优秀的开发团队。

但是运维是可以外包的，比如各种云服务商，尽量选择口碑最好的；安全也是可以外包的，第三方安全公司也是有一些的，也尽量选择口碑最好的。在安全和运维上省钱是不明智的！

开发，在一些非核心模块上，外包也是可以的，比如你临时搞一个运营活动，让人开发一个微信活动的模块，这事其实并不复杂，也比较容易控制质量。

 

7、让技术专家充分认识应用场景

几乎漏了，而这应该是最重要的一条，应用场景是什么，老板或项目负责人跟技术专家说，我们要做个什么什么，技术专家，哦，知道了，然后你认为这个沟通完成了？

事实上，很多问题都出现在这个环节上。

老板或项目负责人对一个产品的理解，是基于可能很长时间的观察，测试，使用，分析，所形成的理解，并且对很多细节和特点已经有了非常深入的认识。

而技术专家，可能只是听说过这个产品，甚至老板交代后去搜了一下这个产品，然后基于第一眼的印象和概念，形成了一个非常粗糙甚至是错误的认识，然后，他去做技术选型和技术规划了！！！

背景信息的一致性是非常重要的，也是产品和技术沟通中最容易犯的错误，产品以为自己都说清楚了，而技术以为自己都听清楚了，但是双方的理解并不一致！ 因为产品忽略了交代背景，而技术通过脑补还原了背景，你确定他脑补的和你认为的是一致的？

交代目的，交代背景，交代应用场景，要不厌其烦，并尽可能要求对方按照自己理解重述完整逻辑（这需要一点沟通技巧，并不是真的不尊重对方），才能确认这个沟通过程ok。