EDITORIAL
Half of 2019 slip away, either parting sorrow, or grow the hard way, in the hearts of all hot.
An article on the distance has been a long time ... lazy blogger can not be attributed to me all this time, I am planning my work, only themselves to blame lazy ...... so-called learning is like rowing, fall behind, not forward to the end can only back.
Today, a number of insights about the architecture of the sudden, write recorded.
The starting point of the software architecture
Software architecture is a software system development life cycle in the forefront of the part, but also the most critical part of the core. It determines the direction of the follow-up code; can determine the direction of the project; sometimes able to determine a company's life and death. Success factors of software architecture, there are a lot of points, one or two of these points or more, the composition of the different levels of business user systems or systems:
* 1 reliability
* 2 security
* 3 Scalability
* 4 can be customized
5 * Scalability
* 6 maintainability
* 7 user experience
* 8 fast iterative
The right technology selection user-oriented systems, user experience, fast iteration, safe, reliable, essential to these four points, these points around the base, management, rules, procedures, will follow the corresponding weight assigned to different a.
A company needs to do if a tool app, xx calculator, notepad or xx. Want to gain market recognition, its architecture will need approximately: 30% of the user experience, fast iteration 20%, 10% reliable . According to this heavy weight assigned to manage technology selection, management and so on architecture. A security tool app to do invulnerable, is not recognized by the market; the security of an electricity supplier website does not guarantee the reliability, it will be abandoned by the market.
And if Company B has an internal management system, you want to correct results, we must first ensure rapid iteration of business are changing every day, instead of the user experience, scalable, secure, reliable, and can be relatively less urgent .
By fast iterative rapid iteration can be customized demand and scalability requirements to enhance the user experience, enhance the user experience to drive the growth of subscribers, then the reliability, maintainability, security, scalability, a higher Claim.
The above is what I want to express, the starting point of the software architecture, which is the market demand for project decisions. What needs are, what determines the architecture Yes.
Architecture is difficult to change. Yes, the architecture is very difficult to change, if your project has been put on the market, unless over again, bring to bear thorough reconstruction of pain. Here we tend to face more severe test, such as personnel handling: There are a lot of c ++ development, you want to transfer java, php or have a lot of development, want to turn python; another example of architecture is bound to have a fresh start overtime, work hard month when the road to go again ~
For chestnut: TDD, TDD essence of the process is to run through from requirements analysis, design, coding, testing, throughout the development process. In fact, it is demand-driven, individually satisfy every demand. TDD is that the core requirements analysis, design, quality control, quantitative process, you can avoid when writing test cases, remodeling, architectural design requirements. TDD is actually a demand-driven architecture model, development model.
Perhaps you are already doing related processing architecture, perhaps you have to eat some bitterness, this theory may help you realize that you want to develop an appropriate framework based on market demand, to derive the appropriate architectural details . Be careful. Neither can be over-designed, nor can design deficiencies, which the ruler is: the market demand.
Architecture people-oriented
架构设计必须要考虑人在其中的重要因素，合适的人做合适的事情。一个好的架构，首要的就是要考虑所在团队的人的情况，我们往往倾向于抓技术层架构，忽略了怎么将合适的人放到合适的位置，已有的团队人员能不能合理的在架构中发挥应该有的作用。
抽象的处理、框架的引进很重要的一点是，如何解决人员素质、想法、环境的不一致。框架通过封装复杂的东西，简化业务的复杂程度，让对应的人能够专注对应的事情。抽象通过可以被共同理解的概念，简化复杂的内部处理逻辑，将人的目标聚拢在一起。
软件架构应该以人为本，将最高效的人放在最高效的地方能够取得最大化的成果，架构设计也就必须考虑人的因素。
例如我们有一个5人团队做一个项目，团队成员比例大约是： 1个leader ， 2 个核心， 2个实习，在设计这个项目的架构的时候，你必须要考虑的是，如何设计能把2个核心成员的力量放在合适的地方，如何设计能让2个实习成员能够完成既定的任务。 假如将2个核心与2个实习放在一起看待，过不了多久会出现一个情况，核心成员感觉做的东西技术含量太低，实习成员可能感觉东西难、累、赶，长此以往，项目会频繁面临人员变更。
我们倾向于集中精力做技术层架构，而不是人员层架构方面工作的主要原因，不是因为技术更重要，而是因为技术更容易做。人际交往是很复杂的，并且就效果而言从来都不会是很明晰和清楚的，但是它们比工作的任何其他方面都更重要。写代码并非只是写代码而已，而是与人有关——需要理解的东西包括那些人是谁，他们能作出什么贡献和需要什么东西，以及是多数派还是少数派等，诸如此类。“如果你把架构重点放一部分在人员安排的身上，那么就会发生更好的事情。
从人的角度衍生出的信息的交互
信息的交互其实是软件开发过程中需要重点关注的事情。信息的完整性、真实性，影响着开发过程中风险的暴露。风险则决定了项目的成功与否，所以我认为它是架构其中的一部分，它常常被人忽略，因为它既不属于技术，也不属于人员，更像管理工作，但其实它也跟架构有明显的关系。
软件项目的风险无非体现在以下四个方面:需求、技术、成本和进度。任何信息的不对等都有可能导致需求完成有误、技术设计偏离、成本过大、进度延迟。怎么样规划合理的信息交互、制定合理的反馈机制是架构需要考虑的问题之一。
总结和感悟
架构的目的是贴合市场需求指定合理的技术规划、人员规划、信息交互规划，架构是不仅仅局限于技术层面的。一个软件架构师，你需要统筹全局，深入了解需求，了解业务的走向，了解技术的价值所在。也需要制定或迎合人员的搭配，制定信息交互的流程。
这是我现阶段比较深刻的感悟，执笔记录，也是最近吃的教训的结果。我的观点不一定正确，感谢大家观看，如有疑问，欢迎留言。