开始项目的思考结构

开始项目的思考结构

开始项目我个人非常重视几个基本的流程,在这里和大家分享
业务逻辑,草图,ddd设计和UML图,这4种工具是互相连接,相互帮助的。如果能让团队中的程序员理解与体会这些工具,相信你将可以很有节奏的控制项目,掌握项目的可变性!  

 

主题 “开始一个项目的思考结构思考”中的结构说的太抽象,这里的场景是在开始一个项目时如何去思考内部结构,让团队有一个完善结构图,共同语言等。相信在多人管理下需要让大家同时同步,这不简单啊~

 

在开始的前提需求已经确定了,现在我们开始设计拼凑结构吧。

万物的开始我们必须对项目有所了解,这里称为“业务逻辑”,了解业务通常被认为是项目经理的事,如果你认同你可能是个码农,你的工作就是依照项目经理给你的工作,你工作就是完成就对啦。
所谓“知其然,知其所以然”,在编写代码在不知情的情况下完成代码,这代码的扩展能力决定是有限的,扩展的范围往往都是自己认知的范围。

 

为什么业务逻辑这么重要,一个程序员如果了解了业务逻辑,就能在设计对象时很好的去设计模块,如果是接到要编辑的模块,也能知道自己的模块是和哪个模块相关,在依赖模块还没做好之前,就有了准备,这是其一的好处。

其二,在编辑模块时,你可以判断是不是“过渡设计”,这句说怎讲?
过渡设计和随便设计很容易理解吧,但是要找出平衡是需要经验的。在不了解业务逻辑,就会知道这底线在哪里?在不了解项目同时你又是个勤劳的程序员,你就会永无止境的开多个接口。这行为可以确保开发的模块不会需要再改,不会有要添加的接口!可是……你会有做不完的工作,而且太多的接口,代码管理需要很强的等级才能编辑出来,息息相关的对象又要一直重构,看你不死!有些人有时间,一直拼命加班去完成,遇到这样的程序员,我会建议他花时间去了解业务逻辑,把剩下的时间去学习更有价值的东西。

 

好的,说完业务逻辑的重要,接着就是ddd设计模式,ddd这里是业务设计。这并不容易(没有东西是容易的啦),要了解ddd设计之前必须必备业务逻辑,那业务逻辑怎么加强?怎么快速理解?
嗨~我能说的是:没有捷径,只有融入线下业务,泡在业务里面才能很好的吸收这项目的逻辑。给大家说个故事:我以前都是看表面为业务拟定项目操作,结果顾客最后不能适应,最后放着不用…… 这行为我之前都一直认为是顾客不配合,不去了解我为什么这么设计,最后我体会了一句经典的话“去改变他人的思想,不如改变去适应他”。使用你软件的用户不是每个都和你一样聪明的,即使你的操作流程比他目前线下的操作好许多,但他们就是没法适应,因为他们操作时是用多年累积的潜意识完成,一旦有人破坏了他们长久建立的潜意识,你知道后果咯!

 

ddd业务设计强调有充足的业务逻辑,有人认为应该花项目中的10%~20%去了解业务逻辑,但我认为你千万不要看的那么简单,因为后果会非常可怕,这里我就不多说为什么~ 我给个场景:如果花不多时间去了解业务,业务会出现漏洞,这时这里就放了个“炸弹”,同样的问题会一直重复,到处都是炸弹!当你在开始编写代码遇到问题或其他程序员问起你问题时,你就是点燃炸弹的人!叭叭叭~
你花10%~20%制作的结构就这样被你的炸弹给摧毁了!也许你是补丁高手,那你就继续补,让项目恶性循环吧~

我的经验是编写代码不花大部分的时间,而大部分的时间都花在没用的“重构”,“重做”,“debug”和“添加修改功能”。编写代码是一门内功,外功再好也不能胜过内功,只要需求确定(业务逻辑稳定)就能很顺的编写与分工!我是从工厂出来的操作员,以前都是看了很多很多重做,而重做的原因大部分都是人为,能在工厂工作的人对工作的热情有限,对工作就马马虎虎,结果制作的产品就有缺陷,到了检验的部门就被打回重做,恶性循环~

 

在完全了解业务逻辑后,接下来就是开始wireframe

草图!这东西要开发的好可以去看看我上一篇的mockplus。草图目的是为了和你的顾客有个沟通的桥梁,这样就能避免太多的误差。草图也是让顾客细节化他们口述的想法,让口述变成画面,顾客会非常喜欢这样的服务(相信大家已经·这么做)。如果你能在草图细节化,恭喜你!你绝对可以省下大部分的成本(在未来)!

草图也有遇到很多的问题,比如顾客的要求会导致草图撑爆,不能持续维护~ 奇怪?为什么会有这现象?通常不可能啊?这看你的业务和工具,好的草图可以挖掘顾客遗漏的细节。一般的问题发现都是在用户操作项目时遇到的,等到用户操作已经是完成项目的时候了……好的草图可以很具体的模拟用户操作,让用户操作中提前把漏掉的操作告诉你,这不就是剩下未来的时间!你看多么棒!

可是草图不就是一张纸,没有操作,又怎么又更多细节?对!但是mockplus 不只是这么简单哦!

 

完成了草图,这回就是设计UML 图了,这图彻底表达了对象与对象的关系,你也可以了解业务与业务之间的关系。这里有一对多,多对多,继承,complex,属性等

设计这UML主要是可以和程序员沟通,通过这UML可以完成所有对象的调用,要完成这UML也不容易(天下没有容易的事)

 

UML图是ddd设计和业务设计的结合,了解ddd的人都知道ddd包括业务逻辑。这里我再强调一下,好的UML是可以预判在调用的场景,调用指的是在前台或后台使用对象的语法。好的调用就是用脑袋中的业务了解去分析怎么调用,比如:我需要动物类中的狗的尾巴长度,结果:animal.dog.tail ,就这么简单的调用。好的调用可以省去程序员的时间,让项目可以更快的完成!

UML还有另一个让人讨厌的事,就是匿名。在名词上要想出好的名词给对象可是苦差事啊~我的英文不好,词穷啊~ 如果你问我有什么好方法解决匿名问题,我绝对不会回答你的问题!跳~

 

总结:这过程虽然看似复杂,但能够一一具备我也不是一两年就搞定的,一切皆是平衡。设计项目过程毕竟不是一般的程序员能完成的,但是具备这条件绝对对你个人发展有着很大的帮助,让你成为一个更有价值的程序员。

 

相关博客