【大话IT】你离成为架构大牛有多远？

duke217

话题背景：

七夕虐狗日刚过，辛苦敲代码的你，是否也受到了朋友圈各种秀恩爱的狂轰滥炸呢？如果是，那么恭喜你，因为小编要继续往这个伤口上撒盐了……不过，这把盐也许会成为你“发粪涂墙”的源动力……

工作了挺久，发现有个挺有意思的现象，从程序员、高级程序员，到现在挂着架构师、专家之类的头衔，伴随着技术和能力的提高，想不明白的事情反而越来越多了。之前很多人问，怎样才能成为一名架构师大牛？今天我们就来聊聊这个话题。

问题讨论：

1. 在你眼中，一名优秀的架构师大牛应具备的最独特的能力是？为什么？

2. 从一般工程师到高级工程师，再到架构师。面对这种进化，你觉得架构师应不应该保持写代码的习惯？

3. 架构师 = LeaderShip + 高级工程师？你对这种观点怎么看？

讨论时间：

2016年8月10日-2016年9月10日

活动奖励:

话题结束后，我们将选取5个优质回复，各赠送精选图书一本。

更有机会获得SACC 2016大会门票一张哦~

这个秋天，和百位大咖约个会！

作为国内最受欢迎的架构师盛会，一年一度的中国系统架构师大会将于10月27-29日在北京万达索菲特大饭店撼世来袭！

大会以"架构创新之路"为主题，云集了国内外顶尖专家，共同探讨云计算和大数据等技术背景下，如何通过架构创新及各种IT新技术来带动企业转型增效。本届大会共设置两个主场分享时段，24个技术交流专场时段；邀请来自互联网、电子商务、金融、电信、政府、行业协会等20多个领域，150多位技术专家及行业领袖来分享他们的经验；并将吸引4000多名系统运维、架构师、及各种企业的IT决策人士参会，为他们提供最具价值的交流平台。

【大会详情】

官网链接：http://sacc.it168.com/

欢迎扫码关注SACC官方微信，获取最新信息！

invokermoon

难道没人么,在所谓的外企大公司见到一个所谓的架构师,代码水平简直连普通工程师都不如,但是也见到过已经百人之上的大领导,也每天都在坚持写代码.
都算这个行业混的不错的人.

ylky_2000

留楼。。。
1. 在你眼中，一名优秀的架构师大牛应具备的最独特的能力是？为什么？

2. 从一般工程师到高级工程师，再到架构师。面对这种进化，你觉得架构师应不应该保持写代码的习惯？

3. 架构师 = LeaderShip + 高级工程师？你对这种观点怎么看？

lipfy

架构师，首先他最起码知道每处的代码改怎么写，但是不需要自己写，这时候需要考虑的是可扩展性，兼容性，安全性，效率，速度等是应该架构师考虑的问题，最主要的是客户需求的可变动性，因为客户当时的需求是个定时炸弹，说不定哪天就会这里改变那里改变，这一步必须是要考虑进去的。架构师应该是写了很多年的代码的那个人，也思考了多年的那个人，最终磨练成。。。。

thinkeasy

1. 在你眼中，一名优秀的架构师大牛应具备的最独特的能力是？为什么？
综合知识能力，知识面要广，还要有深度。要做到四懂：懂开发，懂运维，懂市场，懂用户。
为什么？不用详说了，如果不懂开发，怎么设计程序，如果不懂运维，做出来的程序没办法维护怎么办？不懂市场，可能与老板要求相距太远，不懂用户，东西做出来用户不爽，问题也很大。

2. 从一般工程师到高级工程师，再到架构师。面对这种进化，你觉得架构师应不应该保持写代码的习惯？
必需要保持写代码的习惯，因为计算机语言也是在进步和发展的，一段时间就会有新的语言功能出来，要持续进步才行。
用句管理学的话来说，就是每天进步一点点。

3. 架构师 = LeaderShip + 高级工程师？你对这种观点怎么看？
我不同意这种看法，如果等式成立，那项目经理，CTO干什么啊。架构师的主要工作是将开发层次分配好，使做出来的系统好开发，好维护，用户满意。
架构师=高级开发工程师+高级运维工程师+高级售前工程师+高级美工
公式里为什么要加入高级美工呢？因为美工设计出来的界面元素并不一定能使用户和开发都满意，需要架构师进行协调。

fire_cpp

1. 在你眼中，一名优秀的架构师大牛应具备的最独特的能力是？为什么？
抽象能力、业务知识、扎实的技术知识和适当的更新速度，要能准确判断出支撑业务的系统会遇到什么瓶颈，并用合理的成本予以解决，能理解业务未来的变化与扩展，使架构拥有弹性与合理的扩展成本。
因为架构围绕的是业务，所以必须针对业务进行抽象，而业务是会扩展的、要求考虑成本的，所以这种抽象是必须适当的、能随业务合理扩展的。

2、一般工程师到高级工程师，再到架构师。面对这种进化，你觉得架构师应不应该保持写代码的习惯？
我认为，应该尽力保持写代码的习惯，这样才能接触第一线业务，保持感觉的敏锐、使知识不会随行业的发展而过时。即使不喜欢写代码，也应该让手不太生，适当写一点。
而如果一个架构师完全没时间顾及其他，我认为这是团队或公司管理出了问题——一个架构师怎么可以没有时间思考或干点“闲事”呢？太忙、太要求所谓的执行力，就会损害创造性——对所有人都一样。

3、架构师 = LeaderShip + 高级工程师？你对这种观点怎么看？
我不同意。因为他们主要思考的应该是比这更高一层抽象的问题。即使是写代码，也要适可而止——时间太宝贵。项目的推进、以及其它更具体的问题，应该留给项目经理或者高程去解决。
而如果所面对的业务是有成熟方案的，那么高程就能解决，用不着专职的架构师动手。
当然，“架构师”这三个字，有时和“产品经理”一样，在不同的公司做着不同的事情，没必要在这种问题上太纠结——你的价值取决于你所在的团体。

chenxing2

1. 在你眼中，一名优秀的架构师大牛应具备的最独特的能力是？为什么？
    理解需求/业务能力，对需求和业务理解不到位，后面很难设计出好的架构来，通常是基于需求/业务的边界先出业务架构
    软件架构能力，基于业务架构及工程的技术资源，做系统架构，包含比较多的知识（编程语言、软硬件、DB等等）
    架构推广能力，小公司还好，在大公司尤其跨部门时，尤其需要这个能力，推广不出去白搭。

2. 从一般工程师到高级工程师，再到架构师。面对这种进化，你觉得架构师应不应该保持写代码的习惯？
    架构师还是要写代码，更多的是框架设计时涉及的核心代码，业务代码应该不写了。

3. 架构师 = LeaderShip + 高级工程师？你对这种观点怎么看？
    这个每个公司对架构师的定义不同，对于架构师 = LeaderShip + 高级工程师，这种的架构师更像是技术经理，而不是架构师。
    现在架构师也没有明确的定义，各公司根据自己的情况决定架构要干的事。

东风玖哥

1. 在你眼中，一名优秀的架构师大牛应具备的最独特的能力是？为什么？

架构师具备的、而一般码农不具备的能力就是高超的整体架构能力，熟悉算法和设计模式，能写出适应任何具体业务逻辑的代码（抽象类和泛型等），提高整个技术团队的效率。

2. 从一般工程师到高级工程师，再到架构师。面对这种进化，你觉得架构师应不应该保持写代码的习惯？

随着技术能力的进化，写代码的习惯不应该被保持。而是应该改正堆砌代码量的习惯，尽量写具备可复用性、可扩展性、高兼容性、高安全性、高效率的代码。

3. 架构师 = LeaderShip + 高级工程师？你对这种观点怎么看？

LeaderShip + 高级工程师 = 技术经理，主要负责技术团队的建设和团队整体技术能力的提升，而架构师更多时候 = 高级工程师 ++ ，写最关键的整体架构代码和核心代码。

其实像架构师呀、专家呀之类的头衔、称呼在不同年代、不同公司也有不同的含义，同样是“写代码”这个工作的从业者，在70年代被称为“科学家”，在90年代被称为“工程师”，在当代被称为“码农”，而雇佣架构师的老板则在那三个年代分别被称为“反革命资本家”、“投机倒把”和“创客企业家”

duke217

回复 2# invokermoon

只能说，有的人，随着发展，就慢慢地忘记了自己码代码的能力了……
   

duke217

回复 4# lipfy

是不一定亲手写代码，但必须做到心中有码的境界么