我们正在计划重写我们的一个基本应用程序。它是基于Web的，我们被锁定在PHP中。但它不是一个Web 2.0站点。它更接近企业应用程序。
这绝不是简单的。至少有2个主界面（我认为有4个，但这是另一个主题）。它需要具有高度可配置性和高度可定制性。我预计每年安装50到200个，因此易于维护是一个主要问题。
所以这个问题出现在架构中。我想先做一个正式的高级架构。在此之前。之后，我们将选择一个合适的框架（一个适合架构的框架）或选择一个关闭并将其用作库集。从长远来看，我认为这种方法将保证可行的系统（因为至少考虑了完整的架构）
但是，团队的其他成员希望首先选择一个框架（他们想要使用YII）并完全跳过高级架构。他们的论点是框架首先完成了高级架构，让你“开始编码”。
基本上，我认为这就像把马放在马前，或者在泥坑上面没有基础的房子。我知道这种观点在快速应用程序开发的后ROR时代很受欢迎，因为可以更快地完成更多工作。但我真的担心，对于一个关键任务核心应用来说，这最好是短视的（最坏的是疏忽）。
我真的害怕我们走错了路。
管理层认为我是高级开发人员。从技术上讲，我可以否决其他大多数人。但我并不高于他们，所以在实践中这样做会很糟糕。有人提到有一个主要的语言障碍（他们说波兰语，我说英语）。
我想我应该提到我真的不喜欢大多数RAD PHP框架。不是因为它们无论如何都是坏事，而是因为它们倾向于（恕我直言）强制建构并不重要的心态，因为它们是为你做的。更不用说他们通常希望你按照自己的方式工作（Rails就是这样着名的），而不是一种对手头的项目有意义的方式。所以我通常只使用一个框架作为一组库。在有意义的时候使用这些类，并在项目要求指示的时候构建我自己的类。
所以我的问题如下：
- 我关心的是对吗？或者他们是对的，我只是过度反应？
- 如果我是对的，对于如何处理这种情况有任何建议吗？
- 如何在没有引起叛变的情况下让团队站在我这一边？
您可能对我最近的博客文章感兴趣： 不要把马放在马前 我在谈论在确定任何架构选择之前定义您试图解决的问题的重要性。
至于让团队在你身边，有多种解决方案，因为有多种原因可以抵抗。
我推荐这本书： 推动技术变革：为什么团队中的人不会做出好的想法，以及如何说服他们应该做的事 特伦斯瑞安它即将推出，但您可以立即订购测试版电子书，这适用于最终的电子书。
（免责声明：我查看了该书的草稿，并由出自我书的同一家公司出版。）
您可能对我最近的博客文章感兴趣： 不要把马放在马前 我在谈论在确定任何架构选择之前定义您试图解决的问题的重要性。
至于让团队在你身边，有多种解决方案，因为有多种原因可以抵抗。
我推荐这本书： 推动技术变革：为什么团队中的人不会做出好的想法，以及如何说服他们应该做的事 特伦斯瑞安它即将推出，但您可以立即订购测试版电子书，这适用于最终的电子书。
（免责声明：我查看了该书的草稿，并由出自我书的同一家公司出版。）
我会说你们两个都是对的。考虑到架构很好。但建筑师往往过于复杂化。开发人员指责建筑师住在象牙塔，而他们在战壕中倒下并不罕见。然而，在沟内处于相当低的地面，因此开发人员通常不会看到森林的树木，这可能会导致同样不受欢迎的特殊架构或岛屿解决方案，连接不太好。
至于提供更高级别架构的框架，是的，是的。他们是这样。但这并不意味着它是您需要的架构。您将在框架中找到的东西（希望）建立在已建立的设计模式之后。设计模式是常见问题的建议解决方案。如果您不需要解决这些问题，那么您也不会使用解决这些问题的框架。这是错误的选择。现在，这是相当通用的，但你明白了。
我的建议是不要滥用你的高级开发人员职位并强制做出决定。寻求妥协。让他们参与决策，但希望他们讨论。我不知道你所在的工作环境，但也许考虑采用一些敏捷的过程，比如Scrum。也许首先用不同的框架进行一些探索性编码，看看哪种更适合。最好是尽早使用一个框架而不是最终意识到它是错误的马。
我无法在没有任何详细信息的情况下描绘高级架构，但是对于它的价值，这个：
我想先做一个正式的高级架构。在此之前
对我来说听起来很理智。在选择一个框架之前，需要明确它的结构是否适合你需要做的事情，而不必弯曲它到目前为止它不再是那个框架。
至于 怎么样......我相信其他人比我更有资格回答这个问题。但是，如果时间至关重要，并且团队的大多数人想要“立即开始使用”路线，我会试着说服他们先做至少少量的建筑会议 - 如果只是一个或两个下午。
如果你真的没有权限（即使你有），请让他们在有限的时间内幽默你。根据我的经验，一旦你进入它，架构缺点和问题就会很快出现（“我们需要做xyz。我们如何在Framework X中做到这一点？”）。模拟场景（和问题）的密集会话可能会让人们想一想他们选择哪个平台。
是否有任何其他开发人员在YII中部署了类似于现在需要构建的应用程序？如果没有，那么你至少有一些理由可以推迟，并且a）找出YII的优点和缺点（请他们告诉你）和b）这些如何满足你项目的要求。
如果您正在使用一个您已经熟悉的框架，可以直接进行编码，这个框架具有构建您想要的应用程序类型的可靠记录，但是使用新框架（您的团队不熟悉）它绝对有意义首先评估，至少是一个骨架原型，作为尽职调查的一部分 - 特别是如果它是一个商业的关键任务应用程序。确保它可以满足您的每个必需业务要求。
在推迟方面，您可以随时要求业务部门向开发团队提出问题“告诉我们（证明）为什么我们使用这个框架来构建我们的关键任务应用程序”。
你所在的州，你们都知道你需要建造一座40层的建筑。但你永远不会在沙滩上建造一个上层建筑。达成共识只会延误一切。最好的方法是让每个人在尽可能短的时间内使用相同的基线/期限从预期的产品中获得尽可能多的功能，从而构建概念验证。然后找一个独立的审核小组来研究你的方法。然后做出决定。框架和格子只是您基础的支撑结构。
你和你的团队不同意，但你们都是对的。你去写一些文档，然后让他们开始在CakePHP等框架上开始。理想情况下，您应该获得一些以上框架的经验。这将使您能够在选择平台方面做出更多有根据的选择。
你想先做一堆设计工作的原因非常合理 - 你需要在做之前知道自己在做什么。但是对于其他开发人员来说，开始学习和使用框架也是非常有效的。这些知识将帮助您做出决策，并且还可以让您的团队更快地开始产生结果。
我建议你不要过于担心将推车放在马前。想想前几周教育自己和原型设计，意图将你的早期结果抛弃。使用新框架或方法最困难的部分是学习它，变得足够熟练，以至于你主要考虑的是你的应用程序而不是你正在工作的媒介。你的人可以在你考虑设计问题的同时开始。
您甚至可以尽早找出一些数据模型，让他们开始为这些模型制作UI页面。当然，你需要在改进设计时改变它们，但是做出这些改变是多么容易，这是构成一个好框架的一部分。
原型制作的风险是人们过于依赖“工作”而不想丢弃它的东西的自然倾向。但是，如果没有任何具体的交互和产生想法，那么在抽象中进行过多的设计工作也存在风险。
我不会深入研究瀑布与迭代的论述。但是我建议你释放你的员工对潜水的热情，让他们在你设计工作的同时尝试并学习一些框架。然后，您可以团结一致，讨论您的架构，并就您想要使用的框架进行更有教育的讨论。