来到新公司已经近八个月了。由于业务上的不同，开发方面的价值观也变化很大，趁着杭城初雪的这个好日子，闲话几句这段时间前后对比反差的一些思考，未见得正确，就算个笔记吧。
先介绍一下业务背景，前公司是以卖硬件为主要盈利模式的、较为传统的大中型企业，软件包括一些数据资源是以免费的形式作为提高产品的附加价值存在的，基本上一年两个机型、半年一个大周期两月一次小更新的节奏来做软件。由于品类的特殊性以及公司现有的业界地位，大环境上属于只要有新品就能卖得出去、拿到利润的安乐状态，由于硬件都是自己定制的，所以适配方面难度不大；现公司的产品则是手机平台上的应用软件，更新周期在一月以内，节奏比较快，android方面要兼容市面上大部分的主流机型，相对而言市场竞争激烈，互联网环境下的此起彼伏变化还是很快的，逆水行舟是不进则退的，而产品不进步、没有新意拢不住用户，则存在不进则死的风险。如果人生是场游戏的话，那么这是完全不同的两个副本。下面散记一些思考点，没有什么逻辑关系，想到哪儿写到哪儿。
全员意识
一个人维护五个应用和五个人维护一个应用是完全不同的境遇。虽然工作量都差不多，但是“质”是不一样的。后者让人更加聚焦、虽然要多出适配兼容方面的考虑，但总体上技术上可以研究更深入、可以花更多时间到细节上来。近期的领导TIP是要对项目整体有全员意识，就是说各个模块都基本界定到人的时候，不要自扫门前雪，要对村儿里所有人家的雪都有点认识——对整个产品的设计思路、背后要达到的目的要明了甚至要参与讨论与决策，这里不讨论技术与产品之间的辩证关系、程序猿个人职业发展路线取向之类的哲学问题，最直观的好处就是战友不在的情况下，咱也能伸伸手改改bug；还有就是一块业务做到烦的情况下可以快速找到带有不熟悉技术点的业务练练手，降低技术上的疲乏感，基础一些不熟悉的技术点总能让人精神一振，没有进步对于技术人员而言是件可怕的事儿。
项目时间的评估
快速迭代嘛，快就代表着周期短，那么周期内能做掉多少需求、如何能保证周期内的开发进度，时间上的评估是重中之重。如何去评估业界似乎没有什么被统一认可的方案，各有各的招儿。有个前提是需求尽量在周期内不变动，评估才有意义；另外就是评估的过程实际上也是一个功能实现的设计过程，这涉及到开发者对老代码的熟识程度和设计功底，当然对需求的正确理解、拆分与细化达到技术上实现的最小粒度也是评估出准确时间的条件之一。具体前面有专门的文章表述，这里就不多说了。
技术人员的闲话会
比起一两周一次的技术人员咖啡闲话会，感觉前面的吃饭、唱K、看电影团建三部曲简直是弱爆了（虽然在领导请客的前提下腐败也是能得到满足感的）。我认为团队建设的意义在于加深团队人员的内部交流、提高熟悉程度，从了解到理解再到谅解，达到降低工作过程中人与人之间的摩擦阻力、矫正工作发力方向的目的。茶话会相比而言效果会好一些，咖啡还是茶并不重要，重要的是要说话、要交流，沉默才是最可怕的，因为沉默有太多种可能。至于能从交流中获得些什么，那就要看个人的理解和关注点了，有时候是危机感、有时候是一个新的解决方案、有的时候是对目标的全新理解带来的斗志昂扬，反正总有些收获。
独立时间
存储器上碎片过多的话，会导致存储器的利用率降低，时间对于程序猿而言也是一样的，连续的大段时间对开发效率而言是必需品，而保障迭代周期顺利完成的条件之一正是高品质的开发效率。实际过程中各种各样的事把大段的时间资源切成碎片，运营的反馈、产品的会议、测试的问题……虽然这些“琐事”是必要并无法避免的，但是我们可以尽量的整理一下这些事情的耗时点——像磁盘整理一样。记得之前看到过某些公司有类似于“安静的礼拜三下午”之类的概念，意思是在每个礼拜三的下午是留给每个程序猿独立思考、开发的时间，这段时间团队的其他要程序猿参与处理的事件统统前置或者后置，程序猿之间也尽量避免相互打扰，保证开发人员有一大段时间高效的工作。我觉得不妨灵活的尝试一下这个概念。
代码质量的保障
项目质量的保证目前主要依赖于黑盒，前公司也是如此，不同的是前公司依赖于庞大的测试人员基数和足够长的测试时间来保证项目的稳定性，虽然项目规模不可同日而语，但是目前的状态相比之下测试资源是不足的。这也间接导致了每次发版本必要加班通宵的反常状态。技术人员除了提高自测强度、编码能力之外，总会从技术的角度去思考解决问题的方法，这样白盒测试就再次纳入到视野范围之内。当然白盒有白盒的问题，但是在没有更好的办法之前，只能在条件允许的前提下，逐步建立起来。对于这一点只能用“以观后效”来作为总结陈词了。
不断总结不断积累，养成习惯才好。觉得自己六个月前写的代码是烂代码是个好事情，能推翻或者更新自己六个月前的观点和认识同样也值得肯定。记下来，才好对比，就这样。
