爱学it学无止境

面试的时候，我有个习惯，我会先描述一个具体的问题场景，让候选人设计方案，同时让候选人聊聊如何解决这一类问题。因为这样和候选人探讨具体场景的具体方案，可以很深入的讨论细节，考察实际的系统设计能力，防止他夸夸其谈，询问如何解决这一类问题，能考察是否具备深度思考和抽象能力。

例如服务的full gc 非常频繁，半小时一次，如何解决这个问题，你有哪些思路？谈谈GC问题有哪几类，优化GC参数有哪些方向？

例如优惠券领券活动有库存限制，有总库存和日库存，系统并发度最高 1W TPS，要求设计一个扩展性强的库存系统？

为什么要这样提问呢？因为解决问题的能力和突显你的能力同样重要。解决问题要看结果，你拿到了好的结果，只能证明你解决了这个问题。如何突显自己的能力？要充分说明这件事的挑战、难点，要能说清楚解决方案的逻辑性。

在职场里光干活显然不够，活是永远干不完的。在大公司里，快速解决一个具体的问题和完美解决一个具体的问题，似乎是存在矛盾的。

快速解决一件事，一般使用改动少、风险低的成本低的解决方案，这种方案最终会被定为短期方案。而长期方案则有如下特点：

  1. 能解决根本问题，不仅针对一个具体特殊场景
  2. 不仅能解决当前场景的风险，更全面地解决潜在风险。
  3. 具备更好的扩展性，未来的需求来临时，更好评估和修改，需求交付更快。
  4. 系统边界更加清晰，职责划分更加合理。（至少上下左右相关方都认可的标准）
  5. ……

完成胜于完美

完成胜于完美，我上家公司的CEO说过这句话。那家公司研发团队少于500人，当时公司创建时间不足5年。

在中小型公司，业务压力非常大，业务的稳定性不足，往往需要团队快速试错，快速拿到结果。快速淌出来一条路，证明这条路是光明的。试错的次数足够多，成功的几率越大。

这种情况下，研发团队的目标是更快的交付需求，系统稳定性、系统设计合理性在初期是次要目标。

所以我们的CEO对公司产研团队的要求是完成胜于完美。 项目组采用敏捷开发模式，每天的晨会负责过项目进度，每一天会单独过个人的项目进度。 每个人每天干了什么活，当前有什么在跟进的项目在领导层到时明确的。每个人的压力也是非常大的。

当时领导对我们的要求就是快速完成需求，有困难提出来，领导帮协调解决。 大部分情况下甚至不写设计方案，对齐接口以后，直接写代码。

每天都有写不完的代码，什么都做过，什么都不精通。我感觉自己的成长很慢~ 这可能是小公司的通病。我做过很多项目，经验看似很丰富，但是如果问我精通什么？在这个领域，我足够专业吗？我的心里底气不足。

停下来思考的时间很珍贵~ 因为不停的有倒排期的需求，甚至需求提出越晚，上线要求越急，简直倒反天罡。

完美胜于完成

入职大公司一段时间以后，我开始意识到，原来大公司大部分时间不是在写代码，是在写技术方案，写梳理文档，写SOP处理方案，写重构方案。每天不是忙需求，而是在忙稳定性。

大公司里虽然没人说：完美胜于完成，但那是大家心照不宣的潜规则。

大公司里核心项目的产品形态已经很成功稳定了，产品经理的需求方案评审更加严格，项目规划也更长远。在落地前，会分析大量的数据得出业务结论，会花大量的时间思考产品设计，总之 产品经理更加专业，作为研发感受是：需求频率低了，沟通氛围更和谐了，上线要求没那么急了。

但这不代表你更加轻松了。因为要求你花在技术方案上的时间更多了，你需要考虑更多的事情，它会要求你的技术方案写的更全面。

你要做的足够完美，并且能告诉别人，它在哪些方面有挑战，我采用了哪些动作，化解风险，解决问题。至于完成这件事，这是最低的要求。