软件架构与项目管理的一些心得

前言

        做程序开发久了，日子就会很平淡，很烦躁，程序员就是一个很容易上脾气的职业。如果没有持续的学习，程序员的生命周期就会很短暂，什么35、45岁杂七杂八的。下面讲讲我这些年的心得吧。

         架构设计听起来高大上，各种牛逼的技术，什么6个9,9个9神马的（其实是产品稳定性的一种指标数据）。接触后就会发觉也就那样子，只是在某些方面更好的支持部分业务，比如高并发，高稳定性。但在其他方面可能就一般般，或者劣势，比如：价格或者数据安全性等。

        架构设计的原则是产品决定设计和技术，一切技术的根源就是开发产品，实现盈利。这就是为什么很多初创公司技术架构很low，加班严重（没有完整的开发体系，什么都要自己实现，当然云计算发展一定程度改变了现状），专注业务，但主要有盈利就能活下来，才会有厉害的架构设计等等。

1. 架构设计

         架构设计我初步总结几个方面，不是很全，仅是笔者日常生活的总结

         设计的目的

         设计是否全覆盖，是否闭环

         框架出现的必然

         标准化

1.1 设计的目的

         技术都是会快速更新换代的，技术也是很容易学会的，技术不是科学研究，仅被少数人掌握，所以我们都会过时，但技术设计不会，是一种经验的积累。技术设计的目的一定是为了业务需要，包括技术的选型，设计方案，框架的定制都是为了在业务的实现的过程，更加快速，更加简单，更加统一。

         日常生活中，经常听到什么产品思维，用户思维，其实一切的根源就是做产品，赚钱。因为很多时候，架构的重要性只会在业务量增大的时候才会在产品中体现出来，其实笔者在面试绿厂（手机厂），当时的架构师说过，在业务不复杂，并发量不高的时候，任何实现都不会有问题，都能很好的支持业务，只有在业务爆发式增长或者已经很大业务量的时候，才会体现架构的价值。业务量较小的时候，关键还是用户体验优先，当然用户体验什么时候都很重要。

1.2 设计必须考虑周全

         这点毋庸置疑，架构设计必须要考虑方方面面的场景，全覆盖，全链路，还要一定的超前设计，最重要的是可扩展。

         首先，架构设计其实就是方案设计，当前业务是什么，业务有哪些方面，业务将从哪些方面发展，业务链等等考虑。架构设计是闭环的，体现在产品上就是一个完整的生命周期。这也是ali要做全链路优化的目的，当业务达到一定程度，任何一个环节就不能是阻塞点，去中心化，可扩展。

         其次，架构设计必须考虑实现复杂度，要更高性价比的实现架构，支撑业务的开发。笔者架构能力也一般般，曾经做了一些简单的架构设计方案，感慨最深的是一些很好的架构在设计很不错，在实现的时候比较困难，或者难度比较大，或者性能比较低，就需要在某些设计妥协，并不是技术最新，设计很完美的架构就是好架构，而是最合适的架构。最合适的架构的一些特征：比如，适合当前的技术体系，贴近业务需要，业务方比较容易实现和较少的改动，有时还要考虑当前人员的技术体系。

         最后，架构选型，定制，就要比较合适的切合实际业务，选择好了，以后迭代就比较容易，定制就比较轻松。小业务量就考虑技术成本，大业务量就考虑多了，一般都会经过很多架构师与项目经理的讨论才能有比较实际的架构模式与框架的选型。

1.3 关于框架

         框架是公共业务组件，很多人认为框架是框架，业务是业务，其实也没错。框架就是业务发展到一定程度的产物，最开始是没有框架的，框架就是业务将一些公共业务抽取出来，定制成了框架。

         但是框架由于抽取了公共实现，那么在一些实现就会比较妙，比如设计模式，位运算等。框架不会经常修改，设计之初就要考虑稳定性，扩展性，性能等指标。其实看tomcat与spring的源码就可以发现，核心就是高效IO，算法，设计模式等。包括JVM GC收集器等就是设计的进步与环境的变化（大内存时代）。所以框架的演进跟环境变化（比如硬件发展，就不需要压榨内存了，典型案例的就是Android系统），业务需求息息相关。

         一般来说，开源组织如spring这些就做公用业务组件，一般的业务也够用了。而一些公司却有架构部，定制框架，很大程度上是为了满足公司自身业务的快速发展，架构的先进性在业务快速发展的时候就会有巨大的优越性。这些公司定制架构的目的是让业务开发人员只开发业务，无需关心框架，只需要设计应用架构就可以了。定制框架的目的就是让公司的业务分工，做框架的只做框架，只做部分基础件、中间件。好处很明显：框架有漏洞，框架组修复；框架要升级，框架组统一升级；框架要实现某项功能，框架组实现……业务仅仅就是升级框架版本号即可实现一系列的能力。

1.4 关于标准

         这个才是重点。一流企业做标准；二流企业用标准，定制标准；三流企业用产品。标准才是核心，也是技术壁垒，但是难度太大，难以统一，是博弈的结果。其实JDK就是一系列的标准的产物，比如JSR-xxx。经常框架对旧业务的兼容就是标准的变更，或者以前的业务标准不完备的结果。这个比较底层，笔者接触的也少，但重要性毋庸置疑，比如ARM就是一种芯片设计标准。

2. 关于管理

         笔者也没管理过，从来不是leader，不是很善于跟人打交道。也接触不少大BOSS，跟他们学会了不少东西，简单总结一下吧。

2.1 全局把控

         作为管理者需要全局把控项目，或者项目组。掌握项目的方方面面，从方案，选型，周期，生成，故障应对等。做到心里有数，至于写不写代码，其实无关紧要，手下一帮写代码的，已经无需亲自上阵了。但是要懂业务，精通技术，否则将帅无能，累死三军。

2.2 用人

         这是一门艺术，与人斗其乐无穷，分配人员，倚重人员，揣摩上级心思。笔者是不会的，哎。

2.3 沟通与推动

        部门之间永远都有部门墙，除非小公司，老板全权负责。这涉及到部门之间的利益，本质就是钱，出来工作大部分都是要养家糊口的，虽然经常谈理想，谈人生。这个时候就是管理发力的时候了，作为管理需要维护小团队的利益，同时要推动，拉动关联方的业务，做到的是共同获利，这需要管理者的威望，否则除非上级任务，业务是不能正常进行的。或者活成外包在别人手下讨生活，这就很苦逼。

总结

         笔者只是一个小喽喽，学学技术混混日子的，只是分享这些年的项目经验。尤其是最近的项目经验。也在为35岁而担忧，以后会持续跟进心得。发发牢骚，希望对大家有所帮助。