主管要求註解代替刪除 2

作者: NDark (溺於黑暗) 看板: Soft_Job
標題: Re: [閒聊] 主管要求註解代替刪除
時間: Fri Sep 14 00:29:31 2012

※ 引述《scasur (Wei)》之銘言：

: 我們主管會這樣要求，也是有苦衷的。我們部門提供整個公司的各種業務需求，前台後台
: 各種共用性非常氾濫，資料庫、交易程式、報表程式都有跨部門共同使用的可能。再加上
: 需求很常變更。我們主管面對的問題:
: 1. 當有user打電話來問問題的時候，他希望可以很快找到為什麼這樣做。
:    所以他看code，看夾起來的需求單單號，然後回應對方，
:    證明是有人要求我們這樣做的，而不是我們的問題。

這好解決不是問題.
需求單可以一整塊寫在實作前.也可以寫在宣告前.達成共識就好.
實作的人員本來就應該指出實作是依據哪一個規格實作.
是因為沒有依據功能來封裝才會導致這種說明呈現破碎.





: 3. 他想要看到過去的歷程，原因:
:    3-1 原本甲寫的是對的，乙改壞了，可以看的出來。
:    3-2 user的需求從A變成B，現在要變成A。
:        就可以發現，咦! 你之前才把A改成B，你確定要改回來?


前專案我是軟體頭的時候.我制定的方式是.以檔案(模組)為責任區分.


但是開發進行中不乏會互相支援.

ex. 模組A ( @author PG甲 ) , PG乙來支援

1. PG乙動工之前要先諮詢PG甲(踩到對方地盤要有禮貌)
   因此PG乙的撰寫是在PG甲的授權(review)下.
2. 模組A出問題 PG甲要負責修(這塊地盤給你管,沒有任何藉口說別人幫你製造bug)
3. 如果對開發沒有共識,或是無法釐清責任.主管要負責出來協調,及找出是誰搞的鬼.
                                                  (不是放任下面的人殺來殺去)
                                      (這是主管展現技術權威的好機會,
                                       每次搞定一個trouble,
                                       下次說話就更有份量)
4. 能實行以上有一個大前提,
   我開發底層系統時大模組切的很好.
   所以即便個別模組寫壞,其他模組不容易被牽涉(污染)到.
   責任區分非常容易.就算是一個共通的底層模組出問題.
   隨時把元件拔掉系統依然必須可以繼續運作.(當然這是下過苦工的)



現在我不是專案軟體頭了.底層系統也不是我負責的.
所以我的策略也就跟著改變.
除非被指定,不要費心去革命.
因為別人不會感謝,主管也看不到.
把自己模組獨立出來.
如果別人對開發有意見,請教對方該怎麼改?實際上計畫是如何?
                                       (大部分人都會在這招被打倒,
                                        因為很多人說的一口好概念,
                                        但是當提到細節時卻漏洞百出,之嗚其詞
                                        因為要求別人總是比較容易)
若是擋不住,最好至少逼著任何人把規格寫下來.(白紙黑字的護身符)
有需求,就照規格做.有做錯,先回頭看(確認)是不是規格就寫錯了.下次記得要問仔細點.





對於改來改去的問題.
我比較傾向 可以留下註解.但是在兩個前提下
1. 註解清楚,為什麼留下來.
2. 切割清楚,用封裝,繼承或任何方法,把新舊方法切割開來.



--
"May the Balance be with U"(願平衡與你同在)

視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.164.49.49