支持楼主转，劝退一个是一个，https://www.v2ex.com/t/431308 第 17 楼

推荐 c#的这么少。。。 药丸啊

people need to grow up, people need to learn.

不要黑美的，美的是我见过的把质量控制做的最 nb 的家电企业，用料都是保你用到保修期刚刚好，要么挂掉，要么跟个拖拉机一样。

其实家电行业这已经是约定俗成的潜规则了，质量做的太好，你总是用不坏，也就不会再买新的，他们日子怎么过？不是我吹小曰本，家电要想用的省心，还是得买小曰本。

@gbin 你会发现中科大也挺难考的。。。

算是良心公司了，跟员工实话实说。一般日常操作应该是减绩效和奖金，这个合同限制不了。

我是老板我肯定喜欢裁员，一是能减少开支，二是对留下来的形成威慑，不好好干下个裁的就是你。所以欧美公司换 CEO 一般新官上任第一把火就是调整业务，合并或者出售，然后开始裁员。

@FrankHB 在欧美文化里，Architect 就是这个意思，很少的一个人或几个人领头挑大梁，这个本身也是来自建筑行业，就跟 Design Pattern 也是源自于建筑行业类似，Architect 也是来自于建筑行业。一个 Architect 负责一个建筑项目，一个 Architect 团队负责一个复杂的建筑综合体。BP 吹水这种事情大公司不需要，你说的情况可能体现在 PR 的文案里，就好比房地产某个项目一定会吹 xx 法国建筑师设计，这个也是存在的。中小公司所谓的架构师事实上是做了部分架构工作的高级程序员。

@FrankHB 我们理解的不一样，你不要被满大街的架构师的 title 迷惑了。我说的这个，是我直接打过交道或者间接了解到的 Architect。在这个位置上的人本来就不多，这个 position 要求就是这么高，就是要你面面俱到都得会，而在这个位置上的人也确实是有这个实力，能做到这一点，这样的人也确实是凤毛麟角。

Architect 这个 title 不是随便的人能担当的起的，那种中小公司自我标榜的架构师确实很多，但很多人做的事情其实只是一个高级的程序员的工作，做架构的不一定是 Architect，很多只是为架构添砖加瓦。这种很在某个方向上很厉害的一般是走技术专家最后成为 Individual Contributor，这个不跟项目绑定的，非常自由，专攻一两个技术制高点。

我说的这些技能，你不了解也很正常，因为本来都是屠龙刀这种级别的神器，一个大型公司一条大的产品线上也就一个，有的公司不缺钱会成立一个架构团队，而且是这条产品线达到了一定级别才会配的。

@gimp
@soulmine
然后剧情是 vue 和 react 互相指责对方是六耳猕猴 j ？ https://ws4.sinaimg.cn/bmiddle/62e721e4gw1et02g5wksrj200k00k3y9.jpg

@Yvette 写代码跟吃饭一样，最好是能吃上肉，吃不上肉吃菜也行，没有菜吃糠也能填饱肚子，但最起码你得做熟。
网上随便搜的代码丢给你 == 喂你吃生的。
调不过的代码丢给你 == 喂你吃含有农药的生的。
网上抄的，缩进不正确，格式乱七八糟，调不通的代码丢给你 == 喂你吃屎。
笑眯眯的把貌似能实现功能但内含深层次 bug 的代码丢给你 == 大郎，该吃药了。

exception：
一份包含类似 0x5F3759DF 的实现的代码丢给你 == 那是在给你进补，就不知道你这个小身板能不能挺住。。。

这几样每条线下去都是几个大坑。。。

三条路线应该是这样规划：
技术专家：C++语言 -> 算法 -> 数学 -> 算法库
业务架构：OOP -> 设计模式 -> UML -> 架构
系统专家：Linux 应用编程 -> Linux 系统编程 -> 网络 /高并发 /图形 /图像 -> 高性能基础设施
底层专家： \_______ Linux 内核 -> Linux 驱动

事实上，业务架构这条线，C++并不是很好的选择，Java 和 C#都比 C++好，C++在这里还是暴露了太多细节。
底层专家其实到最后更硬件的 datasheet，ISA，specification 等打交道比较多，用到的东西其实并不复杂，很多都是移位操作，寄存器操作，但是需要软件、硬件都了解。C 用的是最多的，然后是汇编。

不做个网页么？

@msg7086 不支持楼主的观点的，有一顶大帽子在等着你们-“乳滑”

你问我资不资兹楼主，我当然是资兹的，不转不是中国人系列又续写了新的篇章。https://ws4.sinaimg.cn/bmiddle/62e721e4gw1et02g5wksrj200k00k3y9.jpg

@FrankHB

https://www.quora.com/Do-big-IT-companies-such-as-Google-Facebook-or-Microsoft-use-business-and-or-software-modeling-tools-such-as-Enterprise-Architect

https://www.quora.com/Do-prestigious-software-companies-regularly-use-UML

没办法给你一份详细的内部需求做示例解释。如果你做过一些比较严谨的系统，比如大公司的支付系统，基本上离不开这些东西的。基础设施远不止 github 上 star 很多的那些项目，也不仅仅局限于互联网公司用或者不用的东西，就好比你说电动螺丝刀，电钻这种是基础性的东西，但更多的是水坝，高速公路，电站这种。

现在都是 SDN，物理带宽以下随便动动鼠标。那个氮气瓶加速也是这个原理，后台流量给你优化一下，QoS 什么参数改改，路由参数改改切到 cn2 专线上，或者更简单，改一下你接入账户的某个 tag，后面就全部搞定了。

围观 [贤者光环] 状态下的楼主，不知道这个 Buff 能顶多久。https://ws4.sinaimg.cn/bmiddle/62e721e4gw1et02g5wksrj200k00k3y9.jpg

说眼高手低其实并不过分，做架构本来就是一件要求极高的事情，相对于做业务类的架构，做基础性的架构要求更高，毕竟最后搞出来的东西不仅仅是一个产品，而是使用频率超高的基础设施。

@yangzhezjgs #1 楼说了很多技术上必须具备的能力，我再补充一点，还需要掌握 UML，SysML，熟练掌握泳道图，时序图等，对 OOP 有非常深入的理解， [精通] 各种设计模式，工具上要熟练掌握 Enterprise Architect。基础性的东西为了追求性能，很多都是直接用 C/C++写的，如果系统足够复杂，会用到自动代码生成，这部分又是一大堆东西。
然后，这都只是工具和手段，比这些更重要的是你的思路和思维方式，考虑问题是否全面。

除了上述实现上的考量，你还要考虑可扩展性，可维护性，系统鲁棒性，安全性等其他各种方面的问题。

此外，除了上述技术方面的考量，你还要考虑成本，后续实现的人力开销，用了第三方的组件或者第三方的服务还要考虑知识产权和法律风险，考虑第三方缺失带来的风险，还要考虑如果整个系统挂掉了的应急和备份方案。

一个优秀的系统一定是一个或者一群厉害的架构经过千锤百炼打造出来的，做架构的不仅要求知识面广，而且各个方面都要足够深入，所以不是新手三两下能倒腾出来的。

当然，我也不是为了吓唬楼主或者劝退楼主，事实上架构也是从新手村出来的。对于想学习如何做架构的人来说，最好的方法就是从一个小一点的系统做起，循序渐进，不断改良，不断寻找 Best practice，同时自己也会逐步提升。

@higoge 你的联想 K410 内存多大？是 8G 吧，不是 80 吧～

楼主想多了，这不是有没有 App 这种客观条件造成的问题，而是有没有执行力这种主观条件造成的问题。

所以，然并卵，还是把时间和精力用在钻研算法等有意义的事情上吧，不要浪费在这种并不存在的需求上面。