这是一个创建于 1500 天前的主题，其中的信息可能已经有所发展或是发生改变。
本人在校学生，最近有两门课程布置的项目需要同学组队从零开始对需求进行设计并实现以及后续测试。
- 其中一门项目（比较玩具）已经进入了编码实现阶段，然而就在实现时发现了设计中存在的问题，具体情形如下：
- 编码时感觉类图中设计的方法不合理，比如缺少一些参数的传递；
- 编码时开始自由发挥，不再参考类图与时序图。
- 另一门项目（比较正式）马上要开始进入对需求分析并设计的阶段了，我很害怕同样的情形再次发生，因为这个项目队友较多，如果在设计时出现错误，后续实现沟通起来感觉会很麻烦（不想说外语），所以想请教各位前辈如何避免类似的问题。
总结起来其实就是：
- 许多细节上的问题在没有真正写代码前意识不到，只有在真正开始写代码的时候才会发现，如何能够在设计时尽可能地考虑到更多情况？
- 在设计已经完成的情况下，写代码时发现确实出现问题，该如何进行补救？如何确定是设计上出现的问题而不是代码能力的问题？
有个额外的问题就是：
- 在工作后，会发生这类问题吗？本人还没有在一个比较正规的公司实习过，所以很好奇在工作中的一些流程。前辈们写代码时是已经有明确设计好的逻辑，只是负责将语言或者 UML 图翻译成代码，还是只是拿到分析好的需求需要自己进行一些逻辑上的设计？
感谢前辈们的耐心和解惑，谢谢🙏
 |
1
reus 2020-10-08 16:12:59 +08:00 via Android  1
瀑布模型早就过时，敏捷方法更能适应变化
简单来说就是多次迭代，上一次设计有错误，那下一次迭代就修正，不追求一次设计就完全正确 |
 |
2
xuanbg 2020-10-08 16:29:11 +08:00
>许多细节上的问题在没有真正写代码前意识不到，只有在真正开始写代码的时候才会发现
这个不就是「盲人摸象」吗？好好地理解业务，正确定义业务对象，理顺对象之间的关系。不要见着平面就是墙，见着细条就是绳子。 |
 |
3
wzzzx 2020-10-08 17:12:35 +08:00
这是非常正常的丫，所以才需要评审方案+code review
|
 |
4
DiamondY 2020-10-08 17:15:17 +08:00 1
任何具体化的设计都不可能完美无错，看起来完美的只有那些模糊不清的概念
|
 |
5
renmu123 2020-10-08 17:42:45 +08:00 via Android
肯定会出现，会因为业务修修改改，如果时间够会认真思考进行重构，没有的话就剩下一坨屎山了，技术负债不是瞎说的
|
 |
6
charlie21 2020-10-08 18:14:40 +08:00 5
一般是还要让你们进行敏捷开发，每两周提交一个软件新版本的那种，是不是？哈哈
如果是学校项目 5 人小组并且要求几个版本程序（迭代），那么对于第一版程序，就 1 个人出方案，4 个人审核方案提出小改意见，看没啥大问题了之后就按这个方案走 就第一版程序的设计和实现而言： 0 团队合作（把任务分给成员、成员写完、试图整合、整合失败不知道哪错了）会让第一版程序难产 1 个人行动比团队行动更快，尤其当团队里的人都是菜鸟的时候，别人自己都写完了你还在帮菜鸟 debug 还不如直接重写更快，队友就添乱，导致第一版程序难产 2 对于第一版程序，主要是定下来谁收拾烂摊子 3 在第一版程序出问题之后由提方案的那个人（作为主程）主动收拾烂摊子：甚至把第一版程序推翻重做 对于学校项目 5 人小组，一般只有 1 或 2 个人会非常 carry 。对于第一版程序，到最后基本上就是他或他们自己（作为主程）直接把第一版程序全搞定了，其他人在第三版或第四版程序的时候才开始插手。实际工作中也是 项目早期都是一个人设计并实现的。 对于第一版程序，主要责任就在主程一人，团队成员只有在集思广益 or 提一些小意见 的阶段 还有点儿用。 对于后续几版程序，可以逐渐安排每个人都在做什么。即使出现了烂摊子，鉴于第一版程序足够坚实，前几版程序足够坚实，那么新一版程序出问题可以很快扫尾，大不了就是退回到前一个 version 重做嘛。 - - 实际工作中，一是主程操刀第一版程序，菜鸟不会碰也不敢碰，也不能让碰，通常都不会让插手；二是对于第一版程序 如果主程无法对第一版程度负责，那么直接被开掉 换人 因为一个无法承担责任的人是不能主导第一版程序的，人不行；三是对于第 n 版程序，定责定得比较好，菜鸟级开发者只会被分配到菜鸟级开发任务，若菜鸟级开发者出问题了（很可能发生！）会被边缘化，同时鉴于之前对于项目风险和人员风险的预判，即使项目被菜鸟糟蹋了 项目本身不会出现致命伤；四是致命伤只可能发生在第一版程序里，因未考虑到项目整体复杂度而产生致命伤而不得不推翻重做的情况是很常见的。 参考 http://www.uml.org.cn/xmgl/201110132.asp 风险控制主要是在第一版程序里。在第一版程序出炉之后，其他人在主程的指导下工作开发出第 n 版程序。 - （但是对于一个从零开始的项目而言，如果你是主程，那么通常是要做好一个人全包的准备，为什么呢？因为同学们往往是非常幼稚的，他们认为 第一版程序就应该已经完成全部功能的 80% 以上的功能都已经实现了，就像他们经常玩的 SDK 一样 所有东西都是现成的 他们只要 call 什么函数 就 OK 了，即使你想分模块开发 你也分不出来 ... 因为他们对软件开发的基本概念是没有的，比如 生命周期、线程阻塞，如果不知道这些那么程序是跑都跑不起来的 哈哈哈哈，他们真的只能被分配到菜鸟级开发任务，而这些任务往往在项目推进到第三版或第四版程序的时候才会出现。 - |
 |
7
greatbody 2020-10-08 19:06:08 +08:00
敏捷，拥抱变化，持续迭代，代码重构，契约。
|
 |
8
namelosw 2020-10-08 23:03:20 +08:00
流程什么都是形式，没有卵用，UML 一般也是多余的，最多沟通可以用一下，也没有白板简单画一画效率高。
可能的情况下是不要做设计，然后平铺+重构。不管多好的架构师预先设计多少都可能会埋坑。平铺的话形状定下来还比较好重构。不平铺的话就是 make assumption，很容易在错误的道路上越走越远。 如果是那种必须预先设计的环境，就比较坑了，只能尽量，不用太纠结。 没事可以看看《重构》，总得来说就是开发和重构快速交替进行，不要等着全做完了再改，做完就没机会改了。比如你这两天要做一个小任务，觉得本来的设计有问题，不好加新功能，那先把觉得有问题的部分捋顺了再加，不然就是往上积累问题。 |
 |
9
XiLemon 2020-10-08 23:59:25 +08:00
只是代码层面的重构，问题不大。如果有表结构的修改，上线之后产生了历史数据，还挺麻烦的。
另外，也没时间重构，因为改完之后，还要测试去测。 感觉一开始不可能有完美的设计，只能多积累经验，争取下次少挖坑吧 :-) 坐看其他楼有没有更好的建议和方法。 |
 |
10
DoctorCat 2020-10-09 02:54:35 +08:00
听起来是不够了解业务，以至于难以抽象出合理的代码结构。这倒是与瀑布开发、敏捷等过程没直接关系。
当年做学生的时候做项目也遇到过类似的情况… 后来开发经验多了起来，考虑问题就越来越周全了。 关于如何改善，我觉得首先要承认自己在经验不足，不要惧怕，多与经验丰富的人一起白板讨论，不懂就问。 其次，UML 确实是一种有效的建模方法，但毕竟只是个方法论工具，前提还是要有具体的业务经验才行。 实操建议：可以尝试 TDD 方式驱动代码实现，这样在写测试用例的时候会有对业务细节的主动思考过程。 |
 |
11
HenryWang0723 2020-10-09 08:45:36 +08:00
弱弱的问一句真的有人用 uml 转化代码吗
|
 |
12
dream4ever 2020-10-09 10:56:44 +08:00
经验不足肯定会这样，也要接受这种不断变化的状态。
|
 |
13
useben 2020-10-09 15:24:35 +08:00
时刻重构, 才不会不敢重构
|
Select Language