很久很久没有写博客了，不是因为懒了，而是因为莫名的忙了起来，但是忙的事情都是司空见惯的东西，就是重复性的劳作，所以没有什么好记述的。但是想想这样应该挺失败的吧，所以开始总结一些经验类的东西，这些东西不能直接帮助你解决一些问题，但是作为一个过来人的角度讲这些，也不枉费自己花在里面的时间了吧。
系统的阴阳
见过阴阳图吧，你中有我，我中有你，其实感觉暗指的内容就是凡事无绝对，这在设计需求不明确的系统中的含义就是虚与实，严与宽，确定与自由相结合。这样讲可能很空泛，那么就举下面的这个例子来说明。
财务的利润表，(如果不知道财务的利润表是什么请自行百度)，其中第一栏叫做“主营业务收入”，一般来说都是销售订单或者销售订单的金额合计，这个时候，你根据现有的数据计算出来了这个数据，那么这个就是最终值了吗？一般不是，因为凡事无绝对，你算出来的结果是理论值，财务还会微调进去一部分数据，所以这个时候你就需要为财务开通一个可以调整这个数据的功能。这里你计算出来的结果是一个肯定值，你想着自己这个值肯定没有计算错误，这个月的主营业务收入就是这么多，但是实际上的情况是，你90%的可能性是与财务的报表对不上的，这个时候财务就需要微调，这个就是不确定的部分。系统能完全取代人吗？不能，即使是现在最先进的人工智能，它依旧不能有人的感情。就像一个人是绝对的坏人吗？不，他可能也有善良的部分。
回到系统中，凡事无绝对，记住这个宗旨，在设计系统的时候，多想想这几个问题：
- 肯定这样吗？
- 不这样会怎么样？
- 有没有特殊的情况？
这样做的目的不仅仅是为了让你明确，更是为了让你能针对生活中那么多的“额外情况”做好准备。你的系统能应付的情况越多，你的系统别人用起来才越舒服，因为你总能达到他所期望的效果。
非技术型老板/没有规范的日子
为什么写这个呢，因为太有体会了，所以一定要拎出来讲一讲。我们公司是一个小型团队模式的，所以人员配置很不齐，这个时候你常常需要身兼数职，要是有经验还好，要是没有经验，再配上一个非相关技术型出生的老板，那种酸爽。
举个例子，在你手上事情超级多的时候，老板来了，然后向你提了一个需求，这个需求即使是可以修改或者说很合理的需求，你应该放下手上的事情来做这件事吗？人情和规范的开发流程，你选哪个？你也许会用我上面的内容来反驳我，你自己说的不一定啊。其实这个是一定要坚持的原则。就像做人的准则一样，准则要是破坏了一次，就肯定会破坏第二次，即使第二次你给自己找多冠冕堂皇的借口都没用。
首先说一下为什么不应该立刻做。程序的本质是按照一个既定的结果去运行出一个结果，长期跟程序打交道的程序员思维上和这个也很接近，一个工期内，为了一个确定的目标去完成，没有目标或者目标经常修改，就像程序老是运行不出你想要的结果一样，非常不爽。而程序员不爽的最终结果就是辞职。如果你觉得一个程序员辞职无所谓的话，那么你连你的员工都不重视，确定你能经营好你的企业？企业的本质是员工啊！
接着就是节奏，大学时期参加过1000米的都知道，一般人的体力是支撑不了你1000米都是冲刺状态的，当然，你招的起很贵的长跑运动员就另当别论了。所以长跑靠的是节奏，前期跟住，后期努力赶超，这是我的节奏，因为我知道努力赶超很幸苦的那个阶段是有终止的，所以我可以让自己痛苦一段时间。对应到开发中来，有一个很好的节奏，大家才能适应一个高强度的工作任务，否则即使老板每天扣住加班，就像放一头狼在后面追你一样，你开心吗？
最后就是产出质量。即使你让程序员很快就把你想要的结果做出来给你了，那么我可以说这是在消耗一些潜在的可能更好的解决方案的可能性。程序员是一个创造性的工作，每一行代码，每一个效果，都是程序员的创造，如果你将这种创造的过程改变成产出的过程，那么程序员自身的立场就从这个项目的主人，变成这个项目的实现者。举个通俗易懂的解释就是装修工跟房子的主人之间的区别。房子主人对这个房子是有热情的，而装修工没有，在他们的眼里这仅仅是件工作。
所以别催，相信你的程序员，不能把你自己的慌张的节奏带到团队中来，那样造成的结果就是所有人都不爽。而不爽的最终结果以及解决方案都很简单，只是代价有点大。至于怎么规范以及怎么沟通交流，《软件工程》，《情商》，我相信这两本书应该会有启发。
Bug是问题，但是人不是
这个结论看似有点矛盾，因为Bug一定是人写的，那么出现了Bug就一定是人的问题吗？不一定吧。前后期需求变更，业务场景没有考虑到位等等，都有可能造成Bug，这个时候你该怎么办？给员工一句警告：“下次别再出现这样的问题了。”员工可能自己还在懵逼的状态时，突然来这一句，只能自己认栽，然后怀疑自己当时脑子怎么抽到的，怎么会写这样的代码。
出现问题很正常吧，你没犯过二，你没写过有问题的代码？在成为一个老手或者一个专家之前，谁都是从菜鸟一步步来的，当你在高处俯视下面的人时，请多一点耐心与指导，有问题是肯定有问题的，但是也请让他们养成对问题的思考与反思，而不是针对这个问题就给人贴上一个标签或者一个惯有印象，有问题的代码，不是这个写代码的人。