• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Jiang's C++ Space

            創(chuàng)作,也是一種學(xué)習(xí)的過程。

               :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::

            [20060427發(fā)表于blog.csdn.net,20090929重新編輯]

            重新編輯注釋:這是我上上家公司的離職總結(jié),一些技術(shù),幾年沒碰,現(xiàn)在都忘了,我感覺當(dāng)時(shí)我的水平跟現(xiàn)在已經(jīng)差不多了,難道說這幾年都沒什么進(jìn)步?特別是這一年多時(shí)間,我怎么感覺自己心態(tài)變老很明顯。文章中描述的一些問題到現(xiàn)在已經(jīng)得到了比較好的解決,有些卻依然存在,如果各位道友有什么見解,不妨拿出來分享一下。(BTW:當(dāng)時(shí)公司主要是做一些小型網(wǎng)絡(luò)游戲,棋牌類的,從文中能看得出來。)


            對(duì)近日來一些問題進(jìn)行思考,希望能有個(gè)解決方案。
             
            1、數(shù)據(jù)庫方面

            每個(gè)項(xiàng)目都離不開數(shù)據(jù)庫,而數(shù)據(jù)庫的建立過程是個(gè)問題,如何將我們的開發(fā)成果移動(dòng)到運(yùn)營(yíng)環(huán)境中是個(gè)問題,如何維護(hù)以后的更新更加是個(gè)問題,所有的東西都看起來是那么簡(jiǎn)單而缺乏技術(shù)含量,但真的嘗試把它做好卻是非常不容易,人工手動(dòng)來維護(hù)這些文檔是可以的,但恐怕這是一個(gè)專門的工作,如果干這個(gè)的人還同時(shí)做別的事情,總會(huì)無法避免地出現(xiàn)疏漏,我想一定需要借助工具了,而與這些工具的磨合,也是個(gè)不小的成本。

            1)往往忘記寫修改履歷,不知道哪個(gè)是新的,哪個(gè)是舊的
            通病了,希望修改履歷都別忘了寫,包括修改日期、作者和內(nèi)容,這樣就不至于到出了問題找人負(fù)責(zé)的時(shí)候手忙腳亂,至于用CVS來管理怎樣,我沒經(jīng)驗(yàn)。

            2)多個(gè)人同時(shí)直接修改數(shù)據(jù)庫,管理這個(gè)的人很痛苦
            沒有好的解決方案。用CVS來維護(hù)如何?

            3)Oracle 9i開發(fā)出的程序不一定能在Oracle 8i上使用
            千萬別使用高版本的開發(fā)環(huán)境和低版本的運(yùn)營(yíng)環(huán)境,理想情況是一樣的環(huán)境,不行的話反過來用低版本的開發(fā)環(huán)境和高版本的運(yùn)營(yíng)環(huán)境也可以。切記,產(chǎn)品的成功不在于開發(fā)它的工具是高級(jí)還是低級(jí)。

            由于版本不一致,原先設(shè)計(jì)好的注釋到新的環(huán)境就變成了問號(hào),不堪忍受

            4)外鍵約束使用不當(dāng)導(dǎo)致很多問題
            外鍵約束很大程度上保證了數(shù)據(jù)的完整性,但世界上所有的事情都是一分為二的,在我們開發(fā)過程中,外鍵約束往往約束的是我們而不是數(shù)據(jù),當(dāng)我們需要添加一行測(cè)試數(shù)據(jù)的時(shí)候,當(dāng)我們需要修改一個(gè)字段屬性的時(shí)候,當(dāng)我們需要更新一個(gè)單元格的時(shí)候……到最后,我發(fā)現(xiàn)我們的項(xiàng)目去處了很多外鍵約束,最后的成果和設(shè)計(jì)相去甚遠(yuǎn)了。對(duì)于小型項(xiàng)目,很多時(shí)候沒必要使用外鍵約束,當(dāng)你確定真的需要使用的時(shí)候,仔細(xì)思考,它真的合理嗎?

            5)冗余與效率問題
            總結(jié)過程中我發(fā)現(xiàn)了一些數(shù)據(jù)冗余,這是很正常的,比如一個(gè)用戶表中包括了用戶性別、出生日期和身份證號(hào)碼,其實(shí)這就是冗余,因?yàn)槲覀兺耆梢酝ㄟ^身份證號(hào)碼來確定用戶性別和出生日期,但這種冗余是必要的。一定的冗余能提高我們的效率,我們往往需要在冗余與效率之間選擇一個(gè)平衡點(diǎn)。參考數(shù)據(jù)庫三范式。

            6)命名問題
            表面上看又是一個(gè)沒有技術(shù)含量的小問題,其實(shí)是最令我頭疼的問題之一,一張user表中,出現(xiàn)了多個(gè)“state”,state表示一種狀態(tài),每個(gè)用戶有若干種狀態(tài),很正常,我稍微列一下我能看到的:super_assistant_state、login_state、multi_user_state、forbidden_state、lock_state、score_lock_state……如果和別的表關(guān)聯(lián)起來,恐怕還有更多的state,這些state如果命名得不好,往往容易引起誤會(huì),比如lock_state和forbidden_state,兩個(gè)都表示對(duì)用戶的限制,如果注釋中沒有進(jìn)一步詳細(xì)的說明,誰又會(huì)知道那么多呢?

            7)類型混亂的問題
            字段的類型有時(shí)候看起來確實(shí)混亂,比如什么時(shí)候用integer,什么時(shí)候用number,我想這絕對(duì)不是隨意的,至于number究竟有多長(zhǎng),最長(zhǎng)可以指定多長(zhǎng)?誰研究過呢?integer和C++中32位的int類型有什么異同嗎?而long類型和C++的long是一樣的嗎?字符串到底用char、varchar還是varchar2?我想需要進(jìn)一步研究。

            8)過于復(fù)雜的單句SQL語句
            Oracle的功能是很強(qiáng)大的,幾乎支持所有的SQL風(fēng)格,當(dāng)然包括了復(fù)雜的聯(lián)合查詢和子查詢,但過于龐大的select語句使后來的維護(hù)者感覺非常費(fèi)勁,一個(gè)語句往往需要閱讀很長(zhǎng)時(shí)間,而且根據(jù)我的經(jīng)驗(yàn),調(diào)試時(shí)候出問題多的存儲(chǔ)過程就是包含了這些復(fù)雜SQL語句的存儲(chǔ)過程,我們有辦法將它簡(jiǎn)化嗎?如果不能簡(jiǎn)化,務(wù)必謹(jǐn)慎,測(cè)試測(cè)試再測(cè)試,確保其正確性,然后添加清晰的注釋。

            2、應(yīng)用程序方面

            應(yīng)用程序的問題主要還是集中在版本的控制上,包括消息頭文件的版本,運(yùn)營(yíng)與維護(hù)的不同版本程序,測(cè)試與發(fā)行的不同版本。當(dāng)然還有別的問題,不一定是技術(shù)上的原因了,使得后來做出來的成品和原先設(shè)計(jì)的相差很大,很多設(shè)計(jì)文檔實(shí)際上已經(jīng)廢棄,加大了以后維護(hù)的難度。

            1)common_lib的放置
            common_lib是我們使用的一套公共類庫(與之類似的還有aeslib),主要的功能是網(wǎng)絡(luò)通信、寫log、hash表和隊(duì)列等。幾乎所有的程序都用到了這些功能,不考慮common_lib本身版本上的差距,我們有不同的使用方法,以Linux環(huán)境開發(fā)為例,一種是把common_lib與項(xiàng)目分離,放置在$(HOME)目錄下,而在make文件中也指定了“$(HOME)/common_lib”的搜索路徑;另一種是把common_lib放置在項(xiàng)目目錄中,make文件指定的路徑可能是“../common_lib”。前一種方法有可能把項(xiàng)目從一臺(tái)機(jī)器移動(dòng)到另一臺(tái)機(jī)器(或從一個(gè)賬號(hào)移動(dòng)到另一個(gè)帳號(hào))的時(shí)候發(fā)現(xiàn)common_lib找不到的情況,因?yàn)?#8220;$(HOME)/common_lib”不一定有嘛;后一種方法有可能會(huì)將common_lib所作的一些額外更改忽略掉,它用的還是自己的庫。但考慮到common_lib趨于穩(wěn)定,因此我們盡量使用后一種方法,程序能正確,穩(wěn)定地運(yùn)行就是我們的追求了,最新的代碼并不是必須的。另外,使用common_lib的同時(shí),我們也通常會(huì)用到aeslib,我覺得是不是將它們合并起來更好呢?

            2)程序中的錯(cuò)別字
            這是個(gè)不重要又重要的問題,也許大家都默認(rèn)之后不會(huì)覺得有什么不妥,但站在用戶的角度,會(huì)不會(huì)覺得開發(fā)人員水平很差呢?我列舉一下常見錯(cuò)誤(括號(hào)內(nèi)是正確用法):登陸(登錄)、Acount(Account)、超連接(超鏈接)、Sucess(Success)。

            3)數(shù)據(jù)庫?配置文件?寫死?
            我們可能需要修改一些程序運(yùn)行的參數(shù),比如開分最大金額、心跳時(shí)間、最大連接客戶端數(shù)目……等等。這些參數(shù)的改變究竟如何實(shí)現(xiàn)?我觀察了下程序,普遍有三種情況,一是將參數(shù)存放在數(shù)據(jù)庫中(可以在運(yùn)行中生效),二是寫配置文件(重新啟動(dòng)程序生效),三是寫死在程序中(需要重新編譯程序,再運(yùn)行方生效)。這個(gè)除了看需要外,我還想提些建議:
            1、如果需要網(wǎng)頁方面控制,只能使用數(shù)據(jù)庫了;
            2、只要以后有可能需要修改就不要寫死在程序中,要知道,編譯的環(huán)境不是哪里都有,就算有也不是什么人都會(huì),況且代碼是保密的;
            3、對(duì)于較多的批量配置數(shù)據(jù),盡量使用數(shù)據(jù)庫;
            4、程序初始化的配置數(shù)據(jù)使用配置文件通常更為恰當(dāng),因?yàn)槌跏蓟弥巴鶡o法訪問數(shù)據(jù)庫嘛。
            最后,貪方便把東西都寫死是不負(fù)責(zé)任的表現(xiàn),結(jié)果往往帶來很多不方便。

            4)版本依然混亂
            我經(jīng)常說的一句話是:“XXX,請(qǐng)把YYY的最新版本代碼,給我一份。”或者說:“XXX,你這個(gè)是最新版本嗎?最近一次改了什么內(nèi)容?”其實(shí)老說這句話我都覺得丟臉,做了這么久開發(fā),版本控制問題還是搞不好,不排除制度和開發(fā)模式上也有些問題,但考慮到自己有時(shí)候都不能很好執(zhí)行,就不用怪別人了。通常表現(xiàn)為:
            1、修改隨意,常常忽略修改標(biāo)識(shí),無日期,無內(nèi)容,改錯(cuò)了回頭再尋找困難;
            2、經(jīng)常忘記CVS檢入前先同步一次,導(dǎo)致內(nèi)容混亂;
            3、責(zé)任不明確,程序到底誰在負(fù)責(zé)啊?比如有人離開了公司,他的代碼究竟誰來管?
            4、舊版本經(jīng)常不留備份,修改過程無蹤跡可尋(CVS可能經(jīng)歷很多修改才檢入一次)。

            5)目錄結(jié)構(gòu)安排
            一個(gè)工程,安排怎樣的目錄結(jié)構(gòu)?單個(gè)目錄?或者許多?我想這應(yīng)該不是隨意的,我認(rèn)為通常可以這樣:將公共模塊放置一個(gè)目錄,將類庫(比如數(shù)據(jù)庫操作的類庫,圖形類庫,加密狗類庫)放置各自的目錄,剩下自己編寫的代碼放一個(gè)目錄即可,但如果自己寫的代碼模塊獨(dú)立性強(qiáng),也可以考慮把他們分開,以便以后的復(fù)用。還有就是bin目錄的建立,現(xiàn)在想想還是有必要的,將生成的可執(zhí)行文件放置bin目錄下(VC++自己有debug目錄和release目錄就另外講了),配置文件也放置bin目錄下,發(fā)布時(shí)候只需要發(fā)布bin目錄嘛,我們通常寫log,log目錄呢?我認(rèn)為放置在bin目錄下,這樣發(fā)布的時(shí)候也沒忘記帶上log目錄,當(dāng)然啦,要先將里面的log文件清空。

            6)系統(tǒng)設(shè)計(jì)的問題
            在做概要設(shè)計(jì)的時(shí)候,我們往往有很多不錯(cuò)的想法,比如構(gòu)建一個(gè)比較完美的游戲平臺(tái),以后只需要在平臺(tái)上添加各種不同的游戲即可,這樣就產(chǎn)生了對(duì)應(yīng)的不同數(shù)據(jù)庫,平臺(tái)自身一個(gè)數(shù)據(jù)庫,每個(gè)游戲都有自己的數(shù)據(jù)庫,理論上沒問題,實(shí)際操作起來問題就大了。先是web方面根本沒考慮過這種情況,只設(shè)計(jì)了一個(gè)數(shù)據(jù)庫連接,之后重新添加了新的數(shù)據(jù)庫連接,但可擴(kuò)充性恐怕就不好了,遠(yuǎn)沒達(dá)到我們期預(yù)的效果,再就是控制管理部分程序權(quán)力過大,或者說設(shè)計(jì)不合理,往往逾越了平臺(tái)和具體游戲之間的鴻溝,進(jìn)一步加強(qiáng)了偶合,使平臺(tái)和游戲越發(fā)不可分離,擴(kuò)展性更差,最后做出來的產(chǎn)品已經(jīng)很難把平臺(tái)和游戲區(qū)別開來了,一個(gè)平臺(tái)就是一個(gè)游戲,一個(gè)游戲包括一個(gè)平臺(tái)。

            7)考慮上的疏漏
            舉個(gè)例子吧,我們?cè)趯?shí)際操作中需要?jiǎng)?chuàng)建新的服務(wù)器,但發(fā)現(xiàn)不成功,查原因,發(fā)現(xiàn)是因?yàn)閿?shù)據(jù)庫里需要添加新的服務(wù)器的條目才可以,添加條目是web的功能,結(jié)果發(fā)現(xiàn)web沒做好,等web補(bǔ)上了,條目添加了,發(fā)現(xiàn)還是不行,因?yàn)榉?wù)器的運(yùn)行需要數(shù)據(jù)庫的很多信息參數(shù),而這些參數(shù)目前都沒有在添加條目的時(shí)候被添加,由于這次web的工作量較大,一時(shí)改不好,只能手動(dòng)在數(shù)據(jù)庫里添加,一張表添加的條目可能有數(shù)十條,相當(dāng)繁瑣,稍微不留神就可能出錯(cuò)。考慮上的疏漏可能會(huì)伴隨我們一生,但每一點(diǎn)一滴都是寶貴的經(jīng)驗(yàn),起碼我們不能再犯同樣的錯(cuò)誤。

            8)log文件處理
            程序離不開log,按照我們的做法,每天產(chǎn)生一個(gè)log文件,時(shí)間一長(zhǎng),log文件就越來越多,占用空間越來越大,我想我們應(yīng)該改進(jìn)一下,比如每天自動(dòng)刪除3個(gè)月以前的log。

            一天加一天,log泛濫成災(zāi):)

            9)exit的使用
            程序碰到異常情況我們通常喜歡用exit()來結(jié)束程序的運(yùn)行,在單線程中這樣做是沒問題的,但到了多線程則未必,根據(jù)我的經(jīng)驗(yàn),濫用exit()很容易導(dǎo)致程序結(jié)束的時(shí)候出現(xiàn)“非法操作”,甚至數(shù)據(jù)庫寫入不完整。下面是我認(rèn)為的以后的做法(不一定很正確):只有主線程能調(diào)用exit(),其它線程運(yùn)行遇到致命錯(cuò)誤后返回錯(cuò)誤值,一層層往上返回,直至主線程,(或者將致命錯(cuò)誤消息發(fā)至主線程)由主線程調(diào)用exit()。當(dāng)然主線程也可以完全不用exit(),我更偏向于能不用就不用,因?yàn)閑xit()會(huì)不分黑紅皂白強(qiáng)制結(jié)束程序,它不能讓對(duì)象正常釋構(gòu),另外它有類似goto語句,破壞程序的結(jié)構(gòu)化,使程序條理變得不清晰。

            10)多線程中MsgBox的問題
            測(cè)試/維護(hù)過程中發(fā)現(xiàn)過一些很奇怪的現(xiàn)象,程序莫名其妙地到了其它電腦就出現(xiàn)“非法操作”,后究其原因發(fā)現(xiàn)是使用MsgBox(這里通指消息框)的問題,該調(diào)用會(huì)彈出對(duì)話框請(qǐng)求用戶確定取消等,或者僅僅將一些消息反映給用戶。在多線程中使用MsgBox我認(rèn)為存在隱患,一方面是開發(fā)工具的問題,MsgBox在C++ Builder中的實(shí)現(xiàn)和WINAPI的MessageBox是不一樣的;另一方面MsgBox并不能每時(shí)每刻都能工作得很好,我就發(fā)現(xiàn)過多線程程序中C++ Builder的MsgBox不起作用的情況;再一方面MsgBox會(huì)對(duì)線程造成堵塞,如果讓邏輯處理線程直接調(diào)用MsgBox則可能導(dǎo)致一些沒有預(yù)料到的情況發(fā)生。我認(rèn)為,MsgBox和用戶界面相關(guān),盡量只在主線程中調(diào)用。

            這種MsgBox恐怕難以令人接受

            3、文檔方面

            這里指的文檔包括了各種設(shè)計(jì)文檔、配置文件、說明書及程序注釋,是程序可維護(hù)性的重要依據(jù),但往往容易被忽略,它不能影響程序的性能,但我覺得從現(xiàn)在的角度來說,一個(gè)程序的可維護(hù)性往往比性能更重要。

            1)配置文件的問題
            到底把配置文件放入CVS呢還是不放呢?都各有道理,放的話檢出中有這個(gè)文件,用戶知道去修改,但如果一個(gè)用戶修改了配置文件并檢入,然后另一個(gè)用戶更新,那另一個(gè)用戶的配置文件也跟著被改動(dòng)了,可能導(dǎo)致錯(cuò)誤;如果不放,那用戶第一次檢出時(shí)候沒有這個(gè)配置文件,無法運(yùn)行程序,但獲得這個(gè)文件后不會(huì)因?yàn)橹蟮母露鴮?dǎo)致文件被修改。我看還是不放的好,不經(jīng)意地被改動(dòng)配置文件是件很郁悶的事情,寧愿找不到配置文件自己另外去找一個(gè)。但有沒有其它更完美的辦法?

            2)安裝配置說明的問題
            我第一次把我認(rèn)為不錯(cuò)的安裝說明交給測(cè)試部讓他們?nèi)?zhí)行的時(shí)候,我說:“盡量參照說明,不要問我,看看是否能按部就班完成。”結(jié)果是很令人沮喪的,一天跑來問我許多次,因?yàn)閷?shí)在不知道下一步怎么弄,或是出了些意外。當(dāng)然不排除是因?yàn)長(zhǎng)inux易用性差的緣故,但無論怎么說,我的說明文檔也十分糟糕,我一直在想怎么才能寫出合格的說明文檔呢?我想應(yīng)該寫好之后,把自己當(dāng)成一個(gè)用戶,嘗試按說明去操作一遍,這是最起碼的了。當(dāng)然要寫得好,真不亞于程序設(shè)計(jì)的難度,你考慮過意外出錯(cuò)嗎?還有各種你看起來平常的術(shù)語用戶是否就清楚?仔細(xì)仔細(xì)再仔細(xì),難道說明真的很完美,沒有任何錯(cuò)誤了嗎?我沒有進(jìn)一步的解決,只有苦功,在此提一下這其實(shí)并不簡(jiǎn)單,僅此而已。

            3)說明書的問題
            先參考一下上面所說的安裝配置說明的問題,是否存在,還有就是以下的一些問題了:1、格式不統(tǒng)一,章節(jié)不對(duì)齊;2、圖片過大,調(diào)整后模糊,影響閱讀;3、內(nèi)容混亂,針對(duì)性不強(qiáng),到底是一個(gè)針對(duì)網(wǎng)絡(luò)管理員的說明書,還是針對(duì)一個(gè)普通用戶的說明書?我想內(nèi)容肯定相差很大。

            posted on 2009-09-29 14:19 Jiang Guogang 閱讀(656) 評(píng)論(1)  編輯 收藏 引用 所屬分類: Thinking/Other

            評(píng)論

            # re: 【CSDN】軟件開發(fā)中遇到的一些問題 2009-09-29 15:29 func
            用SVN不會(huì)有這類問題吧。BCB有好幾個(gè)不同實(shí)現(xiàn)的MsgBox。  回復(fù)  更多評(píng)論
              

            91麻豆国产精品91久久久| 99久久精品免费| 中文字幕亚洲综合久久菠萝蜜 | 精品久久久久久国产| 99久久99久久精品国产| 精品久久久久久中文字幕| 亚洲成色WWW久久网站| 精品久久久无码人妻中文字幕| 久久亚洲精品无码播放| 久久久精品波多野结衣| 久久精品成人免费国产片小草| 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲高清不卡 国产成人精品久久亚洲 | 久久久久久久综合日本| 精品国产乱码久久久久久浪潮 | 国产精品美女久久久久av爽 | 国产99久久久久久免费看| 国产日韩欧美久久| 日本精品一区二区久久久| 久久中文字幕人妻熟av女| 久久综合88熟人妻| 久久se精品一区二区| 久久综合视频网站| 无码久久精品国产亚洲Av影片| 亚洲精品乱码久久久久久蜜桃不卡| 久久久久久久亚洲Av无码| 麻豆精品久久精品色综合| 人人狠狠综合久久亚洲| 性色欲网站人妻丰满中文久久不卡| 国产成人久久精品激情| 亚洲国产成人久久一区WWW| 久久棈精品久久久久久噜噜| 女人香蕉久久**毛片精品| 久久综合亚洲鲁鲁五月天| 九九99精品久久久久久| 久久天天躁狠狠躁夜夜不卡| 久久狠狠色狠狠色综合| 久久99这里只有精品国产| 久久―日本道色综合久久| 久久伊人精品一区二区三区| 91久久精品国产91性色也| 亚洲女久久久噜噜噜熟女|