离职京东的自我总结

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/u014408411/article/details/52299162

2016.6.30   对于搬砖这个操作 我只能说  我不是很合适,加上各种原因吧  去了达达  

                    新的环境还算不错,由于基础技术比较薄弱,之后的一年,希望各方面的完善下自己

                    首先要做的肯定是总结下之前的面试题,自己也留个纪念

                     明年的这个时间再看 也许就会深深的感觉自己的渺小了吧

                     

                     学习是个枯燥的过程,为了家人,努力吧  

 

展开阅读全文

离职了,总结的一些系统分析的经验

09-26

[size=14px] 刚在一家公司离职,这是一家刚在境外上市的公司。因为公司上市后规模迅速状大,急于开发几款战略产品支承,公司高层对我们之前进行的一个项目非常重视,投入巨大。系统开发之初需求原本很明确,但新的需求总是在开发的过程中不断地被提出,今天来了个推广部经理,明天来了个市场部总监,各有各的想法,并且各个部门、分公司经常找开发小组开会提出新的需求变更。由于项目经理的“软弱”,我们一般很难拘绝。因为老总总是要先看到做出的效果再提意见,所以项目做的很急,系统框架在刚开始设计时没有被充分讨论、简化,感觉在后续开发中遇到很多问题,rnrn 现已离职,也无所顾忌,特谈一谈对系统分析的看法,总结一下之前的工作的经验,有不当之处请指正。rnrn 做需求分析,我觉得最重要的任务是简化业务流程、规则、逻辑;丰富用户体验;rnrn 0. 尽量将复杂的用户需求抽像成最简单的业务规则、数据库结构来实现。因为需求是不可能一下子就确定的,假设我们刚开始对核心需求的实现方式增加了一点点的复杂性,比如说多加了一个表,一个藕合字段,那么对于以后的扩展我们就有可能要去制定更加复杂的规则去适应,从而“被逼”消耗更多的工作,使用更加复杂的结构和业务规则。尤其当需求发生不断变化时,改变这种体系所要花费的代价也会随之几何级上升(因为一般是不可逆的),用户的可操作性也会随之越低,并增加了其使用上的难度,从而不得不对其进行培训。rnrn 1. 对于一个面向公共(大用户群、非公司内部系统)的系统,要充分进行“二八“划分;一个系统不可能满足所有人的需求;要关注最广大的80%的用户,因为另外20%的需求很可能会使另外的80%的人产生困扰;一般人最容易记得7个字以内的句子,同样大部分软件只有20%的功能是经常使用到的,对于互联网公众平台来讲对另外不常用的80%需求的“重视”,只会分散开发人员的注意力,使用户体验、易用性、可操作性下降,并增加系统复杂性、维护和运营成本;因此要将主要精力放到那20%功能的开发上。rnrn 2. 对于核心产品,业务规则和逻辑的设计万不可草率,并且不要集中由“一类”人去做;要从全局的角度制定业务流程,最好一开始就将最终使用和开发者纳入业务流程、规则、逻辑设计队伍。并充分讨论精简后完成产品的整体构架设计,然后进入编码阶段。综合考量成本/效果的比例,舍弃对系统可能产生混乱的设计,并想办法最寻找简单的替代方案。而且尽可能一开始就确定数据库的主体框架,而非去制定每一步的细节。rnrn 3. 对于功能宠大、业务复杂的系统,我认为用户需求接受比在 5:3:2 左右是正常的, 相当于10条需求中有5条可以完全接受的,有3条需要将实现方式略加改变而达目的,但一般有1~2条无法实现是正常的,因为可能会对系统造成较大的复杂性或不利于扩展,而且很有可能跟现有系统的功能产生冲突。不利于系统结构最简化,增加系统运营成本的不可控风险。rnrn 4. 当公司的主打产品经历过数次功能扩展、升级后,而造成的构架复杂性、数据库负载、稳定定、可操作性和用户友好度下降达到一定程度时,就应该考虑将关联性不大的功能分离成相对独立的几个系统,只进行核心数据表进行共享,以此增强各个分系统的可重用和可靠性性。从而避免只向一个大型系统输出复杂性,造成可靠性下降,以及维护、运营成本的上升。[/size] 论坛

没有更多推荐了,返回首页