我的工作日志1

来这家公司三周了,工作基本进入正轨,也已经熟悉了周围的生活。

 

工作有条不紊的进行中，大面上完成的还可以吧，但具体细节方面，依然很乱，例如控件大小，验证，什么情况下可用，什么情况下不可用，这些都要慢慢完善，等待开会统一中，呵呵。

 

因为很多地方需求并不完善，boss们还在讨论中，我们只是在开发需求相对比较稳定的地方，只能说是相对，遇到问题，仍然需要讨论。

 

那天我跟boss简单提了提：是不是可以每个人根据对需求文档的理解，自己写自己那一块的详细设计文档，然后根据详细设计进行编码，然后有不通的，继续讨论，然后完善文档，修正代码，这样进行。

 

我提出这个问题，基于以下原因：

1、这次开发是第一次迭代，主要是暴露那些需求中没有考虑到的问题，然后再后续迭代中进行完善，但我们一头扎进开发，需求不明确的地方，只是讨论，然后简单记录，供需求文档编写人员进行修改，结果开发的时候，依然凭这些简单记录和自己的理解进行模糊开发。这可能会导致，开发与需求文档并不吻合。而且，后续迭代的时候，并不能很好的规避掉以前遇到的问题，因为记录不规范。

 

2、仅仅根据一个需求设计说明书在做开发，太过粗糙，而且开会讨论，讨论结果直接在需求设计文档上修改，并不能看出前者和后者的区别，后续迭代中，并不能发现关键问题。

 

3、平时的讨论和自己开发过程中遇到的问题不能及时记录反馈，很多时候凭个人意志进行随意开发，当时自己明白，但后来者肯定是不明白的，很可能过些天自己都不明白了。

 

4、我们的讨论总是在说，没有落实的纸面上，导致我们的讨论总是很漫长，而且得不到一个结论。

 

5、没有详细设计，随意开发，代码看起来混乱不堪，例如，到处都是隐含域，这些隐含域也只有作者才明白什么意思。大量js冗余代码，不能做到良好的封装。

 

 

我的想法，被boss否掉了，理由：过于理想化，因为毕竟系统过于庞杂，不可能短时间内搞定详细设计，伴随着需求进一步明确，还要继续修改详细设计，编码过程中，又会发现，需求有问题，自然又要更改详细设计文档，最后花在文档上的时间非常庞大，可能见不到效果，领导看不到实际的东西，后果很严重。

 

最后，采取的折中的方式，大家都把各自的模块的遗留问题，整理出来，然后把需求不明确的地方做好记录等等，简单来说就是，开始强调做记录的重要性了。

但我看了大家的代码，注释少得可怜，估计后续迭代，还有未来的维护人员，会叫苦不堪了。

 

boss的想法，依照一个简单的需求文档，在编码中讨论并完善需求文档，以备二次开发。

我的想法，依照一个简单的需求文档，编写一个基本的详细设计文档，然后在一次迭代中，完善需求，完善设计文档，以备二次开发。

 

我也不知道哪个更好一些，但前者，在二次迭代中肯定会花更多时间去编码，甚至在三次迭代中补文档，但可以快速出成果。

后者，一次迭代可能浪费时间在设计文档上，但二次迭代可依据文档详细，可以节省时间，当然也会继续完善文档，争取在三次迭代的时候，文档已经基本成型。

 

还是得按boss的想法走，但我依然觉得没有详细设计，直接搞编码并不明智。