我的问题不是编程语言特定,而是更普遍的问题,看看人们的思维方式.
通常在大型开发公司中,每个工作都有特定的角色,例如程序员和架构师.因此,架构师的观点是拥有完美的架构师和解决方案设计,另一方面,程序员正在处理实际实现应用程序功能和UI的东西.因此,如果您让架构师例如在没有程序员的情况下处理应用程序,您将从内部(设计模式,类,数据库表)获得完美的应用程序,但外部没有任何内容,反之亦然.程序员总是专注于输出,而不必过多关注设计原则(例如SOLID原则).
现在我正在一家小公司工作,团队最多由8-10人组成,所以你需要照顾你的应用程序设计以及实现这些功能.所以我的问题就是
我希望我们可以有不同的思维方式,这样我们就可以提出多种可接受的解决方案
彻底思考问题/设计将改进最终的代码。但是,除非您在编写代码时花费数月时间进行设计,否则您会发现设计中的缺陷、您没有想到的新功能或您没有预料到的交互。在大多数软件项目中,目标都会发生变化(客户会想要一些稍微不同的东西,或者你会在中途产生一个好主意,等等)。
瀑布方法倾向于在你不知道代码将如何实现之前就预先完成整个设计——这是不灵活的,并且会导致设计缺陷发现得太晚而无法采取更多措施。通常,即使在瀑布方法中,我也会建议进行原型设计,其中高风险编码任务在设计阶段实际实现到足够大的程度,以确认它们可以完成并且将按预期工作。
敏捷方法建议您应该只设计开始时需要的数量,然后在发现需要时再进行更多设计。这将编码与设计混合在一起,形成了一种更加灵活的方法。然而,这常常被误解为“没有完成设计”,或者直到为时已晚才考虑设计的大部分内容 - 情况不应该如此。您应该设计足够的整体结构,以便您了解如何继续进行,并且您没有精确指定的设计的小部分足够简单,以便您知道以后能够在不影响最终产品的情况下设计它们。
因此,无论走哪条路,您都需要充分计划,以便知道自己的前进方向,足够灵活,可以在需要时改变方向,但在此过程中编写一些代码(原型或最终代码)以帮助指导您的设计。如果程序的某些部分被证明不够充分,请准备好重构和重写它们。
归档时间: |
|
查看次数: |
104 次 |
最近记录: |