2015第28周四
程序员可以被分为两种：
- 先确认前条件/不变式/终止条件/边界条件，然后写出正确的代码
- 先编写代码，然后通过各种用例/测试/调试对程序进行调整，最后得到似乎正确的代码
我个人保守估计前者开发效率至少是后者的 10 倍，因为前者不需要浪费大量时间在 编码-调试-编码这个极其耗时的循环上。"
写代码之前先通过循环不变式（可以参考算法导论中各种运用不变式证明算法正确性的例子）确认和证明你的逻辑是没有问题，并用边界case确认一下具体处理的逻辑。
永远先想清楚，再去动手。
>>（我是不会说自己每周只敲一天代码的）
不懂要问！问之前先尽可能去查！
>>（萌萌地跑来问我的下属，是把我当作GOOGLE机器人助手还是书橱？）
求助之前要先自己尽力去解决，搞不定及时求助！
>>（上司和同事不是给你打杂的；事情搞砸了再求助毫无意义）
你脑子的想法，不通过口头特别是文档表达出来，它事实上不存在。
>>（写文档，写注释，写日程表，写计划表，写会议纪要……不说了）
公司的各种设计指南、编程规范、XXX规范要仔细学习
>>（否则去参加外面的培训公司接受培训需要花钱还不靠谱）
新技术是好东西，但自作主张用了，多半是作死，特别是自作主张用开源软件的家伙
>>（我手下要是自作主张用开源软件，最起码一个大过处分，不预警，直接通报）
各种接口不要随便乱改；花半天先把接口吵清楚再动手，有益无害。
>>（当年专职负责吵接口吵了大半年呢，每个人都眼巴巴看着你的感觉好奇妙）
公共配置项不要乱动，特别是配置库和编译器的
>>（出问题了找BUG找死人啊）
上面吩咐了做啥事，脑子好就记住，脑子不好就拿本子写下来，然后去做。
>>（反正最多说三遍，再不好好学习就打入冷宫）
安排的工作一般都要接；接不了的要清楚说明客观原因，而且要客气。不要在其他人面前拒绝。
>>（随便拒绝工作安排，基本都是作死；当着外人不给上司面子，这不是作死而是作大死）
如果工作安排不清晰，请主动与上司沟通，明确关键的时间点和交付物。沟通前自己要有预案。
>>（没有上司喜欢不带着脑子跑来问问问的下属的）
如果完成工作需要其他资源，先尽力协调，再向上司求助，并明确说明理由和已协调结果。
>>（他出面跟人撕逼需要子弹，不要让他自己到处找子弹）
上司的技能树和技能点分布，可能跟你完全不同
>>（自己那坨技能点不全是金子，别人的技能也不全是屎，世界主体仍是分工合作）
自己的工作可以求助，但工作主体仍然是你；每次求助都是偷师的机会。
>>（谁给谁打工？这很重要）
遇到例外情况，及时反馈给上司；确信自己有能力且得到授权的，可以同步开始解决，否则等指示
>>（不反馈那叫知情不报；不解决那叫消极怠工；自己乱搞叫越权行事）
事情进展顺利也要定期反馈进展；每日三省吾身，不要让别人逼着你写总结。
>>（老旧的Unix程序默认没有return，但你不是它。他跑来问的时候，心里是充满疑惑的）
是男人都会犯错（from DuangLong），但相同的错误不要一而再、再而三地犯
>>（上司不是你爹，他口水干了就会变得异常烦躁）
不要随便发脾气，更不要对着上司发脾气
>>（否则的话，很快就会通过惨痛教训明白：平等、自由都是相对的）
不要当上司是傻逼；如果觉得他不是很懂，委婉地教会他。
>>（绝大部分情况下，后果是下属傻逼了）
答应了别人的事情要做到，要不就不要答应；
>>（做不到比拒绝的后果更严重）
有啥事情可能起纷争时，事先讲好道理，商议好规矩
>>（这一条是金科玉律！）
不要吝啬于分享经验，但不要随便发表看法
>>（大家都喜欢对自己有帮助的人。但看法么……说者无心听者有意）
一定要有几个死党，关键时刻可以帮你扛扛工作、通风报信；
>>（谁没有难处呢？但没人欠你的）
今天求助了别人，记得日后要还，晚还不如早还。反之同理。
>>（纸牌屋）
搞清楚自己的岗位职责；搞清楚跟你工作直接相关的周边岗位职责
>>（基本入门要求）
搞清楚业务流程，自己在其中的位置；
搞清楚公司靠神马赚钱，自己在其中的作用；
>>（最好的公司都是流程化运作的，没有也要理出来）
编程之余，多看看公司对应的商业和工程专业书籍
但请务必记住：业务不是学来的，是干出来的
>>（业务不是编程和0/1，业务是非常复杂的，它很难掌握但比程序的变化要少得多）
搞清楚你对老大，同僚，周边部门的价值；
搞清楚老大，同僚，周边部门对你的价值；
>>（不清楚这些，工作中怎么互帮互助 or 谈条件 or 撕逼）
经常跳出自己的岗位看问题，有极大好处
>>（否则很容易固执己见讨人厌呢）
要区分有价值的功劳和没有价值的苦劳
>>（否则白忙一场空）
干得好就可以多要钱，但要有理有据，最好的办法是拿好的考评
>>（连考评周期和规则都没有的公司，还是算了吧）
还有性能和质量。开源软件的质量良莠不齐。
好好读编程规范！好好读编程规范！好好读编程规范！
不要依赖于DEBUG！事先想好软件逻辑可以节约大量的DEBUG时间。
硬件是会坏和异常的！
服务器、配置库不说了，传感器和执行器同理。
人是会犯错的，而且很经常！
做好代码和数据备份；检查输入，尽量控制输出。
最好的学习，是工作中学习，学以致用。
因为这样目的最为明确，效率最高，正向负向刺激最强烈。
找个好师傅。
一天最多问他一次，逼着自己先想清楚再去问。
编码不是目标，实现功能不叫大牛。
一般对代码的优化集中在性能，可维护性，可扩展性，安全性和质量健壮性上。
大牛们就牛在这里。