谦卑对于软g架构师来说不是一个很常见的特征。在参与q一些让人敬畏的架构后,q且最q还参与q一个o人愉快的目Q我以每个架构师都比较喜Ƣ的方式ȝ了一些经验:作ؓ一套规则?/span>规则0Q不要装p涂QDon't assume stupidityQ?/strong>
像一些架构师假定开发hd他们自己的设备,表现的将像个猴子。在我的l验里,q是很少会发生的。我只看到过一U开发h员做事时犯糊涂的情况Q就是默默的抗议和反Ҏ构师。如果你认可q个规则Q接下就是一些细节?/span>
规则1Q你可能是错的(You may be wrongQ?/strong>
当审阅一些h的设计理忉|Q我更喜Ƣ开诚布公的试问一些问题。我认ؓ开发h员可能忽略了一个关键点Q如q发。这儿有一些应对这些场景的ҎQ?/span>
1. 架构师:“你不能那样做Q因Z可能破坏代码设计准则?#8221;
2. 架构师:“你不能那样做Q因为在多用h况下Q他是不安全的?#8221;
3. 架构师:“你是否想q多用户Ӟ他如何工作呢Q?#8221;
4. 架构师:“你的Ҏ如何应付多用户场景呢Q?#8221;
亲爱的架构师Q请从最不可能到最有可能得C个尽可能好的pȝ的角度来评估q些Ҏ。(提示Q尽有许多架构面对q个问题l常p|Q但q真的是一个项很容易的工作。)
规则2Q}慎选用技术(Be careful with technologyQ?/strong>
每种技术都会带来成本。大部分技术只能带来很的益处?/span>
q儿有一个我所l历q的成本大于益处的技术列表,因此永不再使用Q如果你不知道他们,也不用担心。关键是数量。)QJavaServer Pages, Java Server Faces, JAX-WS, Hibernate, Spring, EJB, Oracle SOA Server, IBM WebSphere, Wicket, Google Web Toolkit, Adobe Flex, JBoss jBPM, JMSQall implementationsQ? JBoss?/span>
q儿有一个我比较愿意使用的技术列表:JUnit, Jetty, Joda-time, Java Standard Edition?/span>
q儿有一个你可能惌试或模仿的谦虚的交方式:
架构师:你应该用X技术?/span>
我:我注意过X技术,我不认ؓ他能帮助我解决业务问题?/span>
架构师:你想表达的意思是什么呢Q?/span>
我:哦,我需要做Q?..Q这些是X技术假讄Q?..Q我不认Z们匹配得上?/span>
架构师:那么你徏议用什么来替代他呢Q?/span>
我:?..Q我认ؓ我们可以使用普通的Java来解军_。事实上Q我昨晚做了一个非常好的demo来证明其可行性(I made a pretty good proof-of-concept yesterday evening.Q?/span>
受h敬的架构师Q很P让我们用它吧?/span>
规则3Q一致性不像你认ؓ的那样重要(Consistency isn't as important as you thinkQ?/strong>
如果我有一便士Q每ơ我都将会听?..
架构师:“是的Q我觉得q种方式可能比较W,但你必须q样做。你是知道的Q如果不q样做,pȝ会生不一致ƈ且是不可l护?#8221;
相当然吧Q我不常常做l护工作Q但是我处理MpȝӞ最困难的部分通常是理解系l的业务逻辑。XpȝQ有一套业务逻辑Q还是YpȝQ另一套业务逻辑Q是不是一致性的问题在让我失眠的d列表中优先都是被排的比较低的?/span>
事实上,Xpȝ是非常复杂的Q因Z有十二层且每层都要和Ypȝ一致。现在这让我特别生气。不同的上下文环境有不同的权衡?/span>
哦,是的Q还记得规则0吗?假如在一个给定的环境中,开发h员尝试ؓq个环境创造一个好的解x案?/span>
哦,是的Q另一件事Q我从未见到q一个小的可l护的东西复杂到难以理解。复杂只是因为我们让他发展壮大造成的?/span>
哦,好的Q还有另外一件事Q如果因为开发h员中一些用这L花括h式,另外一部分使用另一U花括号方式~程Q而导致开发h员大늝q离~码。我失L有对人性的信Ԓ?/span>
规则4Q自底向上的一致性不如从上到下的一_Bottom-up consistency beats top-down consistencyQ?/strong>
q儿有一U我有能力创建系l内部一致性的ҎQ?/span>
1. 使用更容易被沿用Q而不是用具有突破性的架构来创Z个参考应用。如果你q样做的话,在遇C些偏L构的xӞ除非他们真的需要,在这U情况下他是非常好的Q否则开发h员将会摇头?/span>
2. 培训一U交叉交的文化QFoster a culture of cross-pollinationQ:彼此互相看代码的开发h员一致性要比仅仅看他自׃码的开发h员更好。结对编E(Pair programmingQ,代码reviewQCode reviewsQ和培训交叉技术分享会QTech sharing sessions all foster cross-pollinationQ?/span>
规则5Q跨pȝ的策略重用不是最优选择QTactical reuse in across systems is suboptimizationQ?/strong>
重用会产生耦合。如果系lX和系lY重用了一些功能,pȝX需要对功能q行修改Q这会影响到系lY。但臛_Q工作在pȝX的团队必d定对重用的功能做一份私有副本。那意味着他不再被真正的重用。在极端情况下,׃寚w用功能的修改Q将造成pȝY产生bug?/span>
当你跨系l重用时Q那应该是稳定的Q例如,Java SEq_或别的东西,如此E_Q你不需要自己动手做它)或策略性的内容。关于策略重用,是指整合信息但不是仅仅复制功能的服务?/span>
换句话说Q重用应该是要不被用,要不被集成。副本是你的朋友?/span>
规则6Q分辨规则和教条QSeparate between rules and dogmaQ?/strong>
有三U原因用这个Q何编码规范中都有的规则:
1. 不安全(UnsafeQ:代码在某U场景(真实存在Q非理论上)中会出现bug
2. 令h费解QIncomprehensibleQ:“?#8221;不理解这是怎么回事
3. 旁门左道 QHeresyQ:使用了大安不喜Ƣ的方式来写代码
抽查试Q是否你有这样一个规则,“所有属性必L注释”。关于安全问题,关于易理解问题或是旁门左道?使用q个例子做ؓ标准Q?/span>
/**
* Contains the name value of the object
*/
private String name;
关于“在左花括号前面没有换?#8221;规则Q关?#8220;花括h式应该统一”的规则?是否W合不安全代码,不易理解或旁门左道?
我们应该更关注在特定场景下写适当的代码,关注一致性?/span>
最后:谦卑QBe humbleQ?/strong>
在我从事软g开发的那些q里Q我见过到Y件架构师的伤完多于帮助。做Z个职业角Ԍ如果我们解雇他们Q我们自己)Q我们将节省很多钱。那怕我们仍付给他们薪水?/span>
如果你工作在一个他们造成的伤完多于他们所能阻止,你有两个选项Q你可以试改善或在没有人的时候祈?/span>

]]>