在學校里,一直都知道,做事情(開發)要有規范,應該先怎樣,然后怎樣,最后做什么,這些都是知道的,而且還是學的重點。可是,真真到了崗位上,真真要自己動手的時候,什么都拋掉了!
只圖方便,只圖快捷,根本就不管什么可讀性,什么可維護性,連注釋都沒有,更不用說什么文檔的。昨晚也想到要好好的寫寫文檔,可是今天到了公司,又不愿意寫了。其實,也是另有內情:我實在是不知道,到底該如何下手。
所以,我也請曉鳴能夠把他以前寫的文檔,借我看看,讓我好有個參考,看看到底大致該怎么寫,應該寫些什么內容。
當然,這次,我也暫且先不寫,一方面,考慮到,目前為在做的只是一個試用版,日后一定會再做過的;另一方面,錢好像急著想用它,就先完成它再說吧(也許完成后,再來寫文檔也好,我知道,這個不可取,可總比沒有好)。
剛剛,我也想到,等這個完成,給錢之后,讓他先去跑跑看;然后,我再拋掉所有的東西,重頭做過。到時候要好好的做!
可是,我把這個想法跟曉鳴說了之后,問他我有沒有可能重新做過,他卻說不大可能。郁悶......看不起我!呵呵......也以此為鑒吧!希望我日后,不要如曉鳴所言,而且,這個算是我的第一個項目,一定要好好做才行。
寫此文以記之,望日后自省,望同仁提點!
PS:我也深刻認識到,沒有寫文檔所帶來的麻煩:盡管大致的結構、功能,心理都清楚,可是很多小地方,細節的東西,都是到了臨時才會想起來,這樣的開發,不僅沒有質量保證,而且效率也不高!很多時候,還要仔細地想清楚,到底有沒有什么細節沒有考慮進去。
所以我覺得開發文檔相對次要, 首先要注重的是, 良好的風格, 獨立的模塊, 清晰的結構 .
<<重構>>中有一句話: 需要注釋的地方, 也就是需要重構的地方.
說得也有道理,不過個人感覺,如果說文檔已經確定要求和確定設計,可是到后來卻發現當初的需求、設計和現在有變差,那有一定的原因是因為當初的需求和設計沒有做好!
良好的風格, 獨立的模塊, 清晰的結構! 這些我非常的贊同!
現在彪悍,不一定以后也彪悍!
你認為彪悍,別人不一定認為彪悍!
所以,注釋感覺還是必要的,而且這樣也有助于增強代碼的彪悍性!
呵呵......個人愚見!
不能純代碼,更不能沒有注釋。
“<<重構>>中有一句話: 需要注釋的地方, 也就是需要重構的地方.”
這句話我不贊成。試問,有多少個人能把自己要做的事寫清楚的?如果你自己都搞不清楚,那你不寫注釋,人家怎么看?如果只是你自己的代碼就算了,但你寫的代碼是公司的時候,就應該在該寫的地方寫注釋。
書不是全對的,再說了書也是人寫的,人總是有局限性的。
切記,切記。
很贊同! 人是有局限性的!
如果把注釋作為后續維護的依據.那需求變化導致的變更會讓文檔變得比沒有還難受.
當然老板提供每月100行代碼的寬松工作要求除外.這時就沒有理由不做好文檔的更新和同步的工作了.
這句話的意思是: 良好的代碼是自我注釋的.
我認為文檔的存在,是有利于需求的變更處理的,而不是起到羈絆作用。
試想,如果你連當初的想法都不清楚,到時候需求真的要改的時候,你根本就不知道這個需求到底是變在哪里,更不用說什么需求變更的管理了,當然也不清楚如何來評價這個變更的影響。
到時候,也許做出來的東西根本就不是當初預想的東西。
另外,如果沒有文檔的確定,客戶的需求變更如何確定是變更? 也許,碰到惡心的客戶說他當初根本就是這么跟你說的,那豈不是“啞巴吃黃蓮”!
結論:文檔是一定要的!
讓人看不懂,
這說明這句話存在問題。
好的代碼,代碼本身就是注釋。
只有不夠良好的代碼,才需要注釋去詮釋代碼。
雖然我們稱之為代碼,
其實質還是語言,最重要的是首先保證人可以看懂,人都看不懂,就不好維護,不好維護的代碼也就失去了其生存的價值。
規范并不意味著注釋就是萬金油,
良好的命名,良好的代碼風格,這些比注釋更重要。
文檔不一定意味著是注釋,
程序的使用幫助文檔,就和注釋沒有必然聯系。
保持一個良好的命名習慣,
良好的代碼書寫風格,
具備這兩點就足夠了。