一级建筑师 系统分析师_谦虚的建筑师

一级建筑师 系统分析师

谦虚并不是软件架构师非常普遍的特征。 在与一些糟糕的建筑师合作之后，最近又与一个非常愉快的建筑师合作，我以每个建筑师喜欢的方式总结了一些经验：作为一组规则。

规则0：不要以为是愚蠢的

似乎有些建筑师认为，如果让开发人员留在自己的设备上，他们的行为会像猴子一样。 以我的经验，这种情况很少发生。 我看到开发人员做愚蠢的事情的唯一情况是，在默默抗议建筑师时。 如果您遵循此规则，则剩下的就是细节。

规则1：你可能错了

在审查某人的设计想法时，我更喜欢尝试问一些坦诚相待的问题。 也许我认为开发人员忽略了一个关键事实，例如并发。 有几种不同的方法可以解决这种情况：

1. 架构师： “您不能那样做，因为它违反了代码准则”
2. 架构师： “您不能那样做，因为在有多个用户的情况下这样做并不安全”
3. 架构师： “您是否考虑过它将如何与多个用户一起使用？”
4. 架构师： “您的解决方案如何解决多个用户的情况？”

尊敬的架构师：请对这些方法的评分从最小到最有可能获得最佳系统。 （提示：这是一项容易的任务，即使许多建筑师通常都会失败）

规则2：对技术要小心

每种技术都有成本。 许多技术带来无穷的收益。

以下是我经历过的一贯成本高于收益且因此永远不会使用的技术列表（如果您不了解它们，请不用担心。关键是数字）：JavaServer Pages，Java Server Faces ，JAX-WS，Hibernate，Spring，EJB，Oracle SOA服务器，IBM WebSphere，Wicket，Google Web Toolkit，Adobe Flex，JBoss jBPM，JMS（所有实现），JBoss。

这是我愉快使用的技术列表：JUnit，Jetty，Joda-time，Java Standard Edition。

这是一个卑微的交流，您可以尝试复制：

• 架构师：您应该使用技术X
• 我：我看过技术X，但看不到它如何帮助我解决业务问题
• 建筑师：你是什​​么意思？
• 我：嗯，这就是我们需要做的：…..这就是X技术所假定的：…。 我看不到它们如何匹配。
• 建筑师：那么您建议改用什么呢？
• 我：嗯...我想我们可以用普通的Java解决这个问题。 事实上，昨天晚上我做了一个很好的概念验证。
• 很棒的建筑师：太酷了。 让我们使用它。

规则3：一致性并不像您想象的那么重要

如果每次我都愿意出一分钱，我都会听到……。

• 架构师： “是的，我知道这种方式可能很笨拙，但是您必须这样做。 您会发现，如果不这样做，系统将变得不一致且无法维护”

当然，我不经常从事维护工作，但是我知道当我处理任何系统时，最困难的部分是了解该系统的业务逻辑。 在使我失去睡眠的事情清单上，系统X（具有一组业务逻辑）和系统Y（具有另一组业务逻辑）是否一致非常低。

系统X非常复杂，因为它具有与系统Y一致的十几个层次–现在，这确实使我想拔出头发。 不同的上下文具有不同的权衡。

哦，是的：还记得规则0吗？ 假定在给定上下文中的开发人员正在尝试为该上下文创建一个好的解决方案。

哦，是的，另一件事：我从来没有见过因为我们变得更大而变得难以维护的小事情变得难以维护。

哦，是的，还有另一件事：如果程序员真的因为代码中的某些花括号具有某种样式而有些花括号具有另一种样式而真正地对代码大喊大叫，那么我将失去对人性的​​所有信念。

规则4：自下而上的一致性优于自上而下的一致性

我有一种方法可以在系统内部创建更多的一致性：

• 创建一个参考应用程序，其体系结构要易于遵循而不容易破坏。 如果做得好，开发人员将对偏离体系结构的想法深信不疑。 除非他们真的需要。 在这种情况下可以。
• 培育一种相互授粉的文化：看到彼此代码的开发人员比只看到自己代码的开发人员拥有更一致的代码。 配对编程，代码审查和技术共享会议都促进了异花授粉。

规则5：跨系统的战术重用是次优化

重用会产生耦合。 如果系统X和系统Y重用了某些功能，并且系统X需要修改该功能，则将影响系统Y。至少，系统X上的团队必须决定对重用的功能进行私有存储，这意味着它不再真正被重用。 最糟糕的是，由于重用功能的更改，系统Y会出现错误。

当您跨系统重用时，重用应该是稳定的（例如：Java SE平台，或者是某种稳定的东西，以至于您肯定不是自己制造的）或策略性的。 战略重用是指集成信息而不仅仅是重复功能的服务。

换句话说： 重用应该是use或integration 。 复制是您的朋友。

规则6：规则与教条分开

在任何编码标准中都有规则的三个原因：

• 不安全：代码中存在一个错误，该错误会在某些（非理论上）情况下显现
• 不可理解：“我”不明白发生了什么
• 异端：代码是以某些人不喜欢的样式编写的

流行测验：如果您有一条规则说“所有字段都必须有JavaDoc注释”，那是安全问题，可理解性问题还是异端问题？ 如果标准使用此示例怎么办：

/**
 *  Contains the name value of the object
 */
private String name;

规则说“在花括号前没有换行符”怎么办？ 规则如何：“花括号的样式应保持一致”？ 它是针对不安全代码，难以理解的代码还是异端？

我们应该更多地关注为这种情况编写适当的代码，而不是关注安抚一致性之神。

欧米茄规则：谦虚

在从事软件开发的这些年中，我看到软件架构师所带来的伤害大于帮助。 作为专业角色，我认为，如果我们摆脱他们（美国），我们会省钱。 即使我们仍然支付他们的薪水。

当您从事的职业所造成的伤害超出其危害范围时，您有两种选择：可以尝试提高自己的水平，或者可以祈祷没有人注意到。

参考资料：来自JCG合作伙伴 Johannes Brodwall的谦虚建筑师在“ 大盒子内的思考”博客中发表。

翻译自: https://www.javacodegeeks.com/2013/12/humble-architects.html

一级建筑师 系统分析师