S'S ALGORITHM

总结一下项目中得到的心得

在bizreach的测试

あなたは諦める心を知らない追求者です。

自分の決めた分野を追求できる仕事にモチベーションが高まります。周囲から専門家としてのアドバイスを求められればそれに応え、自分の専門性を通じて組織に貢献できることにやりがいを感じます。スペシャリストとしてどこにいっても通用するような知識やスキルを身につけたいと考えており、普段から仕事に関する本を読むなど研鑽を重ねることに時間や努力を惜しみません。多少厳しい環境であっても、周囲から刺激を受けて成長できるような職場を好みます。また、仲間と力を合わせて共通の目的を達成させることを大切にするタイプでもあります。自分が前線で目立つのではなく、目的達成に自身が貢献できていると実感できることを重視します。専門性の高さから、周囲からの信頼も厚いです。自分の時間を犠牲にしてでも、周りからの期待や要望に応えるような献身的な姿勢も強く、仕事を抱えがちになってしまうことも多い傾向にあります。

働くことにおいて優先度が高いのは仕事内容に関する要素で、将来、起こりうるリスクに備えたり、現状を確実に維持し引き継いでいくような安定した仕事を重視しています。また、仕事において自分なりの基準や納得感を持てる仕事を重視します。職場環境に関する要素については、一緒に仕事がしたいと思える優秀な人材がいるかどうかや、その環境下で刺激を受けられるかどうかを重視します。また、企業理念や価値観に共感できる職場・会社にも魅力を感じます。

仕事をするうえでの能力や仕事へのスタンスとしては、仕事や課題に対する遂行力・対応力が高く、仕事に対する積極性もあります。相対的に、周囲とのコミュニケーションはあまり得意ではないかもしれません。特に、課題解決力の情報収集力が高いです。傾向として、短期間で幅広く確かな情報源から豊富な情報を集め、まとめることができます。一方で、コミュニケーション力の人脈・関係構築力については低い結果となり、改善の余地がありそうです。傾向として、交流の場に出向いて人脈を作ることに消極的なようです。初対面の人とうまく人間関係を作り上げることは苦手かもしれません。また人を見抜く力がやや弱いかもしれません。

平等交流，直抒己见

和藤原老师的交流让我感受到，开发者或者谈论问题的时候，诚实表达自己的意见，并且只是为了促进事件发展的交流是必要的。

思想和想法的碰撞，比礼节尊卑更重要。

我没有很好滴理解客户的话，矢部さん的话，这是对系统整体没理解的原因。

交流中的范畴，侧重点，个人想当然问题

交流中容易发生的问题：歧义，听者侧重点不同，个人感情掺杂，没搞清范畴，缺少理性思考。

作为听者我们听到的句子中的重点，可能和说话者想表达的重点不同，我们需要的是再次确认。

个人感情，通常让我以为对方应该和我一个战线，但是对方可能在理性思考，这时候可能会让我听到刺耳的内容，失去了理性和镇定。这是不需要的。

范畴在于，是在整个世界范围内适用的，还是当前小群体范围的规则，后者没必要苟合，前者则可以学习。

理性思考永远很重要，不要太在意别人怎么看，而是在意如何将这件事推进好。

挫败感

（24/06/25）

可能是一种挫败感吧。如何才能和藤原老师比肩呢。我也不知道，总之就是很挫败，只能默默努力了。

数据ETL处理项目的前瞻性视角 & 以及和member分享和学习的心得

（24/06/17）

关于ETL项目处理：

• 很多问题可以在前期清理。
• 数据整理和分类，数据源的方式，手动还是定期cron推送，都会影响后续的处理方法。
• 数据处理ETL基本上分为的就是event处理和schedula处理，也是根据前一步的数据源和项目最终数据需求决定的。
• 数据仓库mart怎么处理，是在raw数据后直接进行处理还是定期处理也有讲究。在raw之后处理的话，或者不定期无法进行schedula的设置，那么就是需要绑定在raw数据处理的后面跟着进行。
• mart存在的方式，是table还是view，还是materialized view都有限制，有些数据库的mv不能随便修改原本的table，要注意。使用view则会影响用户获取数据的速度。
  • 追求更高的执行速度，就使用DM和view组合，来代替materialized view，使用了MV的情况要考虑参照的表的变动，是否会损坏MV
  • 如果只是简单的filter columns，那么view就OK，可以handle了

关于和member分享心得：

和更有观点的人交流，将心得总结，然后分享给别人，是一种非常好的学习方法。

如果将自己作为项目的主人一切都会变的主动和有掌控性

（24/05/30）

• 也许是因为藤原老师全权授权我自己放手去做的原因，这种感受到自己是项目的主导者的感觉，开始推动自己去主动做事。
• 将重点放在主要的任务上，从关注别人的心情，到关注项目本身，从猜测别人的想法，到直接问和直接表达，也许更适合我，不，正是我的风格。
• 也许以前是因为一直在藤原老师的手下进行代码复用，这次终于可以自己随意开始按照自己的想法和理由进行代码组装和实践，这是一种不小的进步，我觉得开始变得自由了。这很感谢藤原老师。
• 果然，将项目作为自己的学习实践的一个部分的心态是一个很正确的选择。只是进行学习不实践，人会变得认知分裂，我很确信，虽然我学习的很多内容也许和项目内容不相关，但那也只是直接不相关，在底层的思考方法上，完全可以迁移使用。而且在自己的学习中，使用的代码，只是用dummy数据跑的代码，而且以机器学习代码为主，只有在项目中，才能摸到完整逻辑的业务代码，这也正是我需要的。
• 如果想清楚了很多东西，项目也会变成学习的一部分。工作则消失了。
• 学习中的思考方法，会帮助项目，项目中得到的经验会反过来加速学习。原来这就是1 + 1 > 2的效果。我希望之后会变成指数效果。

关于误删了客户table的事件

• 生产环境的作业不适合和其他人一边说话一边随意完成。需要自己认真检查代码，然后执行。
• 最小程度的减少对生产环境的作业。
• 权限管理很重要，最小权限原则。

关于项目推进上的感想

• 交流很重要，一开始的沟通，工具，会议，人员配置，都是学问。如果你能承担起一个项目，也许就能搭建自己的系统，从要素型生产变为系统型生产者。这可能就是项目管理的魅力。
• 之前的案件我和上司两个人没有认真的设计也没有认真的测试，直接就走到了运用阶段。这是不太正规的行为。
• 虽然不喜欢做资料，但是要理解的是，做资料只是一个整理的行为，他们是工程中必不可少的过程的一种指导和证明。那么就留下更多的template作为自己的武器吧。同时更加是一种训练自己思考方式的方法。
• 思考更上层的东西，不只是这一个案件，而是将整个过程抽象化，那么无论做什么项目，都可以进行框架的套用，升级，修改。
• 工程师的觉悟的培养，离不开琐碎的工作。开发者和项目管理是两个不同的概念，他们考虑的内容不同，同时也有交集，那就是对技术的理解，开发者关注的是系统或者应用的性能，反馈，结构，最佳实践。而项目管理，是对整个工程的协调，项目管理也需要有技术才能判断这样的管理是否合适，同时信任开发者。
• 一个人只有先有技术，然后再去做项目管理。
• 这么来思考前一个项目和现在项目的关系，前一个项目的经验就好像是PoC，然后将那个经验拿过来放到现在的项目中来用。但是如果本身就是一个新的不懂的项目，就可能需要一个PoC的过程了。

关于权限申请/阅读doc的实践经验

这次（24/04/12）发生的问题前置情况：

• 整个项目的云环境的权限是通过向管理者申请相对应服务的权限实现的。
• 我们需要从AWS环境的Redshift，传送数据到GCP的Bigquery。GCP的Bigquery有一个功能data transfer。
• 管理者是通过Terraform进行权限管理的，如果发生环境改变，他会自动修复为定义好的环境。
• Bigquery data transfer内部默认使用内部的服务账号进行作业。
• 这导致我们虽然在定义作业的时候没有看到内部的服务账号显示，但是在执行的时候，内部系统自动为内部的服务账号进行了权限赋予，方便它对BQ对dataset进行数据写入的作业。
• 对方的管理者检测到了这一行为，对我们提出了警告。

最终解释清楚了但是实质上是我们没有调查清楚，要请求内部服务账号的权限才可以。

总结起来有如下经验：

• 对于官方的Documentation的阅读，不要只看片面的一页，如果没有时间阅读所有，则向周围或者上司请求复查。
• 即是是复查也可能漏掉，所以可以从如下步骤进行检查：
  • 权限行为主体：是人还是service也就是代理。
  • 主体行为如何：主要是代理行为，如何进行认证和授权的，整个流程如何，要自己理解清楚。
  • 数据的流动路径：从A数据库到B数据库，那么两边都需要权限吗。

构架师技能栈

成为一名优秀的架构师需要结合技术能力、实践经验和软技能的全面发展。

1. 深入掌握基础知识
   • 计算机科学基础：数据结构、算法、操作系统、计算机网络等。
   • 编程语言：至少精通一种编程语言（如Java、C++、Python等），并了解其他几种。
   • 数据库知识：关系型数据库（如MySQL、PostgreSQL）和非关系型数据库（如MongoDB、Redis）。
2. 深入理解架构设计原则
   • 设计模式：学习常见的设计模式，如工厂模式、单例模式、观察者模式等。
   • 架构风格：了解不同的架构风格，如微服务架构、SOA、事件驱动架构、RESTful架构等。
   • SOLID原则：单一职责原则、开闭原则、里氏替换原则、接口隔离原则、依赖倒置原则。
3. 不断学习和实践
   • 项目经验：通过参与不同规模和复杂度的项目，积累实际经验。
   • 开源项目：参与开源项目，了解社区最佳实践。
   • 读书和学习：阅读经典书籍，如《设计模式：可复用面向对象软件的基础》、《架构即未来》、《企业应用架构模式》等。
4. 关注新技术和趋势
   • 云计算：了解AWS、Azure、Google Cloud等主流云服务平台的架构和服务。
   • 容器化和编排：熟悉Docker、Kubernetes等技术。
   • DevOps：了解CI/CD、自动化部署、监控等实践。
5. 提升软技能
   • 沟通能力：能够清晰地与技术团队、产品团队、管理层沟通。
   • 领导能力：能够带领团队解决复杂问题，做出技术决策。
   • 问题解决能力：具备分析和解决复杂问题的能力，能够快速应对突发状况。
6. 寻求导师和网络
   • 导师指导：寻找有经验的架构师作为导师，学习他们的经验和教训。
   • 专业网络：参加技术会议、研讨会，加入相关的专业组织，扩大你的人脉网络。
7. 制定职业发展计划
   • 目标设定：明确短期和长期职业目标，制定实现这些目标的计划。
   • 持续改进：定期回顾和评估自己的进步，调整学习和发展计划。
8. 实践和反馈
   • 项目迭代：在实际项目中不断应用所学知识，获得实践经验。
   • 反馈循环：从同事、导师、团队中获取反馈，不断改进自己的技能和方法。

系统架构和软件架构都是复杂IT项目中的关键组成部分，但它们侧重的层次和细节不同。系统架构更关注整体IT环境和硬件基础设施，而软件架构则聚焦于应用程序的内部结构和代码组织。两者相辅相成，共同确保系统和软件的成功实施和高效运行。