如果看不到产品的日常开发过程，那么人们可能会认为一切都很顺利。 时间线看起来还不错。功能也在持续增加。我们正在朝着我们的目标前进。
但还有什么呢？
java架构师无法真正了解工具
如果java架构师参与编程，那么他们无法亲身实践工具。
首先，当库和工具无法解决问题时，Java架构师可能不知道。 Java架构师可能会规定某些工具可以在理想情况下正常工作，但是这些工具在复杂和常见的用例中可能会带来很多困难。或者恰恰相反，他们推荐了一种适用于复杂场景的工具，但是对于开发人员遇到的简单日常问题太过苛刻。
除非java架构师使用他们自己推荐的工具，否则就无法真正意识到他们的选择产生的影响。
设计无法满足不断变化的需求
在考虑软件开发的时候，我们不能假设一个静态的世界。java架构师做的提前设计并不能考虑到所有的可变因素和极端情况。在软件编写工作完成之前，我们无法发现其中的细微差别。
总之，架构和设计决策经常需要做出改变。
你可能会说这不是问题。java架构师可以回去重新设计系统。然而，实际情况却并非如此。开发人员注意到有些事情不太对劲。这些事情变得越来越困难。而他们可以做的有：他们可以向java架构师汇报这个问题，但是java架构师不在其中无法真正掌握情况；他们可以自行重新设计系统；或者他们也可以尽可能地想办法弥补问题，然后继续前进。
如果Java架构师可以与开发团队相处并进行编程工作，他们可以看到即将到来的更改并实时修改设计。 他还可以提前进行最少的设计，并与团队合作以逐步改善系统架构。
开发人员备受打击
如果设计只能从上至下进行交流，而Java架构师不在身边，那么开发团队将在各个方面受苦。 首先，如上所述，情况将会改变。 如果Java架构师不参与讨论，那么这些变化将导致延迟。
其次，许多开发人员都不喜欢刻板的编程，他们希望能够创造设计并做出决策。 如果设计过于精细，那么创造过程就会消失。
最后，当开发团队注意到实际情况与架构图上的不一致时，他们会责怪计划。而且他们会觉得java架构师没有搞明白状况。无论这是实情还是他们的想象，编写软件过程中的障碍都可以视作java架构师的失职。
推荐阅读：java架构师指南之什么是架构和架构本质