|
||
|
*停權中*
加入日期: Dec 2004
文章: 222
|
引用:
這叫做"有呆丸特色的軟體工程"...  |
||||||||
2012-11-12, 02:52 PM
#11
|
|
|
Advance Member
  加入日期: May 2005
文章: 433
|
引用:
+111111111111111111111 反串判定無誤 |
|||
|
2012-11-12, 02:56 PM
#12
|
|
|
*停權中*
加入日期: Dec 2010
文章: 196
|
這些都還好,
真正惡劣的是主管他自己不懂還排擠懂的人, 說你不合作! |
|
2012-11-12, 03:03 PM
#13
|
|
|
*停權中*
加入日期: Nov 2012
文章: 0
|
引用:
你們不會就是這一堆裡講的人吧? 沒看過 opensource 嗎? 沒聽過 linux ? 來看看 linux 文件怎麼寫的 -> kernel.org 沒有人文件是在寫他們的程式是寫什麼意思的. 他們是台式風格嗎? 哈!  |
|
|
2012-11-12, 03:07 PM
#14
|
|
|
*停權中*
加入日期: Dec 2006
文章: 944
|
所有文件都要有個基本的註解讓人能夠比較好閱讀, 但也不需要到像在寫幼稚園書一樣.
不過我個人經驗啦, 有時候主管只是確認有沒有什麼他/她漏掉的, 怕下屬搞小動作. 更多時候, 只是要讓你白紙黑字的證據, 有事情就推給你, 沒事情就說是他/她協助的. |
|
2012-11-12, 03:18 PM
#15
|
|
|
Basic Member
加入日期: Apr 2005
文章: 16
|
引用:
事實上code review 可以是同事間互相review.. 看不懂而需要解釋, 只有兩個可能.. 1.review 的人程度低.. 2.原作者寫錯了.. 希望您哪天不會review到高手.. |
|
|
2012-11-12, 03:41 PM
#16
|
|
|
Regular Member
 
加入日期: Mar 2003
文章: 96
|
引用:
x9999999 反諷文沒錯！ 因為美國 Cisco 的 programmer 作業流程也是如此！ － |
|
|
2012-11-12, 04:00 PM
#17
|
|
|
Advance Member
加入日期: Jul 2012 您的住址: 新竹
文章: 409
|
引用:
哎...要是老闆不想拌黑臉, 那遇到"高手"把 C 當成組合語言在寫的,怎麼做code review都沒用啦! 連資料結構要做轉換的理由都說不清楚的"程式設計師"怎麼辦 ? 笑罵由人,好話歹話說盡,寫出來的東西永遠讓人傻眼. UML學了半天,只學到把function name後面加個UCO ...  |
|
|
2012-11-12, 04:12 PM
#18
|
|
|
Basic Member
加入日期: Dec 2004
文章: 22
|
關於程式註解這件事，
是協助其它人更能了解原始程式設計師設計理念的方法而已， 如果一個程式寫出來， 只有自已才看得懂， 或者要所謂的程設高手才看的懂， 這樣無形中就增加了後續維護的成本 (本來找一個初階的SD就可以處理，卻變成要找一個OpenSource的高手) 這是不是好程式， 就值得商確了。 另外， 本文舉的幾點， 其實在軟體工程上， 都有執行的好處， 不過他們都有一個共通點， 就是會增加SD的工作量(在台灣)， 所以實務上， 實行起來是會有困難的(因為工作量增加了，但是資源沒增加)， 這是台灣軟體工程的一個困境。 
__________________
Don't Worry Be Happy! |
|
2012-11-12, 05:25 PM
#19
|
|
|
*停權中*
加入日期: Nov 2012
文章: 0
|
引用:
你肯定不是做linux/opensource的? 現在看懂opensource早已是最低門檻了, 看不懂的根本做不了, 現在一堆linux產品, 手機,網通,甚至是電視機上盒...等等 這代表有很多人都看得懂, 不需要什麼程式說明文件, 難到這些人都是高手嗎? 並不是吧! 看懂opensource是最低門檻, 跟不上的很快就會被淘汰的. 作者已經講很明了, 請加強自己的程式技術吧! 以前那一套早就已經不適用了, 只會拖累好的人而已. |
|
|
2012-11-12, 05:44 PM
#20
|
|
