项目的运作应该是有序的，而不是混乱的。细节取决于很多东西，比如UI中的字体颜色，RGB值可能只是R的一个参数，相差1。很难识别，如果用专业的工具测试，会被充分暴露。保证整个项目整体基调的一致性，是项目启动时应该整体考虑的事情！首先，项目从需求调研到签约，然后UI设计，给开发一个好的界面。我们拿到界面后首先要做的不是开始绘制界面。它会在我们绘制的任何地方。这样一来，我们就会失去对项目的控制能力。首先要做的是阅读需求文档和RP，把整个过程流起来，不是浪费时间，而是当务之急。只有熟悉了整个项目的业务模型和流程的运作，才能在后续中占据主动，而不是跟着项目走，或者至于UI设计，如果有时间用思维导图来组织一个需求的理解，也是要让自己知道整个项目在做什么，而不是为了开发而开发。了解清楚需求后，我们开始做的第一件事仍然不是搭建界面，而是思考项目的整体规划。架构这么大的idea先不说，plan是什么？***：整体工程设计模式，MVC、MVVM、MVP、Rout...二：整体工程模块划分：基础层、网络层、硬件层、公共层、管理层、逻辑层、资源层、配置层...第三：思考整个项目会用到哪些第三方库，最后使用cocopods导入第四：思考整个项目界面哪些可以共享，哪些View可以多处使用，哪些控件需要哪些需要封装，哪些需要动画处理等等。第五：总结整个项目使用的颜色，一般不超过五种，使用宏文件管理颜色配置文件，在Xode常用颜色管理面板中设置项目常用颜色值，然后使用XIB为了直接使用设置好的颜色，以免造成颜色混乱，iOS11在Assets中新增了颜色管理。构架并搭建好代码管理仓库第七：确认与后台的接口字段。如果后台标准化了，可以直接按照后台给的接口文档提前开发，同步绘制UI和逻辑！如何管理一个或多个项目？***：切片原则，不断分解细化项目功能，制定计划进度表。第二：主进程优先的原则，也就是一个项目中最核心的功能。这里所说的核心功能其实就是客户最关心的功能。这个函数使用频率很高，大部分的业务流程都在这个函数中。第三：基于静态制动原理，改变项目需求是必然的。频繁的需求变更直接反映了项目人员对需求的控制和计划能力。面对需求的变化，首先静下心来分析一下需求是否合理，有没有更好的解决方案，需求从上游换到下游需要多长时间才能转身，风险在哪里等等。第四：保持原则。对于项目的一个周期，必须有实时文档。需求的变更需要签订变更合同，而不是仅仅更改它。做出一个好的产品，却怀着一颗打磨产品的心，却被需要变更折磨着，程序员甚至在代码注释里骂客户骂公司，其实没什么好发泄的。第五：源头控制原则，所谓水往下流，从商务部-项目部-设计部-开发部-测试部环环相扣。不可能，一个完整的项目不能一成不变，运动要有原则，运动要有限制，需求是无底洞，范围要有限制。第六：沟通为主。无论哪个环节都需要更多的协调和沟通，因为需求在传递的过程中很可能会发生变化，就像一句话过了10个人之后的意思就会和原来的不一样甚至偏离原来的意思。严格沟通是最重要的部分！需求不同，项目规模不同，每个项目背后都有一个孕育的商业模式。不管是原创的还是模仿的，都可以从中学习，学习一种思维方式或者一个行业的思维，所以做项目不是为了做项目，也不仅仅是为了做项目而局限于某些项目。就像编程语言一样，不讨论PHP是不是世界上最好的语言，或者人生苦短，我用的是Python。用编程的思维，不同的编程语言只是语法上的不同而已。局限于某种语言，是对自己思维的局限。为了最好的政策！
