Php 架构和框架选择团队问题

我们正在计划重写我们的一个基本应用程序。它是基于web的，我们被锁定在PHP中。但是，它不是Web2.0网站。它更接近于企业应用程序

这一点也不简单。至少有2个主界面（我想有4个，但这是另一个主题）。它需要具有高度可配置性和高度可定制性。我预计每年安装50到200次，因此维护的方便性是一个主要问题

因此，问题出现在架构中。我想先做一个正式的高层架构。在其他事情之前。然后，我们要么选择一个合适的框架（适合体系结构的框架），要么选择一个相近的框架并将其用作库集。我觉得从长远来看，这种方法将保证一个可行的系统（因为至少考虑了完整的体系结构）

但是，团队的其他成员希望首先选择一个框架（他们希望使用YII），并完全跳过高层架构。他们的论点是，框架首先完成了高层架构，让我们“开始编码”

基本上，我认为这就像把马车放在马背上，或是在泥坑顶上没有地基。我知道这种观点在ROR后的快速应用程序开发时代很流行，因为可以更快地完成更多的工作。但我真的担心，对于任务关键型核心应用程序来说，这充其量是短视的（最坏的情况是疏忽）

我真的担心我们走错了路

管理层认为我是一名高级开发人员。所以从技术上来说，我可以否决其他大多数。但我并不在他们之上，所以在实践中这样做是不好的。更不用说还有很大的语言障碍（他们说波兰语，我说英语）

我想我应该提到，我真的不喜欢大多数RAD PHP框架。这并不是因为他们在任何方面都不好，而是因为他们倾向于（IMHO）强化这样一种心态，即架构并不重要，因为他们是为你而做的。更不用说，他们通常希望您按照他们的方式工作（Rails因此而闻名），而不是按照对手头的项目有意义的方式工作。所以我通常只使用一个框架作为一组库。在有意义的时候使用类，在项目要求的时候构建我自己的类）

因此，我的问题如下：

我的担心对吗？或者他们是对的，我只是反应过度

如果我是对的，有没有关于如何处理这种情况的建议

我怎样才能让球队站在我这边而不引起兵变

---

您可能会对我最近的博文感兴趣：在我的博文中，我谈到了在确定任何架构选择之前定义您试图解决的问题是多么重要

至于让团队站在你这边，有多种解决方案，因为阻力有多种原因

我推荐这本书：特伦斯·瑞安。它很快就要上市了，但是你可以马上订购测试版电子书，这适用于最终的电子书

---

（免责声明：我审阅了那本书的草稿，它是由出版我自己的书的同一家公司出版的。）

在没有任何详细信息的情况下，我很难描绘出高层架构，但值得一提的是：

我想先做一个正式的高层架构。首先

听起来很理智。在选择一个框架之前，需要弄清楚它的结构是否适合您需要做的事情，而不必将它弯曲到不再是那个框架的程度

至于如何。。。我相信其他人比我更有资格回答这个问题。然而，如果时间很重要，团队中的大多数人都想走“让我们马上开始”的路线，我会尝试说服他们至少先做一小部分的架构会议——如果只是一两个下午

---

如果你对他们没有真正的权威（即使你有），请他们在有限的时间内幽默你。根据我的经验，一旦进入架构，架构缺陷和问题往往会很快出现（“我们需要做xyz。我们如何在frameworkx中做到这一点？”）。密集的模拟场景（和问题）会议可能会让人们对选择哪个平台三思而后行

我认为你们两个都是对的。考虑到架构，这很好。但架构师往往倾向于将事情过于复杂化。开发商指责建筑师生活在象牙塔里，而他们却深陷战壕，这种情况并不少见。然而，深陷战壕的地面相当低，因此开发人员往往看不到森林，这可能导致同样不受欢迎的临时架构或连接不太好的孤岛解决方案

至于已经提供了更高层次架构的框架，是的。是的。但这并不意味着它就是你需要的架构。您将在框架中发现的东西（希望）是按照已建立的设计模式建模的。设计模式是针对常见问题的建议解决方案。如果您不需要解决这些问题，您也不需要使用框架来解决这些问题。这是错误的选择。现在，这是相当普遍的，但你明白了

---

我的建议是不要滥用您的高级开发人员职位，并强迫他们做出决定。找到一个折衷方案。让他们参与决策，但希望他们讨论。我不知道你所在的工作环境，但也许可以考虑采用一些敏捷的流程，比如Scrum。也许先用不同的框架进行一些探索性的编码，看看什么更适合。与其最终意识到它是一匹错误的马，不如尽早放弃一个框架。

在你所处的状态下，你都知道你需要建造一座40层的建筑。但你从来没有建立一个