从技术到架构：互联网支援的反思与学习
文章讲述了作者从大数据部门调入互联网部门支援项目的经验，涉及低代码架构的学习、技术服务于业务的重要性，以及对互联网部门工作环境、敏捷开发和外包问题的反思。作者强调理解业务场景和技术背后的架构，以及自我提升的时间管理问题。
一件悲伤的事实，这两周，成长值为零～～
从大数据部门临时抽调到互联网部门，支援重构的“配置下单”项目。
一个变种的低代码架构设计，唯一比较有意思的是它的业务组件的设计与校验设计，算是学习到点东西吧，其余的时间都是赶工中度过～～
一、价值
（一）架构
有幸与公司的前端技术高经聊天，向大佬请教架构师之路，大佬给的建议。
- 技术是为业务服务的。API 学习是基础，但不是重要的，重要的是要懂这个新技术解决了哪个业务场景。
- 深耕业务。深度熟悉某一类业务是架构师的必走之路，比如活动秒杀设计、低代码设计
- 前瞻性。拥抱变化，做设计时需要考虑后期的扩展，更友好的支持。比如：服务人数从 1K 扩展到 1W、新加功能特性
这些是建设性的建议，真正落地还是有一段路要走：
了解技术背景
一个新技术的出现，必定伴随着特定的业务场景，在这个独特的业务场景，持续完善这个技术，最终才会有面向世人的技术.
反思：通常看到一个技术时，会首先一股脑的去学习 API，反而忽略了最本质的东西。
透过技术学习架构
一个好的技术，必定伴随着一套稳固的架构设计。空谈架构有点虚，可以从一门技术的设计，慢慢去学习它内在的架构。学习它、模仿它、使用它。
很好的例子，Vue 中存在双向绑定，React 中为何一直没有双向绑定呢？
打破限制
每一个小的业务做到极致都是一项很庞大的版图，像数据、日志、队列、资产等。架构的本质是为业务服务，打破技术人的边界思维，敢想敢做，是否可以更进一步、再进一步呢？
（二）互联网
不曾真正在互联网网络做过事儿，这两周支援互联网部门，明显体会到不同的气氛。
怎么说呢，互联网部门与内部系统部门，最直观的感受，就是互联网部门更有朝气，使用最新的技术、说着最潮的行话、下最晚的班。
互联网部门是善变的。作为直接对接用户的部门，一个需求、一周变化个两三次都是有可能的。不要担心，会有一堆小伙伴陪着你加班，UI、UE、产品、开发…
互联网部门是自由的。完全基于敏捷思想，快速迭代，以最终产品说话。
（三）外包
不得不说的一件事儿，要远永避开外包、避开外包、避开外包…
需要支援的项目，工期紧张、任务繁重。所以，一件很悲伤的事儿，就是没人关心支援的人是否了解项目，也不需要支援的人了解架构、业务，按照人家已设计好的架构填空就行。
外包的滋味十足，基本上天天在赶工，整个人都在透支中…
二、反思
连续两周未有效读书了，一直给自己找借口。觉得加班忙，所以可以谅解。啊哈哈哈哈哈
时间总会有的，懒而已
扫一扫
556
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
