我们的项目开始立项的时候，最常见的一个情况就是：几个人的小团队，一开始什么也不做，就开始写代码，验证逻辑，游戏就开始写起来了。而公司的一些所谓的领导层面一开始就把游戏定义为我们要做一个大作。这个事情本身就是一个笑话，因为没有任何的规划和设计，我们就妄图写出一个杰出的作品出来是不现实的。Unity 在好用，那么以这个心态去做游戏，一定会写不出来好的游戏来。— 刘钢《Unity 项目架构设计与开发管理》
以上这段话说得很清楚了，就是做一个项目的时候一定要做规划和设计，当然这是从整个项目的角度来看，但作为开发者，对我们来说就要从技术上进行规划和设计，而技术上的规划和设计其实就是要做架构。
架构要做什么？
在项目的初期，我们直接把架构理解为准备即可。我们仔细回忆一下在一个项目的准备阶段，我们都会做什么？
笔者一般是先分析需求，需求分析清楚了，就会对需求进行模块拆分，拆分之后就会去逐个验证技术难点,这时候会选择一些插件等等。等验证完毕就算是准备完毕了。
当然这一系列操作是笔者主动意识下完成的，但是其实还有很多习惯性的操作，比如用 QFramework、用公司的代码规范。
这就是笔者的准备阶段做的事情了。当然项目不是笔者一个人做的，而是有多个人做，而笔者的模块拆分阶段就已经可以把项目的工作量进行拆分了，而团队成员都是按照模块进行分工的。
这就是笔者一般做一个项目的时候做的准备，也就是架构，也就是规划和设计。很普通的事情，可能大家都在做。
但是仔细分析每一个操作，它背后都有很多故事和原因的。
比如一开始分析需求，这个习惯，都是被迫养成的，因为如果一开始不清楚需求就开工，那么就会导致对项目开发的走向判断错误，走向判断错误，那么当项目扩张的时候就会手足无措，体验非常差，而需求不清楚的话，在做项目的时候就会感到有力使不出，很难受的。作为一个开发者，虽然本职工作不是做产品或策划，但是把业务需求理解清楚，会对项目的理解会更加深刻，而如果知道了每个业务需求背后的原因，自己做项目的心态都会变得不一样。但是主动去理解需求是很多开发者不屑于去做的。不过我们可以好好算一笔账，假如在非常清楚需求的前提下，去完成这些需求要花三周的时间，但是在对需求模棱两可的前提下，去完成这些需求可能要花四周的时间。多出一周的原因，是因为需求模糊所造成的多余的工作量。而把需求理解清楚，很简单，一张纸一支笔花两个小时，就清楚了。
当然以上这些情况是适用于开发流程比较成熟的公司，比如策划提前两个月就把需求明确好了，美术提前一个月就把美术资源搞好了，而开发者到手的资源和需求全部都是完整的不需要排查的。
但是市面上大部分公司做不到以上的流程，真实情况下，都是美术开发策划同时开工的，策划都没想清楚就给了需求，给的需求往往都是非常模糊的，美术给的资源都要排查一次，这样就导致开发者会多出很多工作量。
但是在这种情况下，更是要理解清楚需求。策划自己都不清楚的需求，开发者要理解清楚，没错。开发者要想理解清楚需求，就要帮助策划理清思路，也就是策划要和开发多沟通，要理解策划在做游戏设计的时候在考虑什么事情。
当然以上单对很多人来说都很难，因为太在乎面子，太在乎尊严，瞧不起策划等等。一个项目好好做也是做，不好好做也是做，为什么不好好做呢？同样都是花自己的时间，如果不好好做那岂不是浪费了这段时间？
而一个开发者，最好是在最初就要有一颗积极的心态，什么叫积极的心态，就是为了做好项目，可以不在乎尊严，不在乎面子，而是一心想做好它，为了项目可以在争执的时候选择妥协，因为决定一个开发者价值的是项目，而不是尊严和面子。比如，到另一家公司去求职，你不能说这个项目是因为策划 SB 才做成这样的，而要说这个项目是我做的。
好了，说得有点远了。总之，笔者只是想说，理解业务，分析需求是架构的第一件要做的事情。而做好项目是架构的最终目的。
OK，其实还有一种情况没有讲完，这种情况是大多数开发者遇到的，就是项目已经开始了，但是需求还是很模糊，这时候，对开发者的要求会比较高，这时候大家只要记住一点就好，要容忍当前项目的不完美，记住这一点，项目的配置就算是最低，在最艰难的环境下都有机会绝处逢生。但是如果容忍不了当前的不完美，比如策划需求不清楚，老子就不干了，这样项目，那最终只会造成项目的 Delay，对自己对公司都不是啥好事。我们要做的就是，策划需求不清楚，OK，找它聊去，总归能聊明白的，聊完策划也明白，自己也明白。如果还是不能完全明白，也没关系，最起码对需求的理解程度有所改善，这样也是好的。