推 LaPass:不，會出現.... 妳別用哪種複雜的寫法，用最簡單的方法去寫 09/12 22:10
→ LaPass:就好，然後叫你用她的style去寫 09/12 22:10
→ NDark:離開是另一種選擇.但下一個並不能保證會更好. 09/12 23:16
※ 引述《scasur (Wei)》之銘言：
: 是這樣的，主管最近要求凡是修改檔案一律
: 1. 以註解夾住修改的地方
: 2. 原本的程式註解掉，不要刪掉
: 所以原本改完一行變四行，例如:
: 我和同事是有表達我反對的意見啦，
: 不外乎是: 破壞可讀性、應藉由版本控管紀錄歷程、重要的再寫，不要全部寫...
: 但好像不被聽進去。
我完全同意你的看法.
我也遭遇到你的相同困境.
我猜想,這可能是"曾經"沒有使用版本控制的"資深"程式人員所帶出來的習慣.
(我不敢斷然推測是硬體程式人員,因為我從未與硬體程式人員工作過.)
然而,改變人是一件困難的事情.
改變資深或上級人員的觀念又格外困難.
因此,我能建議你的,也就是我所進行(推動中)的折衷方案.
1.推動以檔案為單位的責任區分.(順利的話可以連帶引入doxygen的註解寫法)
2.新撰寫的模組,盡量與原先(已經被污染)的程式碼用檔案作區隔.
3.透過1與2,減少程式人員互相在對方地盤撰寫程式碼的機會.
如果無法避免,使用method/function切割開.
4.磨練(polish)自己的程式碼,以自己所撰寫的模組做準則,
讓那些人知道這樣的寫法所造成的 "美" 到底是一個什麼景象.
不要給自己有藉口沉淪.
: 2. 原本的程式註解掉，不要刪掉
當我希望團隊能夠移除已不需要(已註解)的程式碼時
我所得到的是很輕蔑的回應:
"有什麼差別嗎?"
當時我才深刻體認到
在不同的知識經驗基礎上談事情,很難溝通及達成共識.
對於資深及上級人員可能沒辦法改變,
但是我只能鼓勵你比較樂觀的看法也許是
默默中有新人,或新進人員會追隨上你.
--
"May the Balance be with U"(願平衡與你同在)
視窗介面遊戲設計教學，討論，分享。歡迎來信。
視窗程式設計（Windows CLR Form）遊戲架構設計（Game Application Framework）
遊戲工具設計（Game App. Tool Design ）
電腦圖學架構及研究（Computer Graphics）
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.164.83.38