這叫做"有呆丸特色的軟體工程"... :p

+111111111111111111111
反串判定無誤

這些都還好,
真正惡劣的是主管他自己不懂還排擠懂的人, 說你不合作!

你們不會就是這一堆裡講的人吧?
沒看過 opensource 嗎? 沒聽過 linux ?
來看看 linux 文件怎麼寫的 -> kernel.org
沒有人文件是在寫他們的程式是寫什麼意思的.
他們是台式風格嗎? 哈!


:laugh:

所有文件都要有個基本的註解讓人能夠比較好閱讀, 但也不需要到像在寫幼稚園書一樣.

不過我個人經驗啦, 有時候主管只是確認有沒有什麼他/她漏掉的, 怕下屬搞小動作.

更多時候, 只是要讓你白紙黑字的證據, 有事情就推給你, 沒事情就說是他/她協助的.

事實上code review 可以是同事間互相review..
看不懂而需要解釋, 只有兩個可能..
1.review 的人程度低..
2.原作者寫錯了..
希望您哪天不會review到高手..

x9999999

反諷文沒錯！

:laugh:

因為美國 Cisco 的 programmer 作業流程也是如此！

－

哎...要是老闆不想拌黑臉,
那遇到"高手"把 C 當成組合語言在寫的,怎麼做code review都沒用啦!

連資料結構要做轉換的理由都說不清楚的"程式設計師"怎麼辦 ?
笑罵由人,好話歹話說盡,寫出來的東西永遠讓人傻眼.

UML學了半天,只學到把function name後面加個UCO ...
:tu: :tu: :tu:

關於程式註解這件事，
是協助其它人更能了解原始程式設計師設計理念的方法而已，
如果一個程式寫出來，
只有自已才看得懂，
或者要所謂的程設高手才看的懂，
這樣無形中就增加了後續維護的成本
(本來找一個初階的SD就可以處理，卻變成要找一個OpenSource的高手)
這是不是好程式，
就值得商確了。

另外，
本文舉的幾點，
其實在軟體工程上，
都有執行的好處，
不過他們都有一個共通點，
就是會增加SD的工作量(在台灣)，
所以實務上，
實行起來是會有困難的(因為工作量增加了，但是資源沒增加)，
這是台灣軟體工程的一個困境。 :think:

你肯定不是做linux/opensource的?
現在看懂opensource早已是最低門檻了, 看不懂的根本做不了,
現在一堆linux產品, 手機,網通,甚至是電視機上盒...等等
這代表有很多人都看得懂, 不需要什麼程式說明文件, 難到這些人都是高手嗎? 並不是吧!
看懂opensource是最低門檻, 跟不上的很快就會被淘汰的.

作者已經講很明了, 請加強自己的程式技術吧!
以前那一套早就已經不適用了, 只會拖累好的人而已.


:think: