第悔明十名：“加油!我先下班了啦~”
作为一个需求方，我提醒你不该说这样的话……
第九名：“你造嘛，我新电脑的内存有1TB!”
内存和硬盘有啥区别，你造吗?
第八名：“能帮我黑XXX的QQ吗?”
不能!不能!不能!
第七名：“尽快做完，好伐?”
用邮件发这句笑兄话杀伤力更大……
第六名：“你先大概弄一个，让我参考看看。”
请问，什!么!叫!大!概?!
第五名：“帮我加10个功能先，明天就要，拜托!”
拜托，我又不是变魔术的!
第四名：“太好了，你还没回家，帮我个忙，很快的!”
和第一句连在一起说，你会死得很快~
第三名：“为什么今天网速这么慢?”
怪我咯?
第二名：“这个应该很简单的吧?”
我不想给你解释，解释了你也不懂，心累。
第一名：“这里改一下就好碰前袭了啊!”
YOUCANYOUUP!
布置任务，理解需求，团队协作等相关的工作中，良好的沟通和信息同步有利于减少甚至消除团队成员理解差异。
然而有些项目经理/产品经理/业务，喜欢说“这个需求很简单的，我只讲一次”，在他们眼里一些“简单的功能“无需多讲或者讨论，其实领任务的程序员没有context，很难做需求分解、评估开发工作量，比如某个web应用要做个权限管理模块，初看起来这个需求很常见且简单啊，基于RBAC来设计开发呗，卜蔽伍还可以用这些现成的框架技术（例如shiro）。
但是对于程序员来讲这个看起来常见的功能需求，context很重要，比如：用户数据哪里来？以什么方式登并消录？怎么校验登录基本信息？怎么维护用户信息（例如OA同步过来的数据之后有些账号冻结了，不同的数据源之间咋同步？同步频率？)，登录跨应用吗？这个权限管理功能给谁用？（不同角色使用对功能的要求不同，基于shiro等框架开发的权限管理模块受限于框架技术，如果想要有个完整的 *** 作界面或者做更细节/复杂的权限配置，那么类似shiro的框架往往不适用)。
仔细想想，自己有时候接了任务，评估工作量进入详细设计、开发状态后往往需要中后期增加沟通、协调资源、加班赶进度，很多次是因为当初需求未做充分沟通了解清楚，致使需求拆解不够清晰（小），导致评估量化很不准确，要靠加班来赶进型或度
程序员最讨厌不确定性。Debug的时候，在怪异再棘手的问题，只要可以稳定重现，都迟早可以解决。“稳定重现”的意思是只要按一定的步骤做下来，问题就可以重演。
最讨厌的就是那种时有时没有，不知道什么时候出现的bug。改了代码不知道有没有效，也不知道是否引入了新问题。可以把码农逼疯。
引入到生活中对人对物的态度也是一个道理。无缘无故发脾气又不说为什么的女朋友，言而无信说到做不到的人，约好的事情被放鸽子... 这些都是不确定性。
程序员对不可控的不确定性因素也是有解决方案谈团的。在代码里头把异常try-catch-finally一下，做好补救收尾，在加上几行注释警醒后来人这里别乱动。早陪对随机发生的问题，对应方案就是假设这里永远都会有问题，把随机的行为转化为降格的确定行为。就比如随机发脾气的女朋友吧，就含睁橘会放弃研究发脾气的原因，不求治本，而是假设她永远会发脾气，专注“哄”的工作也就是catch里面的内容。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）