• <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>

            meet-dream

            應用軟件和平臺軟件的一點思考

            ??????程序是對數據流的處理,從這個角度來說,算法是程序的靈魂,特別是在搜索,語音識別等領域。但隨著程序規模越寫越大,我們發現我們的程序越來越難維護,于是出現了改進的編程語言,設計模式,軟件工程等從技術和管理角度改進的方案。我們照做了,如果做的好,我們看會到我們的程序越來越健壯,程序幾乎不需要增加更多的成本就可以一份一份的拷貝賣給更多的客戶,于是一幅美好的藍圖展現在我們面前。當然這只是一個假設,實際實施過程中因為各種各樣的原因,甚至無法將過程完成。 一個針對特定需求開發的應用軟件開發完成后,很多情況下確實能滿足絕大多數客戶的需求。根據80-20原則,我們可以根據實際情況考慮是否一定要剩下20%的客戶,畢竟我們要的是實現利益最大化。
            ??????然而,在我這幾年在平臺項目的開發過程中,我發現,平臺軟件和應用軟件有很大的不同。首先,平臺軟件是針對特定領域而不是針對特定應用開發的,這就決定了你開發的軟件不能是一套單純的軟件,而是一些軟件開發的基礎設施,有了這些設施,我們可以方便的開發出這一領域,甚至交叉領域的應用軟件,這要求你的基礎設施要是細粒度的,相對通用的。為了開發方便,在開發接口上,要很好的體現出對象邏輯結構,層次結構。其次,平臺軟件是應用模糊的,同樣的一個輸入,根據應用的不同,產生的輸出是迥異的,這是我們無法完全預測的。你的東西要是可以訂制的,可靈活配置的,對于一個固定輸入輸出的東西還能叫一個平臺嗎。配置太麻煩也不行,不能動輒要求開發人員來訂制。不能要求二次開發人員對你的東西要有深的了解,他只關心的是自己業務。比較好的做法是只有必要的時候才打開一個缺口。在STL中,我們就能獲得很多啟示,每個concept,iterator,container,algorithm,沒有那個東西是死的,雖然是很簡單的幾個東西,組織起來的威力讓人嘆為觀止.而在其中可以加入自己的東西卻又能很好的融合.?
            ?????????從這兩個角度來說,平臺軟件的團隊里必須有精通該領域的人,在他的眼里,只要是該領域的需求(當然是理論上可以解決的問題),都能迅速轉化為一個可實施的模型.他胸中有"大略",所以能進行高層的抽象,作的東西才有普適性.同時,東西要轉化成解決方案,靠的卻是開發人員.開發人員能理解模型的深層意思嗎,我看很多情況下未必;即便開發人員理解了,他能把它轉化成良好的軟硬件模型嗎?同樣是困難重重!根據我這幾年的看到的東西,我認為我們沒有那個環節做好了,可能這也是國內的大氣候,大家都很浮躁,沒有人從深層次思考這些問題,因為大家都在向"前"看.雖然實際可能就看見前面三尺.?
            ?????????那些自以為很強的人或公司,其實未必有能力實現自己的目標,很多情況下是高估了自己的實力(包括技術水平,企業文化,創超力等)。雖然能做好很多項目,但在開始平臺開發項目之前一定要三思而行。

            posted on 2007-05-28 13:54 meet-dream 閱讀(1206) 評論(4)  編輯 收藏 引用 所屬分類: software develop

            評論

            # re: 應用軟件和平臺軟件的一點思考 2007-05-28 22:05 璞石

            說的不錯,確實是這樣,平臺需要的是通用性,要能為各種應用提供靈活的接口,并且最大程度的抽象各種邏輯。  回復  更多評論   

            # re: 應用軟件和平臺軟件的一點思考 2007-05-29 09:33 zenith

            贊同!  回復  更多評論   

            # re: 應用軟件和平臺軟件的一點思考[未登錄] 2007-05-29 11:26 longshanks

            stl的核心,也就是平臺軟件的核心,就是“可擴展”。
            平臺軟件通常很難遍歷所有的需求,于是抽象出業務模型框架就顯得尤為重要。一旦抽象出業務框架,則可以通過插入和替換組件的方式實現擴展,將軟件定制的開發量減到最小。  回復  更多評論   

            # re: 應用軟件和平臺軟件的一點思考 2007-05-29 16:27 meet-dream

            re:longshanks 這個和微軟的微內核的思想應該是一致的,但這樣以來二次開發就可能需要跨越層次才能實現,這樣其實是簡化了大部分二次開發用戶的任務,但同時也在一定程度上給另外一部分作底層開發的人帶來了工作量,這也許就是事物的對立與統一的關系吧  回復  更多評論   

            亚洲精品乱码久久久久久蜜桃不卡 | 久久777国产线看观看精品| 人妻少妇久久中文字幕一区二区 | 久久91精品久久91综合| 久久99国产精一区二区三区 | 久久中文字幕精品| 伊人久久大香线蕉综合影院首页| 99精品国产99久久久久久97| 色综合久久久久综合体桃花网 | 99久久综合国产精品二区| 亚洲国产高清精品线久久 | 国产99久久久国产精品~~牛| 91精品免费久久久久久久久| 亚洲伊人久久成综合人影院| 久久国产乱子伦免费精品| 久久无码国产| MM131亚洲国产美女久久| 欧美大战日韩91综合一区婷婷久久青草 | 亚洲熟妇无码另类久久久| 91麻精品国产91久久久久| 久久www免费人成看片| 94久久国产乱子伦精品免费| 免费久久人人爽人人爽av| 国产精品无码久久综合网| 亚洲va久久久噜噜噜久久男同 | 久久午夜综合久久| 久久99国产精品久久99果冻传媒 | 99久久精品日本一区二区免费| 狠狠精品干练久久久无码中文字幕| 精品国产青草久久久久福利| 久久久久亚洲精品无码网址| 久久精品国产99国产精品澳门| 一本色道久久综合狠狠躁| 久久久亚洲精品蜜桃臀| 久久国产成人精品麻豆| 亚洲AV乱码久久精品蜜桃| 伊人色综合久久天天网| 手机看片久久高清国产日韩 | 国产99久久久国产精品~~牛 | 香港aa三级久久三级老师2021国产三级精品三级在 | 日批日出水久久亚洲精品tv|