這樣的方式我應該如何選擇--文件與經驗傳承

作者: ggg12345 (ggg) 看板: Soft_Job
標題: 這樣的方式我應該如何選擇--文件與經驗傳承
時間: Thu Apr  5 21:45:11 2012

※ 引述《howshou (好小 )》之銘言：
: : 3.至少運作3年的專案基本上技術文件量基本上會扎實龐大，讓接續的人不必耗時費工，
: : 我並沒有碰到
:
:     如果你真的有認真看過文件，你會越來越不相信文件。
:     我記得前幾年我看約耳談軟體(Joel on Software)這本書時，
:     覺得超有幫助的，果然任何變更都要有文件。先有文件再寫軟體。
:     所有的專案管理經驗與書籍也會告訴你， 寫文件比寫程式重要。
:     它們說得都對，你說的也對。
:
:     但是我不知道為什麼，現實生活就是窒礙難行。
:     最常發生的就是，遇到問題，找出文件來看，奇怪?
:     文件怎麼沒寫這個函數是什麼意思? 文件怎麼沒寫這個DLL檔怎麼用...?
:     總之文件就是與程式碼不同。最後程式碼就變成唯一的文件。
:
:     之所以會出現這種問題，原因很多，不過現實就是:
:     文件寫得好沒薪水，程式寫得好有薪水。
:     文件寫得好沒人看，產品做得好有人買。
:
:     當你事情多到整個專案流程都要做時，你會認真寫文件嗎?
:     先寫程式再說吧，別再當聖人了。
:     我想很多人就是因為這樣的因素，寫出一堆不能用的文件。
:     這樣的環境，你還奢求大量的文件，這種文件大概也不能用。


這段說得非常中肯, 認真寫文件到底是為了甚麼?
軟體工程講的應該不會是為了文件而文件.

現在寫程式除了將寫程式的可讀性提高到程式碼就是同時也是說明文件,
除了用來協助自己免昏了頭外, 還得加寫測試程式片段以證明模組的程
式碼無誤. 基本上這是用來增強寫程式的效率, 而不是增加負擔.

:
: : 4.做了這麼久的資料庫，開了這麼多的資料表，寫的這麼簡易的解釋內容，卻沒
: : 有思考架構圖，就像是整個的秘密只有我知道
:
:     我也遇過同樣情形，故意不放圖的人是我。
:
:     1. 沒時間搞圖片。
:     2. 就算把ERD搞出來、A4大小的文件只看到一堆格子與蜘蛛網，對後進有幫助嗎?
:        拿張全開的紙，高成本印出做成摺頁放在文件好了，
:        那個工程師看到會有心情看這錯綜複雜的蜘蛛網?
:
:     做成 Excel 說明我覺得算有良心了。
:     當然若版上有人佛心可以分享更好的紀錄方式，我超想學的。
:
假如採購軟體的或軟體公司本身要求要有這類說明, 前者是因為可賣錢, 後者應該是
做軟體行銷時, 對外宣傳說明所需要. 是假設會利用這類架構與組成關係於更新維護
或企圖藉之說明有助於賣出多套給不同用戶. 如果沒有這些誘因, 頂多是規劃時內部
人員的講解構想圖, 這樣跟最後的成品是不可能完全一致的. 所以這類文件不齊全是
理所當然. 要正確可靠堪用維持與程式碼模組一致, 免不了程式完成後再訂正, 實況
是事後補充的情況居多. 假如買方要求有原始碼還要有技術轉移的教育訓練, 在付費
與買方會派員驗證的先決條件下, 這才有可能被有效的實施.

若把訂製型軟體當做不再更新修改的套裝軟體賣, 顯然是在此架構增減的環節上是無
法應付同類買方的需求. 若說每套訂製型都與眾不同, 做出口碑後, 一套價位可以高
過前一套, 似乎在軟硬體中這類例子應該極為少見. 大型主機的漲價例都是因為新發
明新產品或新增添某些功能而且是少有競爭對手的情況下才有可能.
軟硬體若無法保證可持續維護與更新, 那是不容易有買主的. 但PC硬體因為量產, 所
以傳統的維護更新在台灣都很少見, 但要行銷海外, 沒這類保障還是行不通.

台灣的訂製型軟體似乎就走不出這個 專業型訂製軟體 大量多家訂購 的怪圈. 只要是
這類小規模的軟體業, 他們似乎很 難在這方面做好. 除非有些公司開竅, 以技術轉移
訓練買方的技術人員變成該應用軟體的加盟開發商, 否則這類的架構或概念圖是很難
被要求提升. 內部的技術討論或技術轉移訓練是可以改善這個文件問題, 但只會存在
於賺錢的大公司. 即使在台灣的學校與自製軟體的電算中心, 早期時代透過程式設計
人員來教學上課是能改善這種文件欠缺的現象, 但如今大學的學位掛帥下, 這種方式
就如同公司內新進人員的傳承問題一樣, 在自顧生路下, 這些都是斷鍊.

: : 5.沒有規劃時間，進度，詳細規格，潛在的危機一直圍繞卻沒反應
:
:     規劃時間、規格的是誰? 你問過了嗎? 怎麼問? 有把你的疑惑說了嗎?
:     若他說不用煩惱那你幹嘛煩惱? 責任又不是你扛 。
:     若你覺得別人錯了，為何把錯放在自己心上?
:     一整個不了解其中的邏輯在哪。
:
:  ------------------------------
:     其他問題都懶得一一回答了，發現每個爆炸點都差不多，關鍵在於:
:
:     為什麼你要預設別人一定要照你的思維思考，而不照你思維思考你就要爆炸?
:
:     每個人的想法不同，有時候你覺得直接開SQL 2008拉樹狀圖好理解。
:     別人可能覺得用EXCEL或其他方式清楚。而且當時也沒想到有其他工具。
:     有些人覺得先開發A，B才對，有些人覺得要倒過來先開發B再開發A才對。
:
:     正常人(混口飯吃而已)應該是： 只要能完成專案，大家爽就好。
:     但感覺你的思考邏輯是： 大家請照我的方式，不然我會在背後偷偷爆炸。
:     大家應該更專業一點，而不是用這種我學生時代都不會用的鳥方式。
:     或許你是對的，但是混口飯吃的人也沒錯，
:     只要能完成專案，是沒有人在管你專不專業的，蠻現實的。
:
:     要改變別人的想法太難了，你遇到不如你意的事情，想辦法提升自己就好，
:     不要想提升整個組織或部門。這很自私，但是是你折衷的生存之道。
:
:     當然這都是我從文字上看到片面的看法。若有誤會還請多多見諒。
----------
或許提升整體, 就是為了公司好, 為了這個產業的大家好.
但基本上, 所有的工程方法不都是為了參與的每一方好嗎?

不過, 對每一方都有利的東西一定不是屬於謀略的東西, 即使講究技巧謀略也一定
是內外有別, 何況, 賣方跟買方也是利益一致才是正確的, 最終仍然是每一方都要
能獲利.
不能每一方都獲益, 自然就是在相互磨耗中只求一己之利.

這世界沒有對錯, 生存確實永遠是第一要件. 但不管買方賣方, 同事或部屬, 不能
互利, 當然也就沒有費力製作文件傳承的必要.

放大一點講, 學校幹嘛要亂造一堆資訊人員出來? 沒有用的知識或研究幹嘛讓其留
存? 早該滅種以免禍患才是. 然道台灣的軟體工程是這類的知識方法? 還是被誤解
誤用了?

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