mediocre117的博客

早晨查看邮件,收到了产品人员发来的产品原型.看完之后,我已经不再心存任何侥幸了!   以后抽空把axure学习了,以后有产品需求的时候,我可以根据产品的UI图,做出来产品原型好了,顺便捋顺产品流程!   既然无法改变产品人员做事风格,那么就改变自己的做事习惯.如果实在受不了,自己离开就是了!

不管别人说你是码农码牲了，本质上还是你如何看待你自己的职业！黑客与画家中有段话我很喜欢，类似的内容如下：黑客和画家，作家其实本质上是相同的。如果他们是相同的，那么画家和作家不可能只是写写字，随便涂鸦的人，他们的作品一定倾注了他们对事物，对人生的思考。同样，如果作为黑客（技艺精湛的编码者），难道只是不断敲那些字母数字的人吗？     不懂得思考的人，和市政人员，只知道挖沟铺路，按照别人的思想而存在

服务器端和客户端开发对接总结   1.从服务器端开发角度而言,将尽可能多的业务在服务器端处理,客户端尽可能少地处理业务逻辑,只做展示使用即可.原因在于服务器端开发一定了解业务,如果让客户端和服务器端都很精通业务,那么就会耗费不必要的时间;   2.从客户端端开发角度而言,服务器端每次返回的数据都是完整版数据,即如果没有对应的数据,那么某些字段也不可以没有返回,可以两方面约定好,不做业务上的判断

对于需求上的技术讨论而言,对于那些经验一般般的开发者而言,让其加入到讨论中可以让他们增长开发经验,但对于整体的思考设计却没有什么帮助,每次的发言和讨论都是粗糙的解释说明,为什么需要主程序呢,因为需要他们的经验和思考能力,对于一般般水平的人来说是要学习他们的经验和思考来提高自己,实在感觉他们的讨论没什么价值,并且不断解释功能意图,让思考者来说是很烦的事情!   对于主要设计人员,设计定稿之后,那么

需求问题:查看某类型数据变动情况,比如京东上订单快递的流程,主要每次加入地点的变化;还有一种情况是查看数据数据本身的变动,比如某类型的申请文件,今日修改上传的图片文件,明日修改提交的文字材料,后天添加缺失的数据.   解决方案:对于总体数据变动来说处理如下.   方案1:以原始数据为根本,增加变化流水表,每日将变动数据写入到流水表中,那么根据原始版可以查看每日变化,这样的不足是无法展示最新的数

为什么要强调代码的可读性呢?我简单解释一下.    1.代码的可用性,可用性体现在开发人员把需求开发完成,正常完成产品需求,代码放到服务器上可以正常运行,测试通过,正常上线,皆大欢喜,但这仅仅开发者要做的第一步而已;    2.代码的可读性,可读性体现在自己现在可以读懂,自己将来也可以读懂,同时别人还能读懂你的代码.如果自己现在能读懂,可能哪一天重新看这块代码,居然自己看不懂了,这是经常发生的

用人和用物类似,物尽其用,而不能超出其韧性范围,纵使钢铁反复折叠同样会折断! 此用人时,需要评估其才和精神,才够用而精力已怠,需要休息的时间. 工作,暂不谈让人快乐与否,若让人困苦难受时,人无法尽其才能时,需要休息也!比如it从业者,如果无法休息恢复精力体力,如何有效工作呢,如果没有了生活,又谈什么工作呢?     所以管理者,需要注意手下的精神体力状态,不可无限制让其工作加班,人都需要休息的

1.针对原型(根本)   结论:对于订单部分的原型必须要提前给开发人员,然后开发人员逐字逐句,逐个按钮输入框进行思考分析,提出疑问和建议.如果版本迭代内容多,那么需要给研发至少半天以上到一天的时间去分析原型.   为何至少半天以上呢?如果开发人员思考不足,那么就会导致开发过程中问题不断,导致研发人员和产品人员频繁对产品需求进行沟通,不断增加两者的时间成本.   本次对新版中心原型,我做的分析

目前公司使用php和java做开发,开发规则如下:   1.重点功能php开发人员调用java接口,非重点业务直接操作数据库处理.好处在于:可以减少测试联调的时间,较少业务处理复杂度,减少不必要的沟通时间和联调时间,降低事情复杂度.   2.新业务开发前,需要做充分足够的业务分析,减少开发的业务阻力和减低开发难度,从而节省沟通成本时间;在开发过程中如果出现业务理解有差异的问题,及时面对面沟通,