|
一个项目的运转应该是井然有序而非杂论无章，细节决定于很多东西，比如UI中的字体颜色，RGB值可能只是一个R的参数相差1，肉眼很难识别，而如果用到专业工具测试，那么就会暴露无遗，保证整个项目整体色调的一致是在项目开始启动时就应该全局考虑的事情！ 首先项目从需求调研到合同签订，接着UI设计好界面给到开发，我们拿到界面的第一件事并不就是要开始绘制界面，绘制到哪里就是哪里这样就失去了对项目的把控能力，首先要做的是先看需求文档和RP，将整个流程串流起来，这并不是浪费时间的事情，而是重中之重的事情，只有熟悉了整个项目的商业模式，流程运转，才能在后续占有主动权，而不是跟着项目或者UI设计的鼻子走，如果有时间使用思维导图整理一份对需求的理解也是很有必要的，让自己知道整个项目在做什么，而不是为了开发而开发。 对需求理解透后我们开始做的第一件事仍然不是搭建界面，而是思考工程的整体规划，我们不谈架构那么大的思路，规划什么呢？ 第一：整体工程设计模式，MVC，MVVM，MVP，Rout... 第二：整体工程模块划分：基础层,网络层，硬件层，公用层，管理层，逻辑层，资源层，配置层... 第三：思考整个项目会用到哪些第三方库，最好使用cocopods导入 第四：考虑整个项目界面有哪些是可以公用的，有哪些View是可以在很多位置使用的，哪些控件是需要封装的，哪些是要做动画处理的等等。 第五：归纳出整个项目使用的颜色，一般不会超过五种，使用宏文件管理好颜色配置文件，同时在Xode常用颜色管理面板设置好项目常用颜色值，后续使用XIB直接使用设置好的颜色，这样不会造成颜色混乱， iOS11在Assets.xcassets里面新增了一个颜色管理很方便使用，并且可以实现全局变换颜色，同时归纳出常用的字体大小等等... 第六：搭建好项目基础框架并建立好代码管理仓库 第七：和后台确认接口字段，如果后台规范，则可以直接根据后台给的接口文档进行先行开发，绘制UI和逻辑同步进行！ 如何管理好一个或多个项目? 第一：切片原则，将项目功能不断的进行分解和细化，制定计划进度表。 第二：主流程先行原则，也就是一个项目中最核心的功能，这里所说的最核心实则是客户最关心的功能，该功能使用频次高，大部分的业务流转都在此功能中。 第三： 以静制动原则，做项目需求变更是在所难免的，频繁的需求变更直接反应出项目人员对需求的把控能力及规划能力，面对需求的变更先静下来分析该需求是否合理，能否有更好的解决方案，如果变更了该需求从上流到下流会需要多少时间周转，风险在哪里等。 第四： 保留原则，对于项目的一个周期循环，要有实时的文档记录，需求的变更要签订变更合同，而不是说变就变，最后面目全非反倒无可追溯，很多程序员并不是不想做好一个产品，而是怀着一颗打磨产品的心却被变更的需求折磨的体无完肤，甚至出现程序员在代码注释中骂客户骂公司的行为，实则为无泄可发而为之。 第五: 控制源头原则，所谓水往下流，从商务部--项目部--设计部--开发部--测试部环环相扣，源头始于需求，牵一发而动全身，不动是不可能的，一个完整的项目不可能不动，动要有原则，有限制的动，需求是一个无底洞，必须限制范围。 第六: 沟通为主，无论哪一个环节都需要多协调沟通，因为需求在传递的过程中很可能会变味，就好比一句话传递10个人后意思会与原来的有所差异甚至偏离原意，严格来说沟通是最重要的一环！ 需求有轻重，项目有大小，每个项目的背后都有一个孕育的商业模式，无论是原创还是模仿，都可从中汲取经验，学习到一种思维亦或一个行业的思维，所以不为做项目而做项目，为做项目而不单局限于某种项目。就如编程语言一样，不要去讨论PHP是不是世界上最好的语言，还是人生苦短，我用Python。有了编程的思维，不同的编程语言只是语法不一样而已，局限于某种语言是对自己思维的限定，它们之所以存在必然有各自的优势，亦或解决某些特定的问题，而取长补短实为上上之策！
| 
收藏
淘帖
踩
