作为一名架构师，如何才能名正言顺的搞垮一家公司呢？
今天就在这里跟大家分享13个小窍门，希望能够帮到你。
1、开发语言选择。一定要选择非热门的语言，像Python、Java、C++、C#这种语言太普通了，谁都在用，无法体现你的技术实力有多强，要用就要用冷门，高大上的语言，越少人用越好，比如像什么Perl、Ruby、Erlang，搭配着用，一套系统用它3,4个语言来开发，它可以帮助你大大提高招聘难度，用人成本，还可以帮助老员工长期留下来。
2、制定规范。不要搞什么标准，规范，让大家自由发挥，自己定义接口规则，代码风格，像偏底层的一些工具类，让每个团队自己写自己的，这样才能锻炼团队成员，发挥每一个人的创造力，让大家获得满满的成就感。
3、敏捷开发，效率至上。什么需求文档，设计文档，统统砍掉，能省就省，全都通过口口相传，一边理解需求，一边设计程序，一边开发代码，一边测试，这样才能用最短的时间满足业务的需求，抢占市场。
4、微服务。现在都流行微服务，不管多小的系统，都要拆分微服务，这样才能显得高大上，跟上时代的潮流。记住，日志每个服务自己打自己的，不要统一采集管理，这样才能在出现问题的时候，让排查难度达到最大。
5、多用开源中间件。不管功能大小，多上开源中间件，这样才能帮助团队学习更多的知识。像搜索功能，上ES；并发过百，上队列，解耦；要报表，上Hadoop、Spark，Flink，数据大屏，把大数据整套解决方案都上了，能多复杂就多复杂。至于后续运维的事情，反正有运维去搞，先上了再说。
Ps：如果运维就是开发，那就更刺激······
6、核心公共模块。核心公共模块不用花太多的时间去思考和设计，能用就行，像什么支付模块，不用考虑并发问题，像什么金额的脏读，脏写，多服务数据不一致问题，一般不容易遇到，等遇到了再想办法解决就好，总体来说问题不大。
7、增加依赖。服务与服务之间尽量做到多重依赖，交错复杂，最好能够实现环形调用，A调用B，B调用C，C再调用A，只要一个环节出现问题，那整个就会崩溃，大大降低了系统的可靠性。
8、数据库设计。数据库字段命名，一定要用拼音首字母简写，大家从小就开始学拼音，一看就懂。数据库尽量设计成单点，搞多了既浪费又麻烦，还要配置同步，单台一样也是用，数据库哪有那么容易出问题。同时，一定不要做备份，公司如果要求备份，那就备份在本机上，这样只要磁盘坏了，公司也就差不多完蛋了，一步到位，奥利给。
9、相信开发人员。要无条件的相信开发成员的设计方案和代码质量，架构师不做不相信团队的事情，相信他们，让他们体会到被人尊敬和信任的快乐。
10、监控预警。像监控这种功能，只要服务正常，一般都没什么用，自己写的代码，怎么可能不正常，没必要去做这个东西，一旦你做了它，当问题出现的时候就会过早的暴露出来，老板就会逼迫你赶紧修复，这样就很难将事故发扬光大。
11、测试方案。没有必要关注测试方案，咱们要相信测试人员能够把各种极端情况、边缘条件考虑进去，像性能测试这种，完全没有必要做，等上线以后让真实的用户来压测就好了，这样才能得出最真实的效果，自己压没啥意义。就像最近某城市的健康码一样，真实用户压测，效果杠杠的。
12、系统部署方案。在设计系统的部署方案时，应用一定要做成单点，只有做成单点，才能节约成本，才会在发生故障的时候，影响全局，没那么快恢复，最终引起用户投诉。
13、不做回滚方案。系统上线不要做老版本的备份，全凭运气发布，运气好则发布成功，运气不好马上改，改了接着发，只要熬得了夜，没有解决不了的问题，有时候不逼自己一把，都不知道自己有多牛。
吾日三省吾身，早上垮了吗？中午垮了吗？晚上垮了吗？
最后，祝所有架构师们，“新的一年，裁猿滚滚”。
静坐常思己过，闲谈莫论人非。
Hello，我是晓晓軍，
一枚不善言辞，沉默寡言，刚正不阿，亭亭玉立的约德尔程序猿。
都看到这里了，看官不关注一下嘛！
