记小曼巴初次的设计心得

  公元2017-10-24,星期一,手机上还不断刷着知乎,嘴里搞着东西坐在那小工位上走着心呢,突然,"小忠,你过来,给你讲讲任务调度这块的一些业务重构的需求吧",还没缓过神儿,就被源哥叫到小黑板前开始上课了;

  "我们做个任务调度的功能吧,现在这个制单速度没有达到最大化,很多客户端不能同时进行制单,只能有一台机器能够自动制单,其它的只能人工手动制单,不行,这个得重新设计一下,重构吧。"老大简明下达了这次作战任务,接着就是他老人家的一些方案,大概进行了1个多小时,我们下课了,最后这次的设计老大交给了我,让我来设计这次的任务调度模块,其实我心里是非常接受的,因为这是我第一次设计,兴奋感一直在心头涌动着;老大也知道我是第一次,所以私下就不断给我灌输了很多他老人家的设计经验,说真的,这几天学到最好的也是嘱咐最多一句话:"小忠,设计不要局限在自己的那块,要跳出来,一定要跳出来,要掌控全局"。

  经过2天多的设计,我如愿以偿的交上了V1.0版的设计文档,周三下午;

  "源哥,设计文档发过去了,你有时间的话看一眼吧,哪些地方还需要改进",当时我还是有点自信的,因为很多逻辑我都想了一遍,突发情况也想好了相应的解决方案。

  10分钟,就10分钟,源哥叫我了,"小忠,你过来一下",我以为要给我说明天就开发吧;然而我错了,错的一塌糊涂,连毛都不剩;

  "小忠啊,我现在把你这个设计文档给其他人,其他人能快速定位到自己需要开发和重构的地方吗,好,不说这个,就你,你现在拿着这个文档去开发,你能列出个满意的计划给我吗?"因为我了解,老大质疑你的东西,那十有八九就是你做的不到位;

  接着,"好,先不说你这个设计方案是否可行,但是你这个入门的基本功首先就没学到位,你没用心,知道吗,你这个文档上处处标记着你没有用心",最后那几个字儿源哥还是拉着很长,然后说了好多这V1.0版本的毛病,这次是我第一次感觉从一次对话中学到了很多道理的时候。

  又经过3天多的调整,我终于将V1.1版的设计文档搞出来了啦,在周一早上就发出去了,但是这次我不是态度的问题,而真的是经验和格局的问题了。起初我是站在自己负责的那块来改造,针对自己的品牌进行了设计,是的不错确实对于我来说真的是一个完美的设计,但是我抛下了很多重要的业务分支,根本没有考虑过其他品牌是否符合你的设计,也没有和任何其他模块的开发者去沟通过,最终导致设计方案覆盖范围极小。"设计者,不要佩带着任何角色去设计,接着,源哥又给我从整个公司的用户下单开始,清晰的描述了整个业务链的运作,以及各个模块之间是如何配合工作的",听完这次的描述,我心里又有了一百种方案,真的,这就是所谓的人生格局越大,看到的景色越美的道理。

  以下是我这次总结的失败经验,给大家分享一下,如果有不对的地方,请各位也不要谩骂我误导大家,因为是第一次,如果有好的地方,也希望能够对各位有用。

    1、设计千万不要把自己局限在自己负责的那块和邻近了解的那块,一定要跳出来,掌控全局,了解整个业务链的运作,有胆量将自己设计的东西放在任何点来重构整个业务链。

    2、设计过程中在文档上做任何决定时,一定要遵循,先寻求现有的,后决定是否自己开发,然后将问题逐一抛给现有的和要开发的方案,进行对比,当然,这是需要全方面的对比,比如:成本、效率和扩展性等。

    3、设计过程中遇到或者别人抛出的问题,一定要记录(必要时刻直接写在设计文档中),这个也是我这次最轻视的地方,每次想到一个问题,经过一番讨论,就完事,也没有将问题记录下来,最后当有人第二次提出同样的问题时,我又开始当场思考,想解决方案,而且还远远不如第一次的。

    4、多沟通,一定要多沟通,厚着脸皮就算是扯淡也要跑着去了解一下有可能涉及到的模块业务,因为就算是扯淡也不至于到最后让你后悔没有去了解一下这块的情况,也不会出现:"卧槽,要是把这次的设计放到这块多好啊"。

  直到今天,我跟这个设计文档整整周旋了快9天,今天早上交付了V1.2版本的文档和一些模块框图过去,其中还加了一些功能分布图和一些对应的描述信息,得到很不错的反馈,因为源哥说看着舒服多了,我心里也舒服多了。估计下周就可以开始实施了,好开心,终于可以看到自己设计的功能了。(初次设计,望各位照顾)

  最后,分享一句老大给我说的话。一个设计文档的好坏,最重要的就是要看,当你把你的设计文档丢给别人,别人和沟通的次数多不多,如果说别人每做一点你都在给人解释,那么你的这个设计文档就烂,而且很烂,甚至可以说不是设计文档,而是你在设计过程的做的笔记,我们设计的目的就是,把模块功能设计好之后组织成文档,交给执行者去实现,最后你再过来看是否和你设计的预期效果一致,话不多说,效果达到就好。

  感谢默默教我道理的人,感谢所有共勉的朋友。

时间: 2024-11-08 19:44:16

记小曼巴初次的设计心得的相关文章

手势识别项目小组——数据库设计心得

因为我们的项目是算法类,所以项目本身的需求不太明确.设计数据库的过程其实本身也是在进一步明确需求的过程. 这是我们画出的用例图: 以下是我们小组成员的数据库设计心得: JJ: 通过本次数据库设计的过程,我经历了很多也学会了很多. 首先因为课程组的要求是设计出至少15张表,而我们想要达到15张表是很困难的.我们的设计想法是先根据我们之前设计的原型先设计出一些表,根据登陆.注册.历史记录等设计了几张表.但是这些表也基本是基于用户而设计的,后来我们也寻求了指导老师的帮助,指导老师帮忙想了一个损失函数表

【2020-01-27】曼巴走了,但他还在

17:00 “经过多少困难,经历多少磨练,多少心儿盼望,春天的消息,恭喜恭喜恭喜你呀.” 一一庆余 今天,是不平凡的一天.但,今天又是平凡的一天.能说出这样一句话,看来也算是近几天看<禅者初心>的一些感受了.而且,还从中学习到了有“小我”与“大我"之分,原来过去的我都叫“小我”.每次当我选择一本新书看的时候,我心里都会在想,这本书能给我带来些什么呢?这是“小我”在思考.当我跑步的时候,我心里会想,今天跑的步会给我带来多少健康呢?这个还是“小我”.那什么是“大我"呢?当我问这

【小话设计模式】面向对象设计原则

1.单一职责原则 单一职责原则的核心思想就是:系统中的每一个对象都应该只有一个单独的职责,而所有对象所关注的就是自身职责的完成.英文缩写SRP  Single Responsibility Principle 单一职责原则-->"高内聚,低耦合",每个类应该只有一个职责,此外只能提供一种功能,而引起类变化的原因应该只有一个.在设计模式中,所有的设计模式都遵循这一原则. 优点: 可以降低类的复杂度: 提高类的可读性,提高系统的可维护性: 变更引起的风险降低. 2.里氏替换原则 里氏

iOS略记小功能

在我们进行开发工程的时候,有些小的功能能提高用户的体验,但是这些小的功能记忆起来比较麻烦,很容易忘记,在这里我整理一下自己使用过的小功能罗列出来. 一.项目在设备上得图标及名称的设定 1).图标:在项目中把你想要用得项目图标添加到项目中并且改名为icon(必须为png格式). 2).名称:在项目的Info.plist文件中有Key为Bundle display name一行的Value值改为自己所需要的名称即可 二.在程序启动还未进入程序起始界面前展示的Image 在工程选项中的General中

算导之DP算法的设计心得

和其他的DP帖子只是灌输思考之后的结果不同,这篇是DP算法的自我体会,应该是设计DP算法的思考过程. 斯以为,这才是拿到一问题,从思考到解决最精华的部分:) 犹记得第一次看到算法导论上拿最长与最短路径来说明DP中最优子结构证明过程的一个细节的时候,心里激动不已,国内的教材完全不考虑这个,而是把伟人思考之后的东西呈现给新人. 我第一看到,心想,这就是我要的东西,包括之前的loop invariant也是如此,看国内教材时缺失而又如此渴望的东西,在算导中再次给出完美的答案. 寻找最优子结构: 1.

《赵一曼传奇》读后心得

<赵一曼传奇>读后心得 风儿吹得走沙子,却吹不走刻在我脑海深处的记忆:抹布抹得去污渍,却抹不去那铁证如山的事实……伴着愉快的歌儿,迎接我们的电影却是可歌可泣的过去……      赵一曼是一位伟大的抗日女英雄.“九一八”事件不久,为了国家和民族的生死存亡,赵一曼便加入了党的地下组织.在一次战斗中,赵一曼不幸腿部受重伤被捕.日寇为了获取所需情报,以药物治疗来维持赵一曼苟延残喘的生命.日寇软硬兼施,想从赵一曼口中得到可靠情报,但由于赵一曼忠贞不渝的爱国崇高品质使得面目狰狞的日寇一无所获.大义凛然的赵

运营平台——效率型后台管理类产品交互设计心得

此文已由作者姚依旻授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 无论是光鲜亮丽界面可人的C类产品,还是稳重大气商务气质的B类产品,若某产品存在运营行为,则必存在一个给团队自己人用的后台,也就是运营平台.人们容易都把目光 focus 在大众用户的体验上,自己人的使用体验则优先级被放低了一些.我与运营平台朝夕相伴了一年整载,终于从一无所知到若有所悟,同时感慨时光飞速竟不察. 笔者在自己在写文章之前,也怕自己资历尚浅观点偏颇,故查阅了一些资料,得知各类运营后台的产品与交互设

慢阻肺疾病管理app——需求设计心得

需求确定已经两个星期过去了,现在回过头来写需求设计心得,能够总结出很多问题 过程: 拿到老师给的需求文档,对老师的需求进行提炼,选择自己将要实现的功能 对选择的需求进行了细分,完成需求原型.在此过程中,我们对需求的内容进行了讨论,对我们要实现的app进行了一个大致的想象,勾勒出每一个需求的呈现形式以及每一个功能的实现方式:当需求确定完,开始制作需求原型的时候,又发现了很多可以修改的地方,并且因为技术的原因,制作出来的需求原型似乎并没有完美的展现我们所期待的哪些功能,不过原型制作完需求也差不多确定

噪声收集系统——数据库设计心得

数据库设计心得 在需求分析阶段,其实数据库的设计就已经初具雏形,组内初步分析了需要哪些表来存放哪类数据,并探讨了各个表中的关键字段.但在需求分析阶段的数据库设计并不完整,只描述了部分实体,表中的属性也不能完全描述需求,数据库表间的关系没有体现,这就需要进入详细的数据库设计阶段来完善. 在数据库设计的第一阶段,还是围绕用户需求来展开工作.用户的需求在设计过程中扮演着中心角色,如果一开始对需求的分析就出现偏差,那数据库设计就很容易出现问题,好在需求分析阶段结束后我们的需求是十分明确的,项目组内根据项