写这个系列，是一个枯燥的的过程。阅读这个系列也并不好受。因为它会翻开自己的烂账，戳中痛处… 它是一篇技术文章也是一段代码人生。
一、普通程序员的困惑
到今天为止，是我从事Android研发工作的4.11年，在IT老兵面前，我是一个菜鸟，在互联网特别是移动设备短暂的历史中，我是一个兵痞。
大专毕业，资历平平，没有进过大厂，但从未停止过对技术的追求，辗转于小公司，担任过Java工程师、web工程师但我始终坚信我是一名Android工程师，一直以来由于公司的性质，我只能以项目进度为主、以产品需求为主。看见新鲜的东西立马学习，但基本上没有用武之地，内存优化、电量优化、低端机适配、IO流优化等等。六大设计原则、21项设计模式、组件化等等都只是在自己的生活中狂舞，无关痛痒，不知对错。
算法反复的学习，到头来发现没有使用的地方，学了忘忘了学，我不知道还能在这种环境中坚持多久…
薪资也在一个固定区间来回摇摆，因为一个工作4年工作经验的人来说，原则上没有做不出来的需求，所以公司不缺这种人，因为三年的人也可以，同样能完成工作且价格不等的时候工作经验就变的不在抢手...
二、保证正确的研发方式
从刚开始工作，引我进门的老师就讲:
一个需求是百分之90的设计和思考加百分之10的手速来完成的
是的，这是在软件行业中大家都应该遵守的规则，只有好的设计和思想才能做出更好的东西。假设一边思考一边敲代，那代码的扩展性、复用性很难保持，长此以往，面对需求就不知道怎么去设计、去思考，就是一顿操作，虽然能呈现在手机上，但是扩展性复用性几乎为0，长此以往就形成了恶性循环，当有人找你评估一个需求需要多长时间完成时，根本给不出准确的时间。即使给出了也是错误百出。 那应该怎样去提升自己在设计这方面的能力，让我们在这么多程序员中脱颖而出，当然，这肯定不是简单的使用系统的API、SDK以及熟读它的原理这么简单。任何一个善于使用互联网的人都可以站在别人的肩膀上完成程序员的基本要求，但有的东西不行。
2.1 首先我们要有正确的研发方式：
正确的研发方式？你在教我做事？ 哈哈 ，很多人在面对一个需求时绝对是立马开始了工作，马不停蹄
要从不同的角度去研究自己，优秀的编写习惯、对应编写语言的特性、缺点避免，思考清楚设计的方式。
这样总结，感觉太过马虎。10年程序员的目标无非就是PM、架构师。前者趋于管理，后者仍在一线。一般大厂都设有架构师的岗位，架构师在互联网行业中也属于顶级之一的存在了，他们的研发习惯和格局可以进行探索，用于研发中。
2.1.1 架构师
系统架构师是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。因此他/她应该是特定的开发平台、语言、工具的大师，对常见应用场景能给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。 系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高，开发容易，维护方便，升级简单等。 --来源百度
相信大家都知道架构师这一名词且在为之奋斗，那大家有没有思考过以下问题：
2.1.1.1 架构的价值
架构的价值是体现在两个方面的，一是他的行为价值，二是他的架构价值，之前认为架构师的存在就是让代码更好更规范的开发，使之扩展性很强，如果公司有了架构师，我就能学会更好的设计，提升自己的开发实力了。
然而当我真正去了解架构师这一指责岗位时发现，之前的只以技术层面思考问题的方式非常可笑，一个保持不了正常收入或者长期盈亏的产品，凭什么让老板持续买单。
到我读到《架构整洁之道》一书中的一个例子，让我明白了公司的难言之隐和程序员的价值所在。 这种情况我们大家肯定是遇到过的，并且非常大的可能是现在的公司正在经历。
例子： 公司的某一个产品经历一段时间后，不仅是研发团队的规模、投出的成本、生产的效益都会增加，这是一个公司壮大的表现，在我们研发眼中是可喜可贺的，但是每行代码的成本、每个版本研发的生产力以及公司角度每个产品版本所需要支付的工资都是非常庞大的消耗， 准备：
- 早期工程师人数和主要版本
可以很明显的看到，当然数据有夸大成分，但是能形容问题，很多公司的产品，在经历融资扩张之后都会在后面的版本上对研发人员进行扩张，这样看起来确实没有问题，对于我们研发来说也是公司发展变强的标志。
- 同期生产效率 每版本需要的代码行数
这个图我们很容易发现问题所在，随着公司的发展能看到工程师人数的增长很快，但是发布的每个版本的代码量在一定程度之后很难推进，这个原因来自两个方面
- 产品拿不出新的东西，但是公司有继续扩大的需求
- 软件的架构太差，推进版本所需的时间在发布版本面前效率甚微，这个时候，应该思考为什么了
那对于我们程序员来说，需不需要关注这些数据呢？毕竟这不是我们应该管的事，当然，我们不应该管这些烂事.
项目的成功与否与其对应的人员组织架构有很大的关系，往往项目的失败就是有一群不明事理、思想腐败的人员组织导致的
但是得对自己的未来负责、对自己的薪水负责，所以应该思考这些问题和我们之间的关系，确保自己有能力在鲜明组织架构的组织带领下，发挥自己的价值，为自己带来收益。
- 每行代码的变更成本
随着版本后移，公司投入的人力成本等均下来会发现后面的版本所需要的钱越来越多，此时，我感受到了资本家的艰辛和创业的不易
- 研发生产力和产品版本
在公司股东眼里我们研发的生产力变的非常差，而我们会变得越来越忙
人员越多，但是生产力越来越低，第一个版本用三个月，从0到1，然而后续的版本成本越来越大，投入和产出严重不符
形成上述问题的原因很多，但从代码增面来讲，肯定是代码的架构出现了问题，变成了一座屎山。
而架构师的存在就是为了解决上述的问题，这就是他存在的价值。
- 世上的第一个架构师是哪里来的？
世上本没有架构师，敲代码的人多了便有了架构师。
从20世纪开始有程序时；从可读写设备出现的时候，有人将I/O操作与特定代码绑定在一起的时候；当出现麦金塔、出现windows、出现liunx、出现可挂载硬盘时，架构师就出现了。
他们将I/O的读写与设备无关；将研发语言和平台无关；将长期的实战经验抽取成模式…
他们的存在是互联网长河中璀璨的星光，是宝贵的精神财富，因为他们，程序才会被叫为软件，因为足够多的扩展，使得程序很“软”。
他们是经久不衰的，一层层的从业者更替，创造出了更大的价值。他来自你、来自我。来自无数个使用键盘和依靠思想的伟大的程序员们。
2.1.1.2 来自你、来自我？
笑话，我从来没有感觉自己能成为一个架构师… 我从从业开始到现在，一行行的代码，一个个的模块，到开始使用设计模式、开始使用各项原则、开始关注扩展性、维护性、开始思考怎么开发容易、升级简单、怎么编译更快，开始思考三方SDK在事故中快速替换…
等等，翻到上面看看百度给出的架构师的定义。我，我竟然在做架构师才能做的事，一行热泪…
虽然在做他们的事，但是我为什么还是一个程序员而不是一个架构师，究其原因。是我使用的不够成熟、使用的不够规范又不够灵活。从小的功能看不到大局观，所以需要更深层次的学习，学习各种技能。
2.1.1.3 什么时候成为一个架构师呢？
是不是以为架构师是高高在上，从不参与一线的人，答案不是的，架构师一定是在一线工作的员工，只有切身体验研发的艰难，才能发现架构的问题，想成为架构师，需要过硬的专业素质，良好的设计理念、大局观等。任何架构师都是从程序员过来的，没有人突然之间成为一个架构师。
让架构行为伴随研发
2.1.1.4 架构师的价值和程序员的价值是否一致
通过上面的了解，清楚了架构师的价值和职责，那他们和程序员一样吗？他们的薪水很高，做的事可能很少，但是他们和普通程序员的价值是一致的
人们在赞叹天安门宏伟设计同时，也在赞叹劳动人民的伟大
所以我们的价值是一致的，一个好的架构需要灵魂主导，也需要处处细琢，需要优秀的程序员去完善。
并且一个软件的架构不是从一开始就进行奠定的，因为谁都不知道软件的方向在未来不会发生变化，所以优秀的架构也是随着业务的发展进行不断的扩张和设计。
《架构整洁之道》中对软件架构给出了非常多的建议，比如说，希望设计的软件架构应该保证其独立性，要有清晰的边界、测略和层次，要有宏观的方向和微观的实现，需要保持良好的测试边界，高级别的软件设计应该不考虑具体的实现，在架构设计之初，可能会考虑到数据的增删改查，但是绝不会去设计到底使用关系型数据库还是映射型数据库。
这些在前期看不到的设计问题，只能依靠架构师丰富的经验去不断的调整适合自己业务的架构，而灵活的调整离不开因业务而变化的架构，更离不开每一个组件、每一行代码的实施。
看完这么多的问题，大家应该心里早有数了吧，
要成为架构师，必须从每一行代码，每一个组件开始，从微观开始，从每行代码的设计开始。
2.2 怎样让自己成为一名“架构师”
上面的论述已经很清楚了，要成为一名架构师，首先要做一名合格的程序员，要对自己敲过任意一行代码、一个组件负责到底，要做一个善于思考的程序员，所以我们可以从以下方面进行研究，提升自己。
2.2.1 从新了解自己的编程语言
- Java语言的编程范式
- Java字节码及字节码操作(了解字节码的操作和虚拟机指令有助于写出更好的代码)
2.2.2 熟练使用各项设计原则
- 单一指责原则
- 开闭原则
- 里氏替换原则
- 接口隔离原则
- 依赖反转原则
2.2.3 熟练使用各项设计模式
- 对于设计模式需要根据自己的需求场景对标使用
2.2.4 熟练掌握架构中组件的构建原则(比如Android中的组件)
- 怎样定义一个组件
- 组件聚合、耦合
- 怎么处理组件间的依赖关系
2.2.5 让自己的代码具有良好的扩展性、维护性
2.2.6 熟练使用“用例” 来设计我们的代码
2.2.7 把它用到研发中去
在此之前我们还需要做什么？
2.2.8 坚持每天学习对应语言的优秀写法
2.2.9 坚持每天学习对应领域的知识盲区
2.2.10 坚持每天阅读巨人的书籍
2.2.11 坚持每天的坚持
当然，这个系列不是让大家整天去思考怎么设计代码，怎么研究架构，架构的真正目的只有一个：
用最小的人力成本来满足构建和维护该系统的需求。让系统正常运行
一个好的程序员需要从公司的角度出发结合自身的实力为公司创造利益，用以保证自身利益和实现自我价值。应该怎么去创造利益，我们一起研究。
在这中间怎么均衡与平时研发的冲突，
- 保证完成需求
- 保证软件能够正常运行
- 利用艾森豪威尔矩阵原则（单独介绍）
三、研发中的架构后续的计划
从入门到今天，每一行代码都来自书籍，来自网络、来自网友，所以在希望有人和我一起共同完成这个系列，使之能在互联网的道路上指示明灯，我希望学习任何能提升自己的东西，我会讲2.2中提到的这几个点一个个学习，变成代码、变成Demo、变成我的编程习惯。 有希望参与该系列的可以直接发我邮箱billkp@yeah.net
以上所有的思考均受《架构整洁之道》一书 ，建议阅读
