來這家公司三周了
,工作基本進入正軌
,也已經熟悉了周圍的生活。
工作有條不紊的進行中，大面上完成的還可以吧，但具體細節方面，依然很亂，例如控制項大小，驗證，什麼情況下可用，什麼情況下不可用，這些都要慢慢完善，等待開會統一中，呵呵。
因為很多地方需求並不完善，
boss
們還在討論中，我們只是在開發需求相對比較穩定的地方，只能說是相對，遇到問題，仍然需要討論。
那天我跟
boss簡單提了提：
是不是可以每個人根據對需求文件的理解，自己寫自己那一塊的詳細設計文件，然後根據詳細設計進行編碼，然後有不通的，繼續討論，然後完善文件，修正**，這樣進行。
我提出這個問題，基於以下原因：
1、這次開發是第一次迭代，主要是暴露那些需求中沒有考慮到的問題，然後再後續迭代中進行完善，但我們一頭紮進開發，需求不明確的地方，只是討論，然後簡單記錄，供需求文件編寫人員進行修改，結果開發的時候，依然憑這些簡單記錄和自己的理解進行模糊開發。這可能會導致，開發與需求文件並不吻合。而且，後續迭代的時候，並不能很好的規避掉以前遇到的問題，因為記錄不規範。 2
、僅僅根據乙個需求設計說明書在做開發，太過粗糙，而且開會討論，討論結果直接在需求設計文件上修改，並不能看出前者和後者的區別，後續迭代中，並不能發現關鍵問題。 3
、平時的討論和自己開發過程中遇到的問題不能及時記錄反饋，很多時候憑個人意志進行隨意開發，當時自己明白，但後來者肯定是不明白的，很可能過些天自己都不明白了。 4
、我們的討論總是在說，沒有落實的紙面上，導致我們的討論總是很漫長，而且得不到乙個結論。 5
、沒有詳細設計，隨意開發，**看起來混亂不堪，例如，到處都是隱含域，這些隱含域也只有作者才明白什麼意思。大量
js冗餘**，不能做到良好的封裝。
我的想法，被
boss
否掉了，理由：過於理想化，因為畢竟系統過於龐雜，不可能短時間內搞定詳細設計，伴隨著需求進一步明確，還要繼續修改詳細設計，編碼過程中，又會發現，需求有問題，自然又要更改詳細設計文件，最後花在文件上的時間非常龐大，可能見不到效果，領導看不到實際的東西，後果很嚴重。
最後，採取的折中的方式，大家都把各自的模組的遺留問題，整理出來，然後把需求不明確的地方做好記錄等等，簡單來說就是，開始強調做記錄的重要性了。
但我看了大家的**，注釋少得可憐，估計後續迭代，還有未來的維護人員，會叫苦不堪了。
boss
的想法，依照乙個簡單的需求文件，在編碼中討論並完善需求文件，以備二次開發。
我的想法，依照乙個簡單的需求文件，編寫乙個基本的詳細設計文件，然後在一次迭代中，完善需求，完善設計文件，以備二次開發。
我也不知道哪個更好一些，但前者，在二次迭代中肯定會花更多時間去編碼，甚至在三次迭代中補文件，但可以快速出成果。
後者，一次迭代可能浪費時間在設計文件上，但二次迭代可依據文件詳細，可以節省時間，當然也會繼續完善文件，爭取在三次迭代的時候，文件已經基本成型。
還是得按
boss
的想法走，但我依然覺得沒有詳細設計，直接搞編碼並不明智。
我的工作日誌1
來這家公司三周了 工作基本進入正軌 也已經熟悉了周圍的生活。工作有條不紊的進行中，大面上完成的還可以吧，但具體細節方面，依然很亂，例如控制項大小，驗證，什麼情況下可用，什麼情況下不可用，這些都要慢慢完善，等待開會統一中，呵呵。因為很多地方需求並不完善，boss 們還在討論中，我們只是在開發需求相對比...
我的工作日誌
沒有系統對日期補0,只有手動補0 針對leadbbs資料庫的,board popfun.asp 作用 日期處理 例子 gettimevalue now 結果 20041008095752 function gettimevalue datestring dim temp,tempstr if isn...
工作日誌1
乙個頁面通過介面獲取oslist,通過篩選出id 然後賦值給release中的os，因為我最後是提交release中的表單資料 我一開始想的辦法的使用過濾器，在過濾器中獲取oslist，但是發現過濾器中this無法賦值，只能另闢蹊徑 然後我投機取巧用了select下拉框，因為option可以獲取os...