|
|
6 回复 | 直到 14 年前
|
1
5
你可能会对我最近的博文感兴趣: Don't Put the Cart Before the Horse
我推荐这本书: Driving Technical Change: Why People On Your Team Don't Act On Good Ideas, and How to Convince Them They Should 特伦斯·瑞安。它很快就要上市了,但是你可以马上订购beta版电子书,这适用于准备好的最终电子书。 (免责声明:我审阅了那本书的草稿,它是由出版我自己的书的同一家公司出版的。) |
|
2
2
我想你们两个都是对的。考虑到建筑是好的。但是架构师往往倾向于将事情过度复杂化。开发商指责建筑师住在象牙塔里,而他们却深陷战壕,这并不少见。然而,处于战壕中是相当低的,所以开发人员通常不会看到森林的树木,这可能会导致同样不受欢迎的临时架构或岛解决方案,连接不太好。 至于提供更高层次架构的框架,是的。是的。但这并不意味着它就是你需要的架构。您将在框架中发现的东西(希望)是按照已建立的设计模式建模的。设计模式是针对常见问题的建议解决方案。如果您不需要解决这些问题,那么也不需要使用框架来解决这些问题。这是错误的选择。现在,这是相当普遍的,但你知道的想法。 我的建议是不要滥用你的高级开发人员职位,强迫他们做出决定。找到一个折衷方案。让他们参与决策,但希望他们讨论。我不知道你那里的工作环境,但也许可以考虑采用一些敏捷过程,比如Scrum。也许先用不同的框架进行一些探索性的编码,看看什么更适合。一个框架一开始就失败,总比最终意识到它是错的要好。 |
|
3
2
我很难在没有任何详细信息的情况下描绘出高层体系结构,但值得一提的是: 听起来很正常。在选择一个框架之前,需要弄清楚它的结构是否适合您需要做的事情,而不必将它弯曲到不再是那个框架的程度。 怎样 如果你对他们没有真正的权威(即使你有),让他们在有限的时间内幽默你。以我的经验来看,一旦你进入其中,架构缺陷和问题往往会很快暴露出来(“我们需要做xyz。如何在frameworkx中做到这一点?”)。密集的模拟场景(和问题)会议可能会让人们在选择哪个平台时三思而后行。 |
|
4
2
其他开发人员是否在YII中部署了与现在需要构建的应用程序类似的应用程序?如果没有,那么你至少有一些理由推倒和a)找出YII的优势和劣势是什么(让他们告诉你)和b)这些如何衡量你的项目的要求。
在回退方面,您可以随时要求业务部门向开发团队提出问题“告诉我们(证明)为什么我们要使用这个框架来构建任务关键型应用程序”。 |
|
|
5
0
|
|
|
6
0
你和你的团队不同意,但你们都是对的。你去写一些文档,让他们开始在CakePHP之类的框架上切齿。理想情况下,您应该获得使用多个框架的经验。这将使您能够在选择平台时做出更明智的选择。 你想先做一堆设计工作的原因是很合理的——你需要在做之前知道你在做什么。但是对于其他开发人员来说,开始学习和使用框架也是非常有效的。这些知识将帮助您做出决策,也将让您的团队更快地开始产生结果。 我建议你不要过分强调本末倒置。把最初的几周想象成自我教育和原型设计,意图抛开你的早期成果。使用一个新的框架或方法最困难的部分是学习它,变得足够熟练,以至于你主要考虑的是你的应用程序,而不是你所使用的媒介。当你考虑设计问题的时候,你的员工可以开始考虑这个问题。
原型设计的风险是人们自然倾向于过于依赖于“有效”的东西而不想丢弃它。但是,做太多抽象的设计工作,却没有任何具体的东西与之互动和产生想法,也有风险。
|
