我们正在计划重写我们的一个基本应用程序.它是基于Web的,我们被锁定在PHP中.但它不是Web 2.0站点.它更接近企业应用程序.
这绝不是简单的.至少有2个主界面(我认为有4个,但这是另一个主题).它需要具有高度可配置性和高度可定制性.我希望每年安装50到200个,因此易于维护是一个主要问题.
所以这个问题出现在架构中.我想先做一个正式的高级架构.在此之前.之后,我们将选择一个合适的框架(一个适合该架构的框架)或选择一个关闭并将其用作库集.从长远来看,我认为这种方法将保证一个可行的系统(因为至少考虑了完整的架构)
但是,团队的其他成员希望首先选择一个框架(他们想要使用YII)并完全跳过高级架构.他们的论点是框架首先完成了高级架构,让你"开始编码".
基本上,我认为这就像把马车放在马前,或者在泥坑上面没有基础的房子.我知道这种观点在快速应用程序开发的后ROR时代很受欢迎,因为可以更快地完成更多工作.但我真的担心,对于一个关键任务核心应用来说,这最好是短视的(最坏的是疏忽).
我真的害怕我们走错了路.
管理层认为我是高级开发人员.从技术上讲,我可以否决其他大多数人.但我并不高于他们,所以在实践中这样做会很糟糕.有人提到有一个主要的语言障碍(他们说波兰语,我说英语).
而且我想我应该提到我真的不喜欢大多数RAD PHP框架.不是因为它们无论如何都是坏事,而是因为它们倾向于(恕我直言)强制建构并不重要的心态,因为它们是为你做的.更不用说他们通常希望你按照自己的方式工作(Rails就是出名的),而不是一种对手头的项目有意义的方式.所以我通常只使用框架作为一组库.在有意义的时候使用这些类,并在项目要求指示的时候构建我自己的类.
所以我的问题如下:
您可能对我最近的博客文章感兴趣:不要把购物车放在马前我谈到在确定任何架构选择之前定义您试图解决的问题的重要性.
至于让团队在你身边,有多种解决方案,因为有多种原因可以抵抗.
我推荐这本书: 推动技术变革:为什么你的团队中的人不会采取好的想法,以及如何说服他们应该由Terrence Ryan.它即将推出,但您可以立即订购测试版电子书,这适用于最终的电子书.
(免责声明:我查看了该书的草稿,并由出自我书的同一家公司出版.)