我们的挑战期待很高
优秀的公司都对体系结构抱有很高的期望，想要优秀的顶层设计，自上而下有统一的认识，遵循共同的规范，编写舒适的代码，即使偷懒，“最辛苦”的体系结构设计会永远持续吗？
但是，高期待意味着高落差，面对落差容易不安：
说到什么时候能写代码，本来应该是这样的； 现在怎么像在爬“屎山”呢？
文件什么时候能写得简单详细； 现在怎么容易理解，又详细又有很多余地呢？
道具什么时候能更强地使用； 现在怎么脱不了链条，没有想要的功能，等着排行榜这么多年吗？
“我”什么时候能从架构工作中找到成就感？ 做了之后不是会考虑跑步吗？
责任重大
很多问题的最终原因是代码问题。 设计不合理，使用方法不准确，逻辑模糊，“漏洞”太多。
没有单个团队负责这些问题。 我们受到了很多“吐槽”:
这个尼玛是谁写的，不堪入目。 看着爷爷推倒后再次展现出真正的实力
XX在这里埋了雷，但XX已经无关紧要了。 事到如今，我也只能兜风了
你不应该这样使用。 本来的设计不是为了这个场景。 你在责备我吗？
卧槽，这尤其是绝招啊。 编译的时候偷偷改变了老子的代码。 找盲目也没找到渗透到哪里
另一方面，口齿清爽，我们“吐槽”历史代码的情况暂时缓和了； 另一方面，这意味着责任也传达给了我们。 处理好的话，我们的生产可能还是同样被视为糟粕，处理不好的话，我们就会毁掉业务发展的前途。
工作很难
体系结构面临的不是单一的业务问题，而是多方合作的交叉问题，负重前行是常态。
工作延年益寿，历史重负下又有新的场景，随便动小刀就会拔萝卜泥。 例如，前2021年10月的版本拥有XXXX组件，比一年前翻了一倍。 班级数XXXXX； XX个插件； 仓库数XX个； ttmain仓库权限XXX人。 (XX表示订单，隐藏了具体的数字。 ^_^ )
技术堆栈层出不穷，既要保持成熟稳定，又要积极探索落地。 架构的学生必须熟悉多个技术堆栈。 例如，在客户端业务中，往往有多个技术堆栈共存。 在H5/hybrid/applet/lynx/flutter业务中使用哪个技术堆栈进行托管需要多少成本？ 选定技术堆栈后，有什么局限性，无法逾越的障碍吗？疗效慢
我们经常把代码复杂度高、降低复杂度作为体系结构方向的重点工作之一，但影响复杂度的因素很多，从外部看，有主观感受、客观指标、行业目标三个角度； 从内部看，有三个角度：工程组织、代码实现和技术堆栈。 即使很好地优化了工程结构这一因素，也很难在短时间内感觉到复杂性明显降低。
我们常说治理，其实是设计机制，在这个机制下运行到治愈为止。
就像老中医开的处方一样，不是特效药，而是开应付病症的方法。 是否是有用的处方，最终需要通过实践和时间的验证。 为了不成为庸医，随便抓几瓶药炖一下，就会吹嘘到药生病为止。
文/蓝盟IT外包
中文
电话咨询
微信咨询
公众号
