前几年在全民创业资本泡沫的繁荣下，互联网企业如雨后春笋般应运而生，市场对研发人员，架构师、技术管理人员的需求也变得非常迫切，技术人员的薪资也水涨船高，大厂的技术同学们按耐不住纷纷辞职投身了创业大潮。如今泡沫逐渐破灭，大浪汽车渐褪去，当初那些企业活下来的还有几个？据全球经济趋势商会2018年的一份调查报告显示，15年A轮的846家公司基本上无人生还。今年互联网企业的日子依然不好过，时常听到大量裁员的新闻，市场大环境变得非常严峻。大家可能会发现，企业面试力度变得越来越大，薪资似乎并不像前几年那样一路飘红了。
站在风口上，猪都可以飞起来。现在风停了，猪怎么办？
实际上有很多中小企业的架构师/总监/CTO是在风口上时投身创业的，其中不乏对技术有了解，但对企业、团队、成本、效率等关键点一无所知的人，其能力水平并不能达到其职位的水平。因为风来了，他们被吹到了力所不能及的位置，从而给企业带来了巨大且无形的投入和浪费。
初创企业相对而言资金短缺、人才匮乏、产品还未得到市场的检验，所以产品是否能够快速上线试错，是否能在钱还未烧完的情况下探索出活路来是每一个创业型企业考虑的头等大事。
这里的几个关键词分别是 —— 趋于正确的方向、快速落地的能力、知错能改的态度。虽然这几个关键词是说企业的，但技术也仍然适用。比如趋于正确的方向，说的是技术选型和架构设计。在企业初创阶段目标很简单，产品快速上线试错。这个阶段不会存在高并发，大数据，也不会遇到复杂深奥的技术难题，业务形态和逻辑也相对简单，因此一个简单、高效、成本低、可持续发展的技术和架构是比较靠谱的。简单是指技术复杂度相对较低，上手容易。高效是指开发效率高，这里不仅仅是编码快，还有现成的解决方案多，自动化成度高、除错快等。成本低是指市场上会的人比较多，人员成本较低，学习成本低。可持续发展是指它的未来可预期，且能够支撑公司未来的发展。
什么样的技术和架构是最适合的？
速度就是这个企业能否存活的重中之重。我们都说十个创业九个死是对创业维艰的真实写照。在如此艰难的生存环境下，活下来就成为了企业的核心目标。作为企业的技术人员，如何在本职工作上完成企业的目标呢？
在业务和产品没有经过市场的检验，没有跑通的情况下，作为技术人员就需要快速地开发产品并上线试错，然后根据市场的反馈和数据对产品快速地调整，然后不断地重复以上过程。对于初创企业，技术上不需要想那么多，高并发、分布式、集群什么的跟你没有半毛钱关系。而是把重点放在简单、快速、高效上。
近几年的面试中一些架构师告诉我他们做了服务化、做了集群、分库分表等等一系列技术性的工作，保证线上业务的稳定性，高可用性云云，当问到并发和日活时却傻了眼。因为有些产品还没上线公司先挂了，有些是产品上线了无人问津，然后公司钱烧完了，大家收拾收拾各回各家。这种“架构师”是不称职的，我将其归类为自嗨型技术人员（自己技术玩嗨了嘛）。要知道原本可以打胜的战役因为决策失误可以导致灰头土脸地失败。技术复杂度高直接导致的是产品规模变大，人员要求变高，资源需求变多，出错几率变大，时间周期变长。结果是招聘成本、人员成本、学习成本、开发成本、时间成本等等都大幅提升。你尽心尽力花了大把时间和人力做了一堆没用的技术产品，到头来却错过了产品上线时机，害死了东家，这就是所谓的过度设计。初创企业尚在探索时期，时间是挥霍不起的。所以初创型企业的架构师在技术选型和设计时主要考虑市场份额高且门槛低的技术，帮助企业大幅度降低成本，使企业快速找到方向并生存下来。
不成熟的技术人员一厢情愿地认为，做架构时要考虑性能、扩展性、灵活性、健壮性等等。就好像不考虑这些就没有技术含量似的。我想说明明是个自行车，却非要加装一个3.0T的发动机。明明地上跑的，却要装个翅膀想着飞。
初创企业怎样做技术选型？
简单说好招到人的技术就是适合初创企业的（技术研究型企业除外）。比如 Apache + PHP + MySQL 是比较好招人的，Java 体系来说 SpringMVC + Spring + MyBatis + MySQL 是一个好的选择。
怎样的技术架构是最适合初创企业的？
越简单越粗暴的架构就越适合初创企业。以 Java 举例，将所有业务逻辑放到单工程中开发，共通部分使用静态类的方式暴露，简单粗暴地利用SQL从数据库查数据，不考虑缓存，不过多考虑性能，尽可能少地使用第三方中间件。好处是线上维护简单，开发效率高。坏处是工程可维护性不高，代码混乱，性能差，不支持热升级等等。说到这里肯定有反对的声音，但当你了解了“最适合的架构就是最好的架构”和“好的架构不是设计出来的而是演进而来的”含义后，相信就能理解。
无论何时，活下来比什么都重要。
下一节：对于初创型企业来说时间和资金是最为稀缺的资源，对于架构师而言不要因为过度设计导致效率降低、投入增加。架构的目的是为了解决业务问题（本质上来讲是解决人的问题），合理且高效地解决当前和未来的问题，又能在不增加工作量、技术复杂度以及不过多资源投入的基础上为架构的演进保持适当的扩展性是架构师所要具备的基本素质。