在软件交付阶段后期,才发现前期做架构设计的时候有缺陷,你会冒着延期的风险修改好吗细节见问题描述。

谢邀??如果你只是小弟的话,我的建议是你先完成现有模块。完成后给你老大说一下你的想法让你老大决定你到底要不要去修改设计,修改会很耗时,这关系到团队其他人进度,得有你们老大进行去中间调节。如果你是项目负责人的话,我的建议是你先保证现有可用,之后根据进度时间决定是不是要进行修改。不过再决定修改之前先自己做个分析??分析一下可行性,不要做了一半了发现方案走不通或者还不如原来的方案,那就很影响士气的。优先可用,之后根据时间进度以及代价(这个一定要分析好,手机没法加黑,反正是重点)来决定要不要修改。还有有错就及时要说,不要以为说出来别人会看不起,你不说最后发现了反倒会更看不起的!再说程序员没那么多想法,程序员还是比较单纯的,都为了项目,该说就得说。
■网友
仅就当前给出的已知条件,我个人认为这不是一个技术问题,而是一个职场问题。因为这里给出的条件已经很明确了:改设计耗时少,不改耗时多。而唯一的问题在于:到底是自己背锅,还是大家背锅。仅从技术角度上说的话……我不认为修改设计的耗时一定少,而且我也不认为修改设计一定更好。我有一个更好的想法!然后导致项目无限延长的例子比比皆是。项目是不可能做到尽善尽美的。因此这个问题其实换个说法可能会更好一点儿。
■网友
谢邀,我觉得好的设计在实现上应该也是节省时间的,题目描述的情况可能说明现在想到的所谓“更好”的方式,其实还不是最优的选择。可以先放一放,让系统先按照原先的设计去做一轮迭代,等测试运行一段时间以后,真正好的方案说不定就浮现出来了。
■网友
只要能达到预期的效果,肯定先交付啊,改进永远都是没完没了的,你今天好的想法明天说不定就过时了,还不如先用起来,根据实际使用情况再进行修改。
■网友
如果建一座楼,快盖好的时候发现地基没打好,会推了重建吗?最好是通过细微的调整尽量加固吧。


    推荐阅读