太仓网站开发建设服务,福州 网站开发,vps怎么建多个网站,建自己网址的免费网页架构师是个很神圣的词。盖茨#xff0c;世界首富。微软#xff0c;世界最大最富有的软件公司。盖茨是微软的首席架构师。 好多程序员流口水#xff0c;一听某人是架构师#xff0c;就两眼发亮#xff0c;比技术总监的头衔还要厉害。 一想起架构师#xff0c;大家就想起那…架构师是个很神圣的词。盖茨世界首富。微软世界最大最富有的软件公司。盖茨是微软的首席架构师。 好多程序员流口水一听某人是架构师就两眼发亮比技术总监的头衔还要厉害。 一想起架构师大家就想起那些UML设计工具、类图、时序图想起那些水泥大楼的框架和地基想起了那些 如百变金刚的开发平台想起了那些让人眩目的反射、元数据、FrameWork、设计模式、面向对象、重构。 很多人想当架构师感觉架构师是技术职业发展的最高境界在往上走就有管理职能了如技术总监和CTO或 研发总裁之类的头衔。 李维先生曾经有过一次演讲讲到了一个架构师应该具备的特性 1核心软件技术。要攻克数据库设计问题必须深入了解数据库的工作原理而不是会写复杂的SQL会管理个 备份会设计个表结构就算精通数据库。有人甚至把会用hibernate/structs/spring当作自己会核心软件技术 。 2产品特性。你学了那么多核心技术到底要干吗我一直在商业软件公司工作没有在研究所工作过。我各 种技术要做到的就是帮助企业软件生产如何更快更省力气质量更好市场竞争力更强。我总是以这个原则来 验证一项技术是否对于我的工作来说而实用。现在技术多如牛毛在各个层次各个领域解决着各个环节的问 题。如果不以解决自己工作中的问题为圆心很容易陷于到大量学习却越来越茫然找不到出路的境地。 3软件趋势。在企业管理软件开发领域往往会见到这样的现象不少开发人员精通客户业务需求深入第一 线做客户实施。他们学习技术也是为了解决现有手头的问题。尤其企业管理软件开发领域技术要求并不高 而如果不了解客户需求开发的软件实用性就不强即使你的功能开发的又性能好又安全性好也没实用意 义。所以不少在企业管理软件开发领域工作多年的开发人员形成了技术轻视观甚至有种核心技术学习 无用论的思想。但企业管理软件开发领域经过十多年的发展已经面临了不少挑战。但是很多人觉得那是 大环境的事情大环境不是一个人一个公司能改变能影响的。大环境变咱们就跟着变。大环境不变咱也 照旧。但是我已经经历过了很多时代见证了很多遗憾大环境发生改变了自己却跟不上了。 DOS/WINDOWS时代、单机/局域网时代、互联网时代、移动增值时代。每一个时代都出了黑马赚取的金钱突 然高出传统模式数倍而传统模式者还是在继续走传统模式辛苦的赚钱而且随着价格战的加剧越来越 辛苦但还不思改变者并且还认为不可改变者大有人在。 4创新技巧。我们往往会遇到这样的情况要解决手头的问题摆在面前的有N种技术方案。选择哪个都有缺 点综合来用又感觉牛刀杀鸡了。有时候我们还会遇到另一种技术选择未来的软件趋势一定是那样那样 的但现在还没有达到现在的技术方案都是过渡期的所以我们还要等。否则利用现在的过渡期技术开 发出来就被淘汰了。如果是这种以现状看技术的思路不管技术发展到什么阶段都有遗憾都在向未来的 未来过渡。所以作为一个架构师比别人厉害就厉害在总是能把手里这些技术巧妙的利用以解决自己 的问题。当然你想把你手中的技术能用活你必然是理解这项技术的来龙去脉和这项技术的适用领域还 要深入理解这项技术的工作原理还要清楚的认识到你要解决的问题领域否则你无法把你的技术和你要 解决的问题结合在一起。 我对李维先生的这四点讲述颇为赞许。架构师总是游走在技术和业务之间既要兼容软件历史不能割裂又要 面向未来发展所以我老把架构师称为走钢索的人。 很多人也想成为具有这样特性的架构师但就是不知道该怎么走这条路。我就讲讲我的经历。 我刚出道的时候很快成为公司技术出众的程序员。有人跟踪调试了一下午也找不到错误的找我有人不 知道这个错误是怎么引起的找我有人不知道某个需求怎么实现代码方便找我有人要优化数据库性能 但怎么都速度提不上去找我有人要修改一段超复杂的代码怎么也理不出来N多判断和函数嵌套脑 袋思考不过来了对代码的复杂度掌控不了了找我 我就跟一个活雷锋一样大家也好像觉得我就是个活字典有技术问题找我总没有错。就这样我在研发部 有了很好的技术信任也有了很好的人缘。 而架构师要做的工作是许多人工作的基础。如果没有很好的技术信任大家怎么敢把他们的工作搭建在你 的基础之上。如果没有很好的人缘大家怎么愿意把他们的工作搭建在你的基础之上。 就是由于我解决了很多业务开发的问题我了解了很多业务开发的现实状况并且还能提出简洁有效的解决 方法而且解决方法不死板不铁板一块能保持独立灵活通用性给其他人的工作带来了很好的工作效率所 以领导才信任我能做好这一块并且适合做这一职位。不是随随便便一个人深刻学习了核心技术然后申请 领导要当架构师。 其实我开始做的也仅仅是公共代码员。但是很快面临了一个尴尬。 简单的虽然可能每个开发组都重复写同样类似的代码但是由于简单所以每个业务开发组都自己写了。 复杂的往往业务开发组组长都认为这个功能是自己这个组的个性功能所以还是自己写。 所以只有人们解决不了来找我时我才能上场。 这干坐着不是回事。我得自己想辙。 于是我在忙“公益事务”做活雷锋之余看到他们在扎堆开会我就主动去旁听。每次我都能提出很独到的 见解。并且能帮助他们写公共抽象代码能帮助他们提高不少工作效率。所以他们非常愿意让我旁听并且 听取我的意见。我也能很快写完让他们用。他们一用发现果然好用而且不用他们自己写代码了功能实 现的还非常巧妙公用性能也好稳定性也好扩展性也好。到后来每次开会都主动叫我。这样我的工作就 越来越多了。 随着各个业务组不同差异的需求都希望我来帮他们抽象出公共的我就在思考我手里的这部分代码。我不能 今天他们提一个我写一个。他们倒是轻松了但我手里就好似一盘散沙一样。于是我不断重构我的公共代 码架构体系框架就这样慢慢成型了。各种各样公共工具调试工具、优化工具、动态设计工具凡是能帮 助业务开发组人员加快效率的我都做了工具或写了公共函数DLL。尽量简单易用不让他们觉得麻烦或不顺 手。 过去各个业务开发组过去是开发人员素质不齐有人责任心强有人随意有人细心有人粗心有人理 解客户业务深刻有人理解不深刻。所以开发出来的质量良莠不齐。自从这样做了以后各个组写的代码少 很多都是我写的公共代码。我的技术好写的代码质量高而且是公共的有错误一改大家都没有问 题了。所以我们整体的软件产品的产品质量、生产速度都提高了不少。 我发现大家越找我各种需求交织在一起越复杂我就越需要更深入的学习技术深刻理解各种技术的 差异性和适用领域去思考各项技术的发展历史、未来趋势并且自己做DEMO看能不能更好的解决大家的 问题。因此我的技术能力也越来越高。如果我不去解决这些不去第一线想也想不到的客户需求我根本就 想像不出我某项技术还能这样用。 这就是我的螺旋上升之路。 我那天重翻上个月的《程序员》杂志看到了我朋友周爱民写的一篇《做人、做事、做架构师-架构师能力模 型解析》他也提到四点技术能力、业务能力、人际关系、个人内在素质。和我的情况很类似。 有一部分所谓的架构师技术超深厚框架堪比Spring之类但自己一个人闷头写框架不断优化力竭使用 最先进的技术思想希望把最豪华的设计模式融进去希望把OSGi融进去希望把AOP融进去全无视那些想 利用框架减轻自己工作量提高自己工作效率的应用功能开发同事。这是在用公司工资玩技术呢还是在满足 个人技术幻想呢还是在实验呢到底在干吗价值在哪里 还有的人不会推广自己的框架。不善言辞就幻想着技术总监能够通过行政命令让大家必须用框架能不自 己写代码就不自己写代码能交给框架做的就交给框架做。但技术总监号召完了大家仍然我行我素各自 开发为政让框架开发者很孤单。 还有的人也不会推广自己的框架沉迷在自己的理想世界。好不容易技术总监召集大家让大家来听听框架如 何应用但自说自话满口自己最得意的词汇听得业务功能开发人员云山雾罩。大家问些问题如这样的 业务开发难题框架怎么解决于是框架开发员就和业务开发员争论了起来。框架开发员觉得这根本就不 能答应客户这种变态的需求而业务开发员说这就是现状。框架开发员说你可以这样这样业务开发员说这 样太麻烦框架开发员立刻还口这还麻烦于是双方各执一词框架也没推广成功。 我手底下有个框架开发员。他的技术渴望很强烈为了技术难题攻克可以不吃不睡。并且技术敏感度很强 学习也快。所以当时我感觉他是个程序员的料就把他拉到我的手下。 但是有个问题他写出的框架代码在平时开发业务功能的时候挺麻烦。大家可能需要的是一把铁锹但是 他却给大家N根不同长度不同粗细不同材质的木棍N个不同形状不同用途的铁锹头。大家会有N种组合。不仅 导致他写代码老超任务期而且也让使用人感觉没多大帮助。使用起来复杂而且还得配置这个配置哪个 需要注意的地方太多。业务开发组的同事就不愿意用还不如把代码自己直接写死了得了。 超期还会影响业务功能开发组的使用。本来人家是为了想加快自己的工作效率。你答应好这个星期给业务开 发组提供一个功能但你没有拿出来。就耽误人家进度。你多次拿不出来人家业务开发组还不如自己开发 一个呢求人不如求己。 我最后警告他如果你认为自己技术够牛那么你必须证明你能很快做出来。如果你认为自己技术够牛最 好能牛到只提供一个函数就解决了他们的问题。别这个代理类那个聚合类这个唯一实例类。最好连参 数也没有大家调用一下写一句代码就OK。甚至你做的好大家都不用调用你的代码你可以包含在基础框 架中你自己去判断什么时候什么应用需要执行这个动作。如果你认为自己技术够牛那么在业务功能需求 发生变化的时候你能够保证接口不变的情况下还能适合变化这才你够牛。别让业务开发组的人跟着你也 得改他们自己的代码那样的设计就很烂了。 小伙听了我的话。进度保证代码接口简洁。 他说你真高。我感觉现在我的技术比过去进展飞快。看来人不逼是不会自己创新更好更快的方法的老 认为自己现有的方法已经不能优化了。我现在发现很多我过去写的东西还可以做的更好我准备在开发任 务之余优化代码但肯定保证不影响大家接口还跟过去一样我要重构一下。 我对小伙的成长感到欣慰。 但是小伙还有一个没有逾越的鸿沟。这个问题不解决我知道他不会成为一个真正的独立的架构师。 我复查过他的代码由于他对业务没有深刻理解所以考虑了N多种情况给自己以后的修改留下了后路。但 也因此代码量大开发周期长无法适应越来越短的客户需求响应时间可阅读性不强功能复杂稳定性困 难。但我从客户行业出发很多情况他其实都是自己假想的而且想错了。 我指出了他的问题。他问我该怎么学习业务他又没有机会到客户一线去实施也不接听客户电话客户需 求都是业务开发组的人跟他说的。 最了解客户业务的是在一线做客户咨询、做客户实施的人员。其次是做客户定制化、客户服务支持的人员 。最不了解客户的就是架构组的人员。但恰恰要命的是架构组的人员做的功能是大家的工作基础如果 基础设计错误那传递的“牛鞭效应”破坏力就很大。所以架构必须了解业务。 我了解业务的思路和我了解技术是一个思路都是来龙去脉法研究一项事情的过去、现在、未来以及 和这件事情关联的其他事情研究方法也如法炮制。 你要制造的是卡车还是轿车你得明确好。你是要造100万的轿车还是5万块钱的轿车也得定好。你是要 制造一辆可以自由改装的轿车呢还是一辆只可以大致改装一些的轿车的也得定好。这些疑问都是和咱 们面临的客户有关。而我们能面临什么层次的客户和咱们公司的实力、品牌、组织规模、盈利要求有关。 你如果是一个小公司想做百万大单只能做的一蹋糊涂。你如果是个大公司你老去竞争那些5万块的小单 做一个赔一个。所以一个公司的出身就决定了它的竞争地位和它的目标群。我们要为这个目标群服务所以 我们就不要做一个百变金刚的架构。公司有公司的目标公司招了你给你付工资就是为了让你为目标客户 群服务。如何更快更好更有质量的服务就是公司的目标。我们就是为了帮助公司实现这个目标。 我一般都是把我们这个产业的竞争格局现状了解清楚我们的过去现在竞争对手的过去现在都了解清楚。 然后我去研究我们的客户行业的竞争格局、层次现状。看看这个客户行业盘子三教九流到底多大多复杂 我们现在是占了多大我们还能占领哪些客户群。 然后我就研究客户行业目前的挑战、机遇、困境。能解决其中一两个问题就是咱们的竞争亮点。如果作为 软件一点都解决不了这些业务困境我就思考如何让产品做的更易用。微软不就靠着易用发家的么 最后我会去研究我们公司现有的研发优势和弱势、实施服务销售的优势和弱势找到适合我们突破的地方 具体归研发能承担能起作用的事情我就会去动员做。脱离现实资源现实矛盾现实包袱的改良是无法做到 改良的。 我还关心各种新的技术应用。可能这项技术很久了但大家都没有想过还能这样用。所以我常常在媒体上 关注这些、思考这些、在论坛上和业界交流这些。对于新的技术要研究原理要尝试但不要冲动引入到 商品生产中。我们不是自己在创业在玩在实现自己的梦想。我们承担的是公司所有人都要吃饭的产品。如果 有闪失这么多人以及他们的家庭都要受到影响。这不是闹着玩。 当我研究完业务领域的这些大的框框以后每逢有业务同事跟我交流客户需求我总能把这个需求和我的业 务框架联系在一起把这个需求归好类。并且能判断出这个需求是个反趋势的需求还是个短期眼光的需求 还是个长远发展的需求。 很多人都在抱怨说需求老变化。其实不是客户需求在变而是你对客户的需求老是不同思路去理解。我心 中有业务框架有过去现在未来所以能识别出一个需求是稳定的还是临时拍脑门想出来的。有时候 有人向我提一个需求我会眼睛一亮对这个需求符合未来发展我就会很快加入。所以我曾经在做实 施经理的时候老是能很容易说服客户让客户听从我的意见就是由于我想的比他们还要远还要周全。好 多程序员说客户非要某个功能不做不行就说明这个程序员并没有理解客户。客户并不是那个非要和你作对 的人他只想解决他的问题。可能你不理解他的真正根源问题而且你又提不出更好的方案所以他要跟你急 要让你必须实现某个功能。 只有你不断游走在业务过去现状未来与技术过去现状未来你做的架构才是真正的实用、弹性、易用而且 最小成本不走弯路不多花开发精力。 我们需要架构不就是为了达到这个目的么。 转载于:https://www.cnblogs.com/javait03/archive/2008/06/15/2403733.html
