🤔☕️🤔☕️🤔 * 📖：领域间问题 vs 横向问题 * 🤔：领域间出问题，大概率是扯皮，也就是扯你做还是我做，原因大概率是收益不明显。要么，把利益的平衡点调整一下，直到大家抢着做，这是基本招数。此招的问题在于，团队会越来越趋利，直到金山银山都不放在眼里。要么，找到高人去看见看不见的方面，吃苦在当下，收获在未来。此招能使的必要前提，得有这样的高人现身。不过，领域之间也存在不可调和点，毕竟在遇到大量新问题面前，当下的领域都是曾经遇到问题的形状，不一定适配新问题。领域间问题，会导致最后出现横向问题，但是横向问题，却不一定直接来自领域间问题。典型如性能，如果领域间互相推，最终在领域之间暴露出性能问题，可是各自领域管好自己家里事，依然会有性能问题暴露出来。 * 📖：架构师、兼职架构师、跨领域架构师 * 🤔：这让我有点迷糊，能对应初级、中级、高级嘛，似乎也不对劲。如果说架构师解决当下问题的技术方案，则兼职架构师就得解决当下加上时间轴这个维度后的技术方案，再则跨领域架构师更得解决当下加时间轴再加组织结构这个维度后的技术方案。当下+时间轴+组织结构，就是架构师在当下这个点、兼职架构师在未来这条线、跨领域架构师在组织之间这个面。架构师的当下需要技术深度的能力，兼职架构师的时间轴需要见识远度的能力，跨领域架构师的组织结构需要软技能加硬风格的实力。 * 📖：找不到任何乐趣的人，学不到任何真正的知识。 * 🤔：赞同+⭐️⭐️⭐️⭐️⭐️xN。我自己现在的学习和探索，就很受《发现你的天赋》这本书的影响。要去接触那些让自己激动的点，让自己起生理反应的点，那些地方可能就是自己的天赋所在。在自己的天赋指引下的学习和探索，就自然有无穷无尽的原生动力。在别人看来的所谓的坚持不懈，在自己的视角，实际上完全无任何坚持感，只有乐此不疲无穷无尽去折腾的劲头。

关于跨领域的软件开发协同工作，学生有一个天真想法，就是要设计一个工具，这个工具可以： 1. 前端可以模拟主要的核心的用户场景。在实际开发前，要确保终端用户的场景，是赞助者和决策者都需要的。并且确保整个架构活动过程，用户场景不能偏离赞助者与决策者的期望。同时也确保背后所有跨领域的开发团队，对即将交付给用户的产品有一个非常清晰的认知。 2. 这个模拟用户场景的前端，必然依赖于计划开发的API，对于未开发的API，可以通过polyfill或mock的方案应对。首先确保用户场景的全局统一。 3. 在前端界面不再有类似Jira的task或issue管理，只有API管理，一切开发围绕API的状态进行。例如API的状态会有：polyfill_mockup, delivered_without_test, delivered_with_bug, delivered_partially, delivered等。第1点描述的虚拟用户场景前端页面，在browser的console中，前端的中间件会打印出调用某API的当前delivered状态。 4. 基于API管理的其他属性有：依赖API，开发时长（根据依赖API的状态，开发时长的计算方法不同，可以作为对此API开发效率的一个参考KPI，目的是暴露出开发短板），用户场景覆盖率(也可以是测试覆盖率)，失效用户场景描述(可以上传截图和log)等等。 以上的想法还不太成熟，请老师和各位大神指正。