个人不完全赞同这句话

架构和方向不应该朝着“高精尖”的方向走，那不应该是目标，“合适”的，才是最好的

这句话很容易被一些不思进取的程序员甚至架构师利用来做偷懒的借口

举个例子吧，
就说Windows系统的发展，
最开始大家坚持用98
XP刚出来的时候被喷，最后大家还不是都开始用XP了。
后来Vista出来了，微软不给力，系统差强人意，还是很多人不用Vista。
再后来Win7出来了，前XP党们又转投Win7了。
而现在Win10出来了，Win7党（前XP党）们又开始“坚守阵地”了。。。

这其中值得思考的点是：
有人在喷新系统，但最后又不得不被push去接纳新系统。

还有个问题留给大家：
Windows Vista真的不如XP么？

那么既然要接纳新事物，为何非要被动接受，而不抱有主动地心态呢？

如果仅仅是固守在“合适”的舒适地，那么，用现在流行的一句话，“时代抛弃你，从来不说再见”

• 最开始寥寥几个JS和静态资源就可以直接完成项目，老板觉得你干活又快又好
• 后来出了grunt/gulp/webpack，你可以说项目不需要，扯出一堆不想改动的理由。
• 再后来ES6/Babel出来了，你依然说项目不需要，配置巨复杂，还要额外配置webpack。。。
• 再后来Vue/React出来了，你依然说迁移成本太大，还要用webpack/ES6/Babel，不适合现在项目。

那么问题来了，从现在来看，那个最开始到现在都一直没改动过的项目架构，
现在看来是合理的么？那还改不改？什么时候改？
你要招一堆新人过来给你写jQuery？

任何改动和升级必然是有风险和成本的。你不能因为这些就停滞不前了。
至于成本和风险，是优秀的架构师和开发者应该去宏观思考和解决的。
关于风险，没人逼着你带着一堆BUG去切换新技术，
再退一万步讲，任何方案和风险都是提前要评估的，
如果真的有无法解决的问题，那时再终止迁移方案，也是可行的。而不是什么都没做，就开始否定新技术。

面向未来，也是架构师最基本的素质吧，不然不就是鼠目寸光了么？

from article.

说得好！

from article.

赞！

from article.

赞

from article.

全局意识，抓精抓细，接地气，是“架构”团队最应该注意的三点。

from article.

点赞~我一直都在强调：不在于什么新技术，适合团队的才是好的架构

from article.

赞！

所以，架构和方向不应该朝着“高精尖”的方向走，那不应该是目标，“合适”的，才是最好的。

很赞同上面那句话。

from article.

棒

from article.

“在适当的时候，遇上对的人。”我喜欢这句话

from article.

赞一个

from article.

赞赞赞！

from article.

这才是踏踏实实做事的人说得话

from article.

po🐷的心里话

from article.

很赞，在适当的时候，用适当的方案去做对应适当的事情。
最近换了公司，从一个小的全端团队，再次回到前后端分离的前端团队中。
真是不同的团队推不同的事情。

from article.

架构的本来目的就是为了解决当下存在以及未来可能出现的各种问题，如何做到架构需求的实时回归（从一线反馈的需求）这个是个问题

from article.

• 全局意味着 - 清楚的知道团队在当前阶段应该做什么事情
• 全局意味着 - 清楚的知道团队的现状，优势和问题
  • 不至于高傲的迷失了方向
  • 也不至于卑微的找不到出路

赞

from article.

赞
沉下心来

from article.

很赞

补充一点个人理解。
架构组还有一个相对隐性的职责，是面向未来。业务关注的是未来三个月的表现，架构至少要看到未来一年的可能，看到进化的方向，制定计划推动进步。现在火热的 ES6 实践应该大都是基于这个动机，至于是否恰当，还要看团队和业务现状以及信心。

在未来技术上的投入可以看成是微型的风险投资，收益和失败几率成正比，选择一部分余力来做还是倾囊而出，有时候还真分不出孰优孰劣，但是看到身边有大胆的人勇猛地冲怎么说都是件值得高兴的事情。前端这些年的迅猛进化，离不开这些冲动的高手们。

from article.

BTW，
有时候架构工作可能会碰到个问题：如何证明这些架构工作的意义，它给公司带来多少好处，多大价值？发问可能来自于兄弟部门，也可能来自上级老板。

业务部门的指标都很明确简单，对于架构而言性能提升和基础库搭建的作用比较明显，其他工作内容的价值就不容易衡量了。在某些糟糕的情况下，甚至衡量的重要性要超过内容本身，这也算是团队的生存现状，也是架构组需要考虑的内容。

这个问题放在前面的论述里来说，属于横向全局的考虑，也有点类似开放透明所要解决的问题。

from article.

@amio 我其实蛮钦佩勇敢往前迈进的决策者和团队的

from article.

说的不错，赞一个

from article.

我们小团队前后端分离好痛苦，环境构建确实带来酸爽，架构方面只能慢慢摸索，需借鉴你们的经验:)

from article.

赞！喜欢这句话：在适当的时候，遇上对的人

from article.

赞

from article.

赞~

from article.

能看出来 是用心在写文章 很有意识 有机会请你喝酒哈

from article.

写的真好！

from article.

个人理解架构解决主要问题就是规范 效率 质量

from article.

不求高精尖，但求合适
说的好！

from article.

合适:合得来 ，适配的又好。。。 赞

from article.

终究还是造了个轮子。。。

from article.

在适当的时候，选择适当的架构，随着业务的扩展不断进化。

from article.

不是前端，以后慢慢看

from article.

看到前言就赞，同感的前端人

from article.

里面几个链接都挂了，能修复一下么？

from article.

@banditsmile 文章中的几个链接是指向公司内部网络的链接，所以使用「脱敏」指代，无法打开。

from article.

‘架构和方向不应该朝着“高精尖”的方向走，那不应该是目标，“合适”的，才是最好的’

其实这句话说的不够准确，“合适”确实是比较精深的词，我们也应该明白“高精尖” 和 “合适” 是不矛盾的，其实，在技术选型期间，我更优先考虑这些高精尖的东西是不是符合目前的场景，当然这也是一个权衡利弊的过程，毕竟新的东西有TA的优势，也有TA的弊端，如果要弥补弊端的代价大于优势带来的好处，那就可以定位这个“高精尖”不符合目前的需求，也就是所谓的不“合适”！

from article.

赞一个，合适才是最好的，而不是使用什么高深的技术。

from article.

用心在写文章，赞

from article.

good!
thanks

from article.

gooddddddddd

from article.

赞。。

from article.

赞！发人深省，自叹不如~~

from article.

看来，架构师和全栈比较接近了

from article.

踏实做人!

from article.

说的话，说到点子上了

from article.