第一篇薄博客，文笔差，话题老，将就将就。
最近一个星期的空余时间里读完《程序员的职业素养》，感触比较深，于是就拿这个当话题写了点东西没，顺便推荐一下翻译者之一 余晟 的微信公众号“余晟以为”
【说“不”】
最近这几个星期，因为公司里要测的项目都扎堆在一起，我和导师都非常忙碌。后来发现的bug很多，当开发在deadline到来嚷着要上线的时候，导师坚决拒绝，“宁愿延期也要保证质量，绝不能把一个残次品扔上去给别人用”。原话大概是这样，这深深地触动了我。在很多公司里面测试地位都比开发低，这是国内行业的文化。通常测试和开发也是对立的角色，容易起争论导致团队内的不和谐，可能这时候比较没有经验的测试（比如我就是）会在内心说服自己听从开发，安慰自己这是为了团队的和谐和长期发展，就听开发一次吧，开发比自己资格老，自己不该这样顶撞。殊不知开发其实并没有想得像自己以为的那样周全，结果最后锅还得由测试背，因为测试的责任就是在最后把关产品的质量，过了测试这一关就相当于质量已经得到了测试的保证，出事找测试。导师这样做，绝对是对的，不仅在考虑自己身为测试的利益，也考虑了产品用户的体验和团队的名声。在书中，用的是经理跟开发沟通的例子，开发知道经理的给出的时间不足以完成任务，在经理的软磨硬泡下依然坚持自己的判断不接受任务，绝不妥协，不会说“我试试看吧/我试着做一下吧/我尽力吧”，这样说在别人理解已经相当于开发给出了一个承诺，承诺会在期限内完成任务，“能就是能，不能就是不能。不要说‘试试看’”，想起导师也对我说过，“你测试的这个模块是测试通过就通过，没有通过就是没有通过，不要说‘应该通过了吧’”。
【说“是”】
我经常找开发解bug，碍于其他安排需要开发给出解bug的耗时，或者开发解完bug后问他bug产生的原因。书里给出了一些方法，可以识别“缺乏承诺”的征兆，并给出真正的承诺听起来是怎么样的，这样就知道开发的话是否可信。
原文：
以下事例中包括的几个用词和短语，会透露“缺乏承诺”的蛛丝马迹。要注意搜寻。
[需要/应当]。“我们要把这活做完。” “我需要减肥。” “有人应当负责去推动这件事。”
[希望/但愿]。“希望明天我能完成这个任务。” “希望改天我们能再见面。” “但愿我有时间做这件事。” “但愿电脑能快点。”
[让我们（而不是‘让我’）]。“让我们回头再见。” “让我们把这事做完。”
只要去搜寻你就会发现，在自己身边，此类词语比比皆是，甚至在你对别人说的话里也时常出现。你会发现，我们有极力逃避承担责任的倾向。
真正的承诺听起来是这样的：我将在……之前……
下面给出的是让你没能做到“言必信，行必果”的一些可能原因，同时还附了一些应对方法。
[之所以没成功，是因为我寄希望于某某去做这件事]。你只能承诺自己完全掌控的事，当你的任务需要依赖别人开发的模块时，除非你能保证别人不出岔子，不然就不应该瞎承诺。
[之所以没成功，是因为我不太确信是否能真的完成得了]。即使目标无法完成，你仍能全力前进，离目标更近些、而弄清楚目标能否达成这件事，便是你可以采取的努力行动之一。
[之所以没成功，是因为有些时候我真的无能为力]。如果你无法兑现承诺，那么最重要的就是今早向你的承诺对象发出预警，越快越好，越早越好。你越早向各利益相关方发出预警信号，整个团队就越有可能抓住机会，中止并重新评估当前的活动。
【测试】
我从实习到现在进入试用期共工作了三个月的时间，以前一直觉得测试是因该在拿到产品初版的时候才开始制定测试计划和测试策略（被大家笑话了QAQ），后来被导师训了一顿，测试是在拿到产品说明文档时就应该开始制定计划和策略的，从来都是（QAQ）。另外，由于组内测试员工很少，产品项目又比较多，自动化不能搭建起来，因为不同产品之间不通用，这样每一个产品搞一套自动化的成本就超高（其实都是内部使用的产品，不对外，一般出问题了也不会说一下子丢了几十几百个万什么的）。单元测试也没有做到，这个是开发的工作，开发看起来贼忙的样子，有时改完bug拿过来让我测，我按照之前的操作直接重现bug，我强烈怀疑开发瞎改一下根本没自测就直接提上来，也说明了公司里的开发水平是参差不齐的。
测试也是分业务测试方向、工具平台类方向等等。按照我的偏好来说我打死都不愿意做那种整天只是点点鼠标敲敲输入数据的业务测试，跟导师聊过，业务测试其实在技术方面是很有限的（导师走的是业务测试），或者说编码能力是很有限的，虽然还能编码，不过做出来的东西难度也就中低，比如说写个两三百行python搞搞基本的接口自动化测试，或者向开发要些老脚本过来根据自己的需要改动一下再使用。与其说业务测试是技术性岗位，在我的观点看来更像是半技术半管理的岗位，升迁高一些后就是负责测试设计、流程管理、测试安排等工作，无聊。
工具平台类的就把时间分在业务测试和工具平台开发上去了，不过就现在我所知道的（仅仅是现在我所知道的，肯定还有更多），工具平台一般也就是一些监控平台、数据汇总展示平台、自动化平台等，选择貌似也很有限，来来去去都是这样，没有非常吸引人的创造性所在，东西也只是追求实用性而不追求艺术性、创造性、新颖性。说到底也并不是我想要的，不过目前为止倒是还可以逼我学习一下一些网站开发技术比如php等，暂时这条路还是可以走一下，不过我不想一直走下去。
【练习】
爱好技术，就必然需要不断练习。数据结构、算法是所有程序员的基础课题，这些技能好了绝对会有益无害，做的不好虽然平时看不出来有什么明显劣势，但是在关键时候就会发现要你的命，所以练习是不能停的，编程就是一种手工活，熟能生巧，旧点不使用生疏了，就很麻烦了。平时找些数据结构或者算法的题目做做，难度按个人偏好，然后试着从不同角度解题，把一个实际问题抽象后用程序来实现算法。一直都很羡慕搞ACM的大牛，我是有自知之明知道自己搞不来这种东西，不过有空钻研一下也是很好玩的。
【时间管理】
会议是我现在最怕的东西，因为我发现很多会议效率低下令人打瞌睡，而且又占工作时间会后要加班，万恶……书里提到过番茄工作法，我曾经不是很严格地按照要求试过一下，还是有效果的，可以一用。
【专业程序员最糟糕的表现是两耳不闻窗外事，只顾一头将自己埋在技术堆里，甚至连公司业务火烧眉毛行将崩溃了也不闻不问】
也许别人最关心的，恰恰是自己不以为意的。相信不少数从事技术的人都会有一颗向往技术的心，有时甚至是直接会给自己定位成“除了技术什么都不想管”。我自己也是对技术有偏好，刚出来的时候甚至还有些对其他从事非技术岗位却拿着高薪的人心存蔑视，那时候是太幼稚了。在这个时代，技术不是决定一切的原因，公司产品的业务才是决定一切，技术只是作为一种支撑，来让业务可以被用户更好地享受。比如淘宝双11，你觉得用户会在意淘宝的双11技术团队如何加班通宵调优测试吗？没有用户会在意这个。用户唯一在意的是他能不能在双11到来的那一刻秒杀他想买的东西，而淘宝提供一个电商平台，用户就下意识地认为淘宝在双11运行正常是它的责任，就得让用户不会在秒杀商品的时候神他妈发现网页不可用。或者换种角度说，业务才是程序员的米饭班主，程序员被聘用过来就是为了给公司创造价值，给所在的业务线提升收益。
【不正常的团队最糟糕的症状是，每个程序员在自己的代码周边筑起一道高墙，拒绝让其他程序员接触到这些代码】
我现在所在的公司很明显存在着这种问题，不过最近开始强调内部开源，让各个部门可以分享其他人做出来的内部工具和平台，以达到比较好的复用效果，减少造轮子的现象，节省更多的人力来从事更加有创造力的事情。之前还是每个部门，每个团队有会做自己的内部工具，即使在隔壁团队就已经做出一个一模一样的，但是为了kpi和绩效，还是自己重新造轮子，真的很浪费时间。共享代码是很必要的，我现在是一个刚毕业的测试，也没有什么话语权让开发把源代码拿给我review，说不好听些可能那些干了几年的开发根本就不愿意把他们的代码给我看，也许他们就认为区区一个二流学校刚毕业的毛头小子有什么资格阅读和评论我写的代码（当然我希望这只是我的猜测而不是现实）。我觉得，把自己的代码拿出来让人“评头论足”是一件很自豪也很兴奋的事，一是你有信心把代码拿出来，这就某种程度上表明了自己的代码是规范整洁、井井有条的；二是万一别人有更高明的解决方法，或者说发现你的一些自己从来没注意到的编码坏习惯，那对自己来说肯定是血赚不亏啦。
【面试后符合要求的毕业生有个共同点：他们几乎都在进入大学之前就已经自学编程，并且在大学里依然保持自学的习惯】
我是在大三接触到数据结构后才开始觉得编程有意思的，算起来我从投入计算机到现在应该刚好两年，也是因为我起步晚并且那时候没有受到什么特别大的刺激（张秋怡的简历），一直当个乖乖学生没什么知识追求老师教什么学什么。所以导致我没有办法在毕业的时候找到一个好的开发岗位，最后退步来到现在这个大型公司从事测试。我所听闻到的很多业界高手，就是从高中、甚至初中（很多老外大牛从小学）就开始接触编程并且爱上编程。虽然张秋怡这类国内大牛是从大一才开始接触编程，不过人家目标明确、有着强烈追求和毅力，所以仅仅本科4年就已经牛出名气。然而从正态分布上来说，有这样水平和意志力的程序员也是少数，应该有不少像我一样起步晚、人比较懒、但是有对技术有着热爱的同学在，自学是我们的唯一出路，看书、公开课、逛论坛、接触牛人等等，算起来其实也有很多自学方式让我们成长，希望我、还有大家，都能在以后一直保持着自学的习惯和动力。