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