如何培养技术思维
所谓技术思维，其实就是用技术人员的思考方式看待问题。作为技术人员本身，随着工作年限的积累，慢慢都会形成自己的技术思维。不过有些基本的思路早晚都会用到，所以还是尽早了解比较好，不必都等到踩坑之后才去反思。
技术思维之可行性
策划产品的初期，原则上是不应该受可行性的干扰，先想到好点子，剩下的才是具体实现方案的问题。但是到了具体的产品需求文档形成之前，可行性就成为最后一道门槛了。这时候，产品同学应该好好找开发哥聊聊，到底能不能做了。我们知道，产品同学最怕的就是开发哥甩过来一句：实现不了… （偷笑）
那么到底能做还是不能做，是不是就只有开发说了算呢？当然不是！至少还有老板~ 然而，总把老板搬出来也不是个事儿，况且，不是每个需求都有老板关注和授权，狐假虎威肯定是要出事情的。
那我们先来看到底什么情况是我们所谓「实现不了」的需求。据我观察，做不了的需求无外乎以下几种：
- 技术限制，完全实现不了；
- 平台限制，公司不用这种语言，没有环境基础；
- 人员限制，开发不知道能实现，或知道能实现，但自身能力不足；
- 心情不好，不想做了。
首先第一点，这句话不是随便说的，如果要说是技术上实现不了，那一定要相当有信心和勇气了。但你要知道，说出这句话是要责任的。这就如同去医院看病，医生说「治不了」，那产品运营同学就只能选择相信，或者换家医院试试，这就是专业的力量。
所以，平时得多看看其他技术方案的案例，多参加行业会议，多跟高手交流，多积累经验，都是废话。如果实在不确定能不能实现，起码拉上几个老师傅和领导「会诊」一下，统一口径，如果都觉得实现不了，那基本就是实现不了了。
那么第二点，平台限制是什么意思呢？产品运营同学在外面找到了「类似」的东西，说别人都能实现，我们为什么不行？那么，其实这里深层的原因就是，他们只能看到产品的表象，或者说是 UI 层面，交互层面。
举个例子，有些功能使用某种编程语言实现的，但是你们公司服务器没有这种环境，也不想为了这个需求单独搭建一套环境，那结论可能就是（在当前的条件下）实现不了。如果需求足够重要，我们可以考虑单独为其搭建一套环境满足需求，否则就只能换方案了。
再举个例子，产品运营同学看到某个网站上有酷炫的效果，问你能不能实现。你说，在你这个浏览器能，但是我们要兼容 IE 某个版本，那么，现在我们就只有三种选择：
- 优雅降级，针对这个 IE 版本牺牲部分效果；
- 根据客户端统计数据，放弃使用某些客户端的用户；
- 换方案。
具体，就看你怎么选了。所以，遇到这种情况呢，首先你要确定他们找到的例子真的能应用在你们的业务上，比如高级浏览器能否套在低级浏览器、APP 效果能否套在 H5 这种。如果不能，那就是实现不了。如果能，那就要看第三点，是否有资源或人员上的限制了。
第三点，人员限制。不管你承不承认，任何人的技术能力和视野一定是有局限性的，就看对待具体问题的态度如何了。有的时候，是真的实现不了，但是知道别人能实现；而有的时候，是我们自己实现不了，也不知道别人能实现；还有的时候，知道自己实现不了，别人能实现，但是碍于面子不好意思承认。这段可以算是「乔哈里窗」的程序员版本。
遇到这种情况，还是应该发扬积极主动的精神，在时间允许的情况下多去调研一下，多找找相关的例子。
至于最后一点嘛，心情不好就不做，你以为你是谁？先混到资深再试试吧。
总之，对于可行性的问题，一定要做足功课。否则一次两次说实现不了，万一同事又找到真的可以实现的方案，那么一来面子上过不去，二来也是对你能力和靠谱程度的减分，所以一定要慎重。
提示
- 新开发的系统，尽量熟悉平台已有的基础能力，再来看新特性；
- 使用外部开放平台的，一般都有现成的文档，虽然未必全懂，但至少大概知道平台能力；
- 别人家已经做好的效果，总不能说实现不了吧？如有差异，至少要给我讲清楚；
- 关注不同端的巨大差异，很多实现不了的，其实是终端差异的局限；
- 理解从芯片、硬件厂商、操作系统不同、手机厂商不同、机型不同、浏览器不同、语言不同等造成的种种差异~
技术思维之极限情况
开发同学，尤其是测试同学，总是各种钻牛角尖，什么小破输入框输入 1000 个字怎么办？什么同时 10000 个人访问怎么办？什么 500 个账号薅羊毛怎么办？
严格意义上来说，这些未必是你需要考虑的，到了「测试用例评审」这一步，自然会有专业的测试人员提出这些问题。但是假如这些类似的问题你之前都没有思考过，那么也可能被测试人员怼得很惨。
要想成为资深的工程师，需要你对研发流程的各个环节都成竹在胸，不至于一问三不知，或者一看就根本没有深入思考过。
这些极限情况，可以统称为「异常流」。有些异常流可能用户感知不明显，而有些异常流则会对用户造成很大的影响。因此，当出现这些异常的时候，如何给用户更好的提示和引导，或者引领用户去找客服寻求帮助等，就显得尤为重要了。
提示
- 试试钻牛角尖思维，暴力一点会怎样；
- 试试薅羊毛思维，量上来会怎样；
- 试试并发思维，全都一起来了会怎样；
- 有些极限情况是产品形态问题，要找产品同学拍版。
技术思维之安全性
每隔几年，就会出现一次较大的用户隐私信息泄露问题，最近的一次大家都知道，就是 Facebook 的隐私泄露事件，以及国内的 WiFi 万能钥匙。至于之前的门系列，虽然也是用户隐私，但是跟互联网关系不大，主要是修电脑的锅。还有「开房信息泄露」那次，是由于被黑客攻击。
关于黑客攻击的问题，无论是产品人员还是普通的开发人员，都是没有办法的事情，要有极其专业的安全团队才可能应付。我们这里说的，只是一点安全意识的问题。很多工作一两年的开发人员都非常缺乏安全意识。甚至有些是不经意的人为信息泄露，压根算不上技术问题。
比如，我们在互联网产品里标识用户要有某个特定的维度，可能是用户的手机号、第三方开放平台提供的 openid、淘宝登录名、微信昵称等等。那么，当我们以这个维度标识用户，并向他们展示隐私信息的时候，能否确认看到信息的一定是本人呢？有没有可能我们的维度没变，但是用户换了呢？
严格来说，除了生物认证和实时的真人认证，我们几乎无法确定网络另一端到底是什么人，甚至连是不是人都很难知晓。所以现在的很多互联网产品，才会有那么多烦人的认证。这个问题尽管无解，并且还要跟真实的用户体验之间做权衡，但总归是不能不考虑的方面。
提示
- 弄清楚所负责产品的用户体系，以及「用户」的定义；
- 考虑你展示给用户的信息，有多大可能被别人看到，站在身后看也算；
- 用户如有多个小号，能否达到 1+1=3 的效果；
- 你的系统有没有可能被机器人或外挂直接使用，而无法分辨。
技术思维之性能
你希望你负责的产品做到什么程度，是能用就行？还是在任何情况下都能对用户友好。如果程序上报错，信息一定是有助于问题定位的方法名、代码位置等等。那么用户需要看到这些吗？用户看到之后是怎样的体验呢？
所以，互联网产品如果想做到尽量完善，就要考虑到各种情况。当然，你不考虑也可以，那么接下来就是在开发、测试、运维同学不断的提问和质疑中慢慢填坑。
以电商的抢购活动为例，最理想的情况下，是系统有无限的承受能力，大家随便抢，系统也不会挂。但现实的情况是，硬件资源、网络带宽等都是有限的，即使我可以预估真实用户的量，也无法预估羊毛党的量。某个活动一旦有利可图，被转发到几个羊毛群，那基本上分分钟就要被掏空了。
那么在这样的现实下，如何能保证对大多数用户来说尽量公平，系统又不至于很快挂掉呢？这就是产品和技术要一起解决的问题了。譬如很多抢购活动引入的排队机制，或者提前发放的资格码等。这些需求某种程度上都是由于客观条件的限制，才引入的产品特性，从而倒逼产品人员修改流程和界面交互等。那么在你负责的产品中，有没有因为性能或其它的限制而产生的「特性（不是 BUG）」呢？
提示
- 工作没有界限，多了解点什么知识都没坏处；
- 互联网产品都会在某个环节或阶段有性能瓶颈，由此可能产生意外的需求特性；
- 从脑子里的一个点子，到最后用户使用的口碑，你都有责任关注；
- 在很多客观条件的限制下，没有所谓的绝对公平，一定是通过某种技术手段来「维持秩序」。
技术思维之隐性消耗
所谓隐性消耗，当然是不那么明显的消耗。那么在实际需求中，哪些消耗不容易察觉呢？最常见的，就是硬件资源和带宽的消耗，例如某些带有视频的活动，如果出现爆发式增长，就可能快速烧掉云服务账户里的余额。如果公司有资深的运维人员，那么可以在类似的产品上线之前，找运维同学预估流量和费用，以免不小心超出预算。
同样，有些公司购买的带宽是峰值计费的，那么就很容易出现意外。服务器临时扛不住，紧急加机器也是可以的，最坏的情况就是有短暂的时间无法给用户提供服务。其实一般情况下，大家是不太需要考虑这些的，毕竟不用你自己出钱，而且有 IT 和运维人员搞定就可以了。只是特殊的一些产品和活动，才需要把这些预算考虑在内。
还有一种情况，作为自己有开发团队的公司，遇到任何需求第一反应就是自己的开发能不能做，如果不是特别复杂的需求，一般都会得到「能做」的答案。但是有些时候，同样的能满足需求的东西，如果采用外包的形式交给外部团队，成本却可能降低很多。
这是为什么呢？难道我们开发就这么挫吗？当然不是！如果说一个需求全是从零开始的话，那么可以说很多公司的开发无论在速度和质量上，都是值得信赖的。但是，当这些需求外部已经有成熟的方案，或者活动模板，甚至是不怎么需要修改的现成代码的时候，这个成本就完全不一样了。毕竟术业有专攻，专门做活动的积累了很多活动；专门做游戏的积累了很多小游戏；这些东西对许多外包公司来说甚至是零成本复制，就看他想赚你多少钱了~
当然，外部采购也有麻烦的地方，比如公司资质门槛，财务流程等等，肯定是没有直接给开发哥提需求方便。但如果整个项目的成本和 KPI 都比较明确了，并且考察过有类似的外部团队可以满足需求的话，不妨对比一下成本和效率，开发哥的工资也很贵的~
提示
- 重点项目要考虑技术侧可能花钱的地方；
- 开发说「能做」只是说明可行性，效率和时间还要再评估；
- 外部采购成熟方案有时可能效率更高。
技术思维之关联改动
我们在规划新的产品特性的时候，往往会涉及到对原有系统的改动，由于原有系统可能不是自己负责的产品，即使与对应的产品沟通过，也可能考虑不周，而这些，还只是表面的功能改动，更大的坑还在后面。
无论从设计到产品，还是从前端到后台，都希望有很多所谓「模块化」的东西，最好像 PS 一样贴过来就能用。对于完全相同或差异不大的功能，模块化固然很好。但是在需求迭代的历史长河中，总会产生同一模块的大大小小的变种，以及与各个使用模块的系统之间千丝万缕的联系。
此时，如果你的需求动到了这些所谓的「公共模块」，麻烦就来了。其他使用模块的系统是否需要一起改动，是否需要同步更新，还是保持原样？保持原样的模块是另一份拷贝还是在原有模块基础上兼容？
在技术的架构上，我们很难既满足想要一起改的时候就完全一起变化，而不想要一起修改的时候，又可以随便想改哪个改哪个。这两个点之间只能是不断地权衡和妥协，没有完美的解决方案。因此，在我们寻求公共逻辑和修改迭代的便利性的同时，也需要考虑到未来分道扬镳时千丝万缕的纠缠。
提示
1，只要你的需求修改到的地方，就有可能牵一发而动全身； 2，模块化未必是好事，只有在保证这些产品模块功能相对一致时才有用； 3，技术人员也一直在纠结优化与过度优化之间的界线，这个界线完全取决于产品的走向~
结语
本篇粗略讲述了开发人员见到需求或者遇到问题的时候，大致都有哪些「技术思维」，这些思维出于严谨，却又难免有吹毛求疵，钻牛角尖之嫌。技术说到底，都是冷冰冰的代码逻辑，没有什么感情用事和临时的杀伐决断。只有把所有细节和可能出现的状况尽量考虑清楚，才能开发出健壮稳定的系统。
你负责的产品能健壮稳定地给用户提供服务，也是技术成功的表现。既然如此，这方方面面的技术细节问题，不可不察。培养良好的技术思维，能让你尽快成长为一个专业的、资深的、真正意义上的工程师。 下一篇: Chapter 05-04 如何培养用户思维