架构师之路道阻且长

最近接手了一个小项目，经历了长时间的兵荒马乱后，终于上线，因此趁着今天有时间，把一些感触和经验写出来。

写程序写好了，就能成为架构师？全栈程序员就能当架构师？事实并不如此。一个架构师和程序员之间差的不仅仅是多少行的代码，更是思考能力，控制能力以及对技术，开发周期的精准掌控。下面将我在架构项目时遇到的问题进行逐一描述。

A,需求与周期

需求是用户核验程序时要参考的最重要指标，因此自开发之初和客户核对好需求至关重要。而这一部分恰好是由程序员转做架构师往往忽略的一点。我们要了解到的是需求不仅仅只是一个用户核验程序的标准，同时也是我们在开发中要参考的绝对标准。没有详细的需求，何谈技术实现？没有技术选型，何谈项目规划？连规划都没有，又何谈开发周期？因此即使在客户迫切地询问开发周期的情况下，我们也要谨慎地对需求进行分析，对技术可行性进行分析，的进行规划，提出明确的周期。

总结，核对需求的三个原因：

（1）保证在进入开发过程中，不会因需求的修改不断地对程序进行大范围的整改；

（2）根据具体的需求，确定正确的开发周期，以避免拖延工期的情况；

（3）在项目交接时，不会因为甲乙双方在需求的不明确，导致不愉快的争执以及项目的返工；

需求明确到哪个部分，才算是到位？

这个其实是个很重要的问题，不过可惜的是学校老师讲需求的时候，我也记不得在编写什么代码，亡羊补牢，希望为时不晚。

现在就以用户登录为例，对需求中可能涉及到的问题进行简单的分析

先说几个简单的记录版本信息的部分，需求文档的类型，需求文档的版本，攥写人。如果客户中间提出需求，不要进行口头上的允诺。所有的需求的更改都需要记录在不同版本的需求文档中，这既是对客户权益的保证，也是对开发者权益的保证。花费个十分钟时间修改文档不会对项目的开发有任何的影响

在基本的需求版本确立之后，我们要考虑哪些问题呢？

举例：

用户在登录的时候，需要提供哪些凭证呢？用户名？手机号？

（要想想，一旦中途用户更改凭证，对于一个MVC的项目，需要修改的不仅仅是SQL，参数，还有前端页面，甚至是逻辑）

用户在登录时，是否需要验证码?何种形式的验证码？简单的数字，还是文字或者更多数字和文字组合？

（不同的验证码需要对应不同的代码实现）

用户在登录的时候对安全性有什么要求吗?同一时间，一个账号是否只允许一个用户登录？

（如果对安全性有要求，那么我们就需要考虑在传输数据时进行加密）

用户对界面有什么要求吗

再来一些更小的问题，是否点击enter直接就可以触发submit按钮？

（确实，问题很小，但是如果这些问题在交工时被提出，所有的小问题集合在一块儿，也会导致花费一段时间修改这些不能称之为bug的bug）

B,技术选型和问题解决

再来谈谈技术选型和问题解决。无论是企业级的应用或者是个人应用，技术选型上主要考虑一下几个方面：

用户要求的周期

团队中人员所熟知的领域

选择技术的社区和文档

技术是否稳定，安全，有无重大漏洞