工作随笔
关于业务知识
第一次感受了最密集且比较系统的培训，能明显感受到公司层面对于培训的重视。当然对我们学员也非常严格的，以多次串讲、考试等形式对我们进行考核。我们同期培训的同学都一致认为这强度和压力跟「高考」差不多，所以很多人基本都把周末时间充分利用来复习培训内容了。过程虽然有些披荆斩棘，但最后收获良多，比较系统的掌握了公司的很多业务知识，能在日常工作中与其他同事无障碍沟通业务知识
密集培训业务，包括现在我们大团队周例会分享的一些业务实现，熟悉了业务知识，我觉得至少有以下几个好处
- 能在日常沟通中更顺畅，不至于鸡同鸭讲，听产品讲 MRD 云里雾里，很容易漏掉一些产品经理没有提到的隐形开发需求（影响范围），最后让自己排期不准确，工作量估算过大或过小，甚至做出的东西根本不是产品经理想要的
- 技术应该服务于业务（商业）价值，我们只有更好的理解了业务，才能选择出最适合的技术方案，而不一定是最好的技术方案
- 帮助我们程序员知道，我们在做什么，为什么这样做，还可以怎么做，增加对自己所做事情的认同感，有时候产品经理的提出的一些需求不一定是逻辑严谨的，甚至技术实现上存在矛盾，我们技术人员也可以站在最终用户的角度提出一些更合理的产品建议，而不仅仅只是一个需求翻译官
关于专业技能
参加了几次敏捷迭代需求开发，能够通过自主学习和向同事请教，快速掌握相关业务知识，对涉及的功能模块的上下文、依赖项做比较好的把控，可以独立完成开发过程，并对一些产品设计问题提出改进意见
关于高效的一个姿势
对于我们的敏捷迭代开发，我认为多数需求的改动都不是特别大，最明显的是需要修改的代码量不会特别大，但在修改前往往需要摸清需求的影响范围，如果需要重构之前的一些不够优秀的代码，更需要花很多的时间去梳理清楚上下文。如果这个过程中遇到疑难问题，我觉得最好最快的方式是向懂这块业务和技术的人请教。虽然自己也可以通过慢慢打断点，单步跟踪，打 console 日志，断言试错，查看堆栈调用记录等方式摸清一个复杂功能的逻辑，但如果自己花费了半天甚至一天，都卡在一个点上，那就太不高效了
关于提产品优化意见
前段时间 excel 数据更新这个需求，刚开始我看到 MRD 的时候，很苦恼怎么去实现，需求是在一个 table 拖拽某一列到特定（原始字段）区域时，不仅显示灰色遮罩层，还额外在合适列头下显示一个提示 tooltip 的需求。从技术的角度来说，它应该是可以实现，但实现成本是非常高的，技术难度确实很大。后面仔思考，我发现这个 tooltip 其实是可以不必的，因为这个 tooltip 的目的是告诉使用者不能把列拖放到这个区域，但这个需求里面已经要求在这种拖拽状态下，原始字段区域显示置灰遮罩层，且原始字段的分组标题上有明确的文案描述「不能把新字段拖拽到原始字段区域」，额外的 tooltip 其实也是为了表达同一个意思
言下之意我们用了 3 种不同的方式告诉用户不要那样操作，我觉得用过多的 UI 元素来表达同一个意思是不必的，堆砌那么多特效反而会让界面显示不够简洁；所以后面我与产品和设计同学电话沟通后，大家一致同意可以把这个多余的 tooltip 特效拿掉，这样就轻松的解决了问题
我的一个理解是，解决问题的方式不一定都得从技术角度，换一个思路和方式，或许能柳暗花明
关于调研新技术
10 月，我的主要工作是调研 ag-grid 这个号称全世界最强的 js table 库，目的是为了实现我们 SDG 的 2 个需求，为了能在更多相似业务场景下能复用，所以决定做成单独的一个组件库，在这个过程中，我有下面两点感触
- ag-grid 虽然异常强大灵活，但针对我们特定的需求还是有很多地方需要改造，且由于我们还要加入表单嵌套子表单，校验，自定义单元格内容等复杂功能，只依靠 ag-grid 这一个库肯定不能完成所有需求，还需要整合其他三方库来一起协作才能输出我们要的功能。所以在开发过程中，为了让多方库「友善」的工作在一起，不仅要熟读各个库的帮助文档，还要上 GitHub 看源码摸清楚各自的「习性」，最后在无缝的整合他们，这中间遇到的问题和困难还是挺多
那段时间，每天下班很容易因为解决了某个问题产生一点点成就感（欣喜感），但第二天又要面临一些新问题，只能慢慢适用（理解）它的节奏（原理），做大量的尝试和推断后，才可得到自己想要的结果。
这里的总结是，要做好一件事，打磨出一个接近完美的东西（90 分以上的产品）是很难的，它至少需要有工匠精神，花很多时间去尝试和试错，不断地思考和总结 - ag-grid 它有社区版和企业版，像这种专业做组件库的公司，技术本身就是业务，他们的帮助文档非常细致，且大多数特性都会给详细的 demo 展示，这对使用者（用户）是非常友好。这或许也是被业界广泛使用的原因之一，很多东西之所以谓之好，优秀的文档是必要条件。而对于我来说，之前文档能力比较弱，也不够重视，所以在编写文档过程中，往往反复修改了好几次才 review 通过。通过这段调研工作，更新了我对文档的认识，后续需要不断学习和加强，尤其是输出给用户的文档，需要重视描述事情的逻辑性和完备性，且其中还有很多写作技巧，应多站在（小白）读者的角度去思考，描述是否准确无歧义而又通俗易懂
