我的工作日志1
来这家公司三周了,工作基本进入正轨,也已经熟悉了周围的生活。
工作有条不紊的进行中,大面上完成的还可以吧,但具体细节方面,依然很乱,例如控件大小,验证,什么情况下可用,什么情况下不可用,这些都要慢慢完善,等待开会统一中,呵呵。
因为很多地方需求并不完善,boss们还在讨论中,我们只是在开发需求相对比较稳定的地方,只能说是相对,遇到问题,仍然需要讨论。
那天我跟boss简单提了提:是不是可以每个人根据对需求文档的理解,自己写自己那一块的详细设计文档,然后根据详细设计进行编码,然后有不通的,继续讨论,然后完善文档,修正代码,这样进行。
我提出这个问题,基于以下原因:
1、这次开发是第一次迭代,主要是暴露那些需求中没有考虑到的问题,然后再后续迭代中进行完善,但我们一头扎进开发,需求不明确的地方,只是讨论,然后简单记录,供需求文档编写人员进行修改,结果开发的时候,依然凭这些简单记录和自己的理解进行模糊开发。这可能会导致,开发与需求文档并不吻合。而且,后续迭代的时候,并不能很好的规避掉以前遇到的问题,因为记录不规范。
2、仅仅根据一个需求设计说明书在做开发,太过粗糙,而且开会讨论,讨论结果直接在需求设计文档上修改,并不能看出前者和后者的区别,后续迭代中,并不能发现关键问题。
3、平时的讨论和自己开发过程中遇到的问题不能及时记录反馈,很多时候凭个人意志进行随意开发,当时自己明白,但后来者肯定是不明白的,很可能过些天自己都不明白了。
4、我们的讨论总是在说,没有落实的纸面上,导致我们的讨论总是很漫长,而且得不到一个结论。
5、没有详细设计,随意开发,代码看起来混乱不堪,例如,到处都是隐含域,这些隐含域也只有作者才明白什么意思。大量js冗余代码,不能做到良好的封装。
我的想法,被boss否掉了,理由:过于理想化,因为毕竟系统过于庞杂,不可能短时间内搞定详细设计,伴随着需求进一步明确,还要继续修改详细设计,编码过程中,又会发现,需求有问题,自然又要更改详细设计文档,最后花在文档上的时间非常庞大,可能见不到效果,领导看不到实际的东西,后果很严重。
最后,采取的折中的方式,大家都把各自的模块的遗留问题,整理出来,然后把需求不明确的地方做好记录等等,简单来说就是,开始强调做记录的重要性了。
但我看了大家的代码,注释少得可怜,估计后续迭代,还有未来的维护人员,会叫苦不堪了。
boss的想法,依照一个简单的需求文档,在编码中讨论并完善需求文档,以备二次开发。
我的想法,依照一个简单的需求文档,编写一个基本的详细设计文档,然后在一次迭代中,完善需求,完善设计文档,以备二次开发。
我也不知道哪个更好一些,但前者,在二次迭代中肯定会花更多时间去编码,甚至在三次迭代中补文档,但可以快速出成果。
后者,一次迭代可能浪费时间在设计文档上,但二次迭代可依据文档详细,可以节省时间,当然也会继续完善文档,争取在三次迭代的时候,文档已经基本成型。
还是得按boss的想法走,但我依然觉得没有详细设计,直接搞编码并不明智。