我國的軟件開發已經逐步從原來的手工作坊式發展到了軟件工程的階段。同時，軟件開發本身也在不斷髮展，已從“算法＋數據結構＝程序”逐步發展到了“設計模式＋對象組件＋開發工具＝程序”。開發工具的選擇，已經成爲軟件開發成功的要素之一。
開發工具的選擇主要決定於兩個因素：所開發系統的最終用戶和開發人員。最終用戶需求是一切軟件的來源和歸宿，也是影響開發工具的決定性因素；開發人員的愛好、習慣、
經驗也影響着開發工具的選擇。嚴格的軟件工程管理和開發人員的技術水平是軟件開發成功的關鍵。
本文介紹一些選擇軟件開發工具的思路，重點強調在滿足客戶羣體的情況下，軟件工具服務於軟件工程思想的重要性。
開發工具 爭顯鋒芒
首先需要強調的是：開發工具的比較沒有絕對的標準。評價一種開發工具，不僅要看它對設計模式、對象結構以及管理的支撐情況，更重要的是要針對具體的使用環境、開發方法、結構體系、開發羣體以及使用羣體來評價一種工具的適宜程度。
現有的開發工具大概分爲大而全和小而專兩種類型。Microsoft的Visual Studio系列和IBM的Visual Age系列應該屬於前者；其他很多工具，像Delphi/C++Builder/JBuilder/Kylix、PowerBuilder/PowerJ，還有大量的各種SDK等都具有各自的特點，屬於小而專的類型。
大而全的工具一般都提供從前端到後臺，從設計到編碼測試的完整工具，但在一些特定的功能上，它們不如小而專的工具。
Visual Studio.NET的UML開發工具(Visual Modeler/Visio)一般只能和Rational Suite中Rational Rose的Logical View相比，它不可能有完整的Rational Unified Process流程；其可視化的Visual Basic沒有辦法和Delphi/C++Builder在速度和功能上相比。
雖然Visual Studio.NET的各個部分都有不足，但其Visio工具能夠更快、更方便地和編程語言整合在一起。Visual Basic在和Office等工具整合時遇到的問題(數據類型轉化等)比Delphi/C++Builder要少得多。所以，工具類型和具體的情況決定了特定條件下軟件開發工具最優的選擇。
欲善其事 先利其器
開發工具的選擇主要決定於兩個因素：所開發系統的最終用戶和開發人員。最終用戶需求是一切軟件的來源和歸宿，也是影響開發工具的決定性因素；開發人員的愛好、習慣、經驗也影響着開發工具的選擇。
最終用戶的需求
程序的最終使用羣體是軟件開發的服務對象，也影響着開發工具的選擇。從計算機使用的程度分，最終的使用者可以分爲IT人員、各行業的專業人員以及普通用戶。使用者的不同，對於軟件的需求就不會相同。IT人員自然需要更多的功能、更自由的定製/二次開發空間；行業用戶往往需要一個整體的解決方案，從而提升其整體競爭力；普通用戶顯然要求更方便簡單地使用。用戶的需求分別在自由度、涵蓋度、針對性、方便性等維度展開。
擴展軟件自由度
爲了擴展軟件的自由度，較少的封裝和充分的功能暴露是必然的。爲了讓用戶自由使用Windows的功能，自由訪問操作系統和硬件資源的語言C++或者Assembler應該是最好的選擇。Visual C++成爲Microsoft對其操作系統功能的“權威”封裝，至今在Windows系統級開發中佔據主流地位；C++ Builder擴充的標準的C++語法，提供了RAD(Rapid Application Development)的支持，但是它的VCL(Visual Component Library)大部分是用Delphi寫的，不像Visual C++的MFC/ATL類庫的純C++源代碼，對於C++程序員的深入編程不利。最近開放源代碼(Open Source)運動風靡全球，開放源代碼的C++工具中，GCC受到了普遍的採用。它不僅可以在各種流行操作系統(Windows、Linux、Solaris、HP-Unix)上運行，而且支持Object C、C++的各種擴充語法，甚至可以編譯Java代碼。
涵蓋度各取所求
關於涵蓋度的要求，不同的系統也是不盡相同的：有的可能要求涵蓋前端、中間件、後臺、數據庫，也有可能要求涵蓋各種操作系統和硬件平臺。Visual Studio .NET和IBM的電子商務平臺都能夠提供從客戶端、中間件到數據庫的整體開發支持。
Visual Studio.NET甚至將可視化帶到了Web客戶端，通過拖放完成Web頁面以後，可以雙點到後臺處理程序的框架代碼中。從軟件工程的思想看來，Visual Studio.NET給程序員提供了強大而且方便的功能，但是並沒有明確的支持需求分析的流程。IBM的Visual Age系列在這個方面做得不錯，Visual Age UML Designer支持從需求分析到設計、編碼的相對完整過程(不過，在代碼生成方面僅僅對Java和Smalltalk的支持比較好)。
Visual Studio.NET採用COM+作爲組件模型，其生成的Web客戶端對於平臺沒有限制。不過，雖然.NET框架應該可以移植到非Windows平臺上運行，但是其中間件和服務端還沒有看到在Unix或者Mac OS上的成功案例。IBM VisualAge+WebSphere+DB2系列大量採用JavaBEAn/J2EE作爲組件模型，由於Java的平臺無關性，客戶端和中間件的跨平臺性就比較好。
當然，用小而專的工具組合起來也能完成這些工作，Rational Suite可以完成從業務建模、系統建模、模塊建模以及發佈測試的完整過程，Delphi/C++Builder可以利用CORBA或者COM+作爲中間件，JBuilder 6更是可以採用Visibroker或者orbix等各種CORBA產品或者WebSphere、iPlanet、BAS、WebLogic等各種J2EE產品。但是，如果不明白Rational中UML和代碼映射的方法以及C++Builder/Delphi/ JBuilder對於代碼的管理方式，要讓建模和編碼配合起來，就需要在Rational Rose中設置ClassPath以及在Borland工具中設置源代碼目錄。其中的過程和可能出現的問題都很多，而在Visual Studio.NET中，這些工作僅僅是點幾下鼠標的事情。
也有像Ensemble這樣的公司，專門集成小而專的工具，但是這些軟件的成熟度以及學習和掌握也是問題。當然，在局部涵蓋性上，Delphi使用CLX的程序可以在Kylix上編譯，從而在Linux上運行；Raining Data Corporation的Omnis Studio 3.1甚至直接支持跨越Windows和Linux平臺的RAD開發。
針對性各有特色
在針對性上，各個工具都具備各自的優勢。在單機應用上，Visual FoxPro具有全球最快的數據訪問引擎。而PowerBuilder在開發兩層數據庫應用上，特別是用數據窗口和Sybase數據庫後臺掛接，用PowerDesign建模，不僅開發速度快，而且效率和穩定性也比較好。在三層應用上，使用Visual Basic/C++/C#+ADO，如果再使用SQL Server，就在性能、開發效率、穩定性上都有保證；而使用C++Builder/Delphi+DataSnap(MIDAS)，在掛接非微軟數據庫，或者需要和CORBA程序交互時都具有優勢。
對於多層分佈式應用，COM+規範和CORBA產品(orbix, visibroker等)往往決定了開發工具的選擇。COM+的開發工具一般採用Visual Studio.NET或Borland的產品，而由於CORBA的編程語言和系統平臺的無關性，各種開發平臺一般都可以。另外，針對C/C++編程，DSET公司的DSG在高端應用(一般在電信領域)中，它在與網絡協議棧的無關性、同/異步消息處理、海量通信能力、嵌入式到大型機的移植性等方面,具有獨特的優勢。在服務器端開發上，COM+、CORBA 3.0、J2EE都支持組件模型，分別利用MSMQ、CORBA Messaging System、JMS完成異步通信。COM+仍然主要集中在Windows平臺上，CORBA 3.0的Java語言部分包含整個J2EE規範。但是，CORBA作爲一個跨語言跨平臺的規範，現在支持3.0版本非Java語言的產品還不多，支持其核心——CCM(CORBA Component Model)的C++編程的產品有iCMG公司K2-CCM等。
J2EE的組件(EJB)已經發展到了1.2版本。滿足該規範的產品——BEA WebLogic、Borland BAS、 IBM WebSphere、Oracle 9i甚至免費的JBOSS都得到了廣泛的應用。BEA WebLogic 7.0在前端開發工具上做了大量的工作，聲稱將J2EE開發和Visual Basic放在同一個級別上(其內部名字就是Visual Basic for Java)。
微軟方便性最好
在方便性上，由於有大量用戶的實踐，微軟的開發工具應該是最好的。它在可視化、工具間互操作性、穩定性、文檔的豐富性上都具有明顯的優勢。Borland Delphi/C++Builder在可視化上和Visual Basic/C#基本上類似，但是他們在穩定性上不足(C++Builder 5.0自動生成的CORBA程序的debug版會報錯(Exception))；IBM Visual Age系列的穩定性不錯，但是它們的可視化編程不是非常方便；在文檔方面，更是沒有一種工具具有Visual Studio自帶的MSDN那樣的容量(兩張光盤)。
開發者的偏愛
開發工具是給開發者用的，開發人員是這些工具的用戶。不同的開發人員對工具的偏愛也不同。Pascal程序員一般都會鍾愛Delphi/Kylix；Windows的C++程序員則會選擇C++Builder或者Visual C++；在不同平臺下C++編程的人員可能會更加喜歡GCC；Smalltalk程序員恐怕就只會考慮Visual Age Smalltalk；而Turbo Lisp、Visual Fortran、Perl Builder等開發工具在其他各種編程語言的程序員中也被大量採用。
現在，各種編程語言的功能互相融合，像Borland Delphi和C++Builder之間的功能差異，在語言上表現得已經非常少了。除了編程語言的偏愛以外，不同操作系統的程序員使用的工具也不同：Solaris系統下的程序員更多地使用CC編寫C++/C的後臺程序，用Perl編寫框架或者測試腳本，用TCL/TK編寫界面程序；雖然Windows下也有這些工具，但是更多程序員恐怕還是會選擇支持RAD的工具。現在，人們普遍認可一種趨勢：操作系統、編程語言在開發上的差異正在迅速消失。XML有效地解決了在不同系統下統一數據表達的問題；通過虛擬機，Java程序能夠在不同操作系統下執行；微軟的.NET框架能夠利用C++/Basic/C#來編程。
平臺和語言間的交互使得各種工具對於通用標準的支持越來越重視。Sun新推出的Java的XML開發包，明確支持由微軟和IBM提出的SOAP規範，Visual Studio.NET也明確支持Java語言(J#)。雖然現在還僅僅是一個開端，但是，語言和平臺的融合是一種不可阻擋的趨勢：必然有更多的編譯器將其他語言編譯成爲Java字節碼，Visual Studio.NET也必然會將程序編譯到其他操作系統中。
然而，伴隨着技術的融合，差異性也將永遠存在。微軟爲了互聯網應用而推出.NET框架，Windows和Visual Studio都做了巨大的改進。爲了這個框架，Visual Studio.NET甚至推出了一個新的編程語言C#，它具有Java語言的大部分特徵，同時在固定內存區允許使用指針。C#在設計上確實非常先進，但是由於缺乏大量的使用，而且缺乏Java 2中的安全特性，是否能夠吸引大量的程序員，還是一個未知數；同時，C#中的很多特性(像對象方法的修飾詞等)都是微軟COM+規範在編程語言中的映射，這會在今後的操作系統平臺移植時產生麻煩。
除了開發人員的平臺特性和語言偏愛以外，人員間的配合模式也決定着工具的選擇。自由軟件普遍採用的跨地域開發模式，對於使用CVS版本管理系統的開發工具非常合適。而由於Visual Studio.NET在開發調試中會改變本地Windows註冊庫，跨地域開發就非常不方便。
當然，不能排除別的因素對於開發工具的影響。舉例來說，行業的特點以及遺留系統(legacy system)對於開發的影響也是不可忽略的：電信行業的軟件開發，由於有ITU-T規範的存在，Java要代替現有的C/C＋＋開發模式還不能像通用軟件那麼快。但是，歸結起來，軟件的開發總是一個由人完成和爲人服務的。無論其他因素的影響力現在有多大，今後的發展也必然是由人來決定的。
開發利器1 PB集成 降本提效
互聯網已經從前幾年的“接入爲王”、“內容爲王”，發展到了今天的“應用爲王”的時代了。大批的應用軟件開發人員也將進入Web應用開發領域。他們熟悉應用業務領域、熟悉傳統C/S的開發技巧，但不一定熟悉HTML/JavaScript, 也不一定熟悉3-tier體系架構。這對平臺和工具廠商來說是一個巨大的商機。
PB異軍突起
現在究竟是什麼阻礙了Web應用和3-tier的大批出現呢？仍然是工具。一個好的開發工具應該是在日常開發中能夠屏蔽煩瑣的技術細節，並允許高級開發人員直接干預這些技術細節。在3-tier開發中，我們會同時面對數據庫操作(表、數據維護、存儲過程和觸發器的維護等)，Component編寫和調試, 網頁(尤其是調用這些Component的動態頁面)的編寫和調試，以及一些2-tier應用程序的維護等許多任務。
一般說來，完成這些任務需要使用多種工具，在開發時需要在多個工具之間切換，由此造成了開發效率的低下和開發難度的提高。而PB8/PJ4很好地解決了這些問題。所有這些任務，都可以在同一個開發環境中完成，開發人員能非常快速地編寫基於數據庫的業務邏輯Component以及調用這些Component的Web-Client或PB-Client。尤其是Sybase把2-tier中的王牌Datawindow擴展到了HTML領域，使得數據庫驅動的動態頁面實現起來非常容易。
總體來說，Sybase的優勢在於具備開發企業信息系統所需的全系列的工具，包括系統分析和系統設計工具PowerDesigner、應用開發工具PowerBuilder和PowerJ、應用服務器EAServer(內含Jaguar和PowerDynamo)、數據庫Adaptive Server Enterprise(以及複製服務器等)。這些工具由於是同一家公司的產品，具有非常好的互操作性。同時，這些工具對標準的支持非常好，比如EAServer對組件模型就同時支持COM、CORBA和J2EE，可以用C/C++和JAVA來編寫各種Component, 甚至以CORBA的形式支持用PowerBuilder直接編寫Component。
反面意見
許多人都提到PB的許多不足，比如與VB和Delphi相比界面較單調、對於Windows API的調用能力較差(PB本身不直接支持指針)等等。然而，在某些特定場合，這些問題會變成優勢。企業應用的核心在於數據訪問和業務邏輯。界面的花哨倒並不重要。在企業應用中，好的用戶界面設計是指符合用戶業務思維方式和業務流程的界面設計，而不是花哨的界面設計。而不支持指針，則會大大提高程序的可靠性。這些問題，實際上都源自PB產品的定位：不是作爲一個通用開發工具，而是作爲一個專用的企業信息系統開發工具。在這個領域，PB/PoerJ確實是無可匹敵的。
在系統分析和設計工具領域，Rational Rose是一個常被人稱道的工具。然而在現實的信息系統項目和應用軟件開發中，我們面對的不是純面向對象的環境，而是關係數據庫和麪向對象的混合環境。並且，用戶無一例外地希望數據庫的訪問有儘可能高的性能。 第三方工具
在互聯網上您可以找到大量第三方的工具來幫助您提高您在開發PowerBuilder應用時的效率和質量。下面就是兩個例子：
大家一定會了解Visual C/C++與MFC的關係。在C/S環境中，PowerBuilder也有一個PFC與之對應。當然，兩者的層次是不同的。MFC提供了底層的封裝，而PFC提供了數據庫應用的更高層面的封裝。對PFC的深入應用可以大大提高系統的開發效率和開發質量。進入到3-tier的世界，如果用PB來開發Component，同樣也有一些很好的類庫，比較著名的就是EAF。對這些類庫的深入應用並形成自己的類庫，是迅速提高產品和項目的質量和效率捷徑。
確保應用軟件的質量一定是許多人都很頭疼的問題。那我們就先來看看最基本的問題吧。在單元測試這個領域，大家一定了解在Java中的JUnit這個單元測試工具。PB中也有一個對應的工具叫做PBUnit。你可以在開發過程中，在PBUnit環境中編寫測試腳本，反覆對你的Object進行迴歸測試，並自動記錄、分析測試結果。對於常常是包含了大量數據處理的PB應用程序來說，這是非常有價值的。(祝楓)
開發利器2 WebSphere Studio 開放開發
IBM正在交付一個基於WebSphere Studio Workbench技術的電子商務應用程序開發工具的新套件。WebSphere Studio Workbench是一個用於工具開發和集成的平臺。這是 IBM 對開放源碼Eclipse Project的增值實現。WebSphere Studio Workbench提供用於開發源代碼編輯器和其它用戶界面的一組API、模型和框架，以及對資源管理的公共服務、調試和團隊編程的訪問。該平臺實現了現有標準並提供用於將功能部件和函數作爲插件添加的擴展點。IBM 和獨立軟件供應商(ISV)正在開發插入這個框架的工具。
WebSphere Studio Site Developer和WebSphere Studio Application Developer是IBM合併和擴展WebSphere Studio Workbench而成的兩個產品。這些產品是計劃中將要跨越所有電子商務開發角色的集成開發工具套件的一部分，從Web開發者到Java開發者、到商務分析師、到設計師、到企業程序員。WebSphere Studio開發工具系列將添加更多產品。
客戶希望有開放標準、工具集成、更大的靈活性和結合到現有應用程序的能力。這些還只是WebSphere Studio產品套件所交付的部分優點。
垂直和水平集成
傳統上，軟件供應商提供垂直工具，迫使客戶自己做集成。WebSphere Studio Workbench的目的是提供一個 IBM 和 ISV 都能容易地擴展的平臺。供應商已經擁有了該技術並在此基礎上積極地構建工具。
在Workbench上構建的每個WebSphere Studio產品都將提供已集成的工具，使您可以專注於構建應用程序而不必費力去集成工具。
開放標準
WebSphere Studio套件中的所有產品都是構建在開放標準上的，並且它們所生成的代碼也是與開放標準一致的。可以構建和部署滿足Servlets 2.2、JavaServer Pages(JSP)1.1和 Enterprise JavaBEAns(EJB)1.1規範的最新型的(state-of-the-art)服務器端應用程序(在Site Developer產品中將不包含EJB開發工具。)所有構建在WebSphere Studio Workbench上的產品，都包含CVS(Concurrent Versions System)。
基於角色的開發
WebSphere Studio產品系列中的每個成員都是爲特殊電子商務開發角色或某種角色範圍設計的。例如，Site Developer是爲開發和管理整個網站的Web開發者設計的。Application Developer包含Site Developer的所有功能並添加了對在業務邏輯方面(包含 EJB)工作的程序員的支持。當IBM交付WebSphere Studio系列的未來成員時，它將擴展其選項範圍，將產品與用戶的角色和需求相匹配。
在每個WebSphere Studio解決方案內部，面向任務的視圖篩選出複雜性並只提供與手邊的任務相關的功能。用戶根據此時正在開發或分析什麼，或者根據他們在項目中的角色切換視圖。因爲不同的開發者以不同的方法工作，所以視圖可以定製。因爲他們使用WebSphere Studio Workbench技術構建，所以所有工具和視圖共享一個公共外觀，這減小了學習難度並使得用戶的生產力最大化。並且，因爲項目的開發資源存儲在單個資源庫中，所以您獲得了對項目的最大共享性和一致團隊支持。
最大編程性能
除了將應用程序開發者們從工具集成任務中解放出來以外，Site Developer和Application Developer 都以許多方法優化了程序員的生產力。(蘇永)
開發利器3 微軟.NET和C#
微軟現在把自己的希望寄託在新的.NET應用程序框架之上。雖然在.NET中幾乎可以使用任何一種編程語言，但是開發者更熱衷的還是微軟的C#和C++。因爲它們改變了幾乎所有從桌面軟件到具有Web功能的企業解決方案的Windows開發規則,所以這些技術的潛力非常巨大。
.NET框架和C#擴展了Windows的功能，C#和Visual Studio .NET的結合使得創建和配置Web服務幾乎可以自動進行。並且，和傳統的ASP應用程序相比，ASP.NET應用程在性能、穩定性以及可擴展性方面都有了實質性的提高。
雖然有很多優點，但是.NET價格不菲。目前的Windows開發者如果要轉向.NET框架，都必須進行再培訓，並且所需費用很高。由於.NET框架中有很多重大的改變以及複雜度的提高，因而現在的VB程序員將無法應對這些變化。C++程序員則會因爲C#繼承了自己熟悉語言中的基本內容而感到高興，但是他們也會發現在API以及語言方面C#還是有很大的改變。
在ASP.NET中，由於不再使用VBScript，而只用JScript，並且在系統服務中也不再提倡使用COM(Component Object Model)，因此要把現有的Web應用程序轉換成ASP.NET，重新編寫程序代碼要耗費大量的時間和精力。如果要把現有Java項目轉入到.NET框架中，即使你使用的是J#(微軟的Java開發語言)，那麼要完成一個項目的遷移，至少也要花費幾個月的時間。如果要把服務器從Unix平臺遷移到Windows,那麼更是要求所有的IT職員都必須掌握一門新的技術。
考慮到以上因素，我們就很容易理解爲什麼.NET和C#會讓人們既關注又擔憂。當然，對於已經在從事Windows平臺下開發的公司和企業來說，不是接不接受.NET的問題，而是什麼時候接受的問題。目前普遍的觀點認爲，如果不及時實現向.NET的遷移，那麼將最終不堪忍受來自開發者、商業夥伴、應用程序提供商以及工具提供商的壓力。 當然，相對於來自Java、Unix和Linux擁護者的挑戰來說，微軟要把Windows下的開發者吸引到.NET框架上來。在和Java和J2EE的競爭中，微軟主要有兩張牌可打，即Visual Studio .NET和Web服務。測試版的Visual Studio .NET IDE(整合開發環境)已經在開發人員中引起了不小的震動。相信在Web服務領域和Java競爭時，它將成爲微軟的一把利器。(伊利貴)
開發利器4 鍾情Delphi 6
Delphi 6 是當前 Windows 平臺上全面支持最新 Web 服務的快速開發工具。無論是企業級用戶還是個人開發者，都能夠利用Delphi 6 輕鬆、快捷地構建新一代電子商務應用。Delphi 6優秀在何處？
高效的開發
Delphi 6是一個RAD(Rapid Application Development 快速開發工具)。它有可視化的開發環境，當然具有類似功能的開發工具也不少(如Visual Basic)，但Delphi 6有如下的獨到之處：
Delphi 6是真正面向對象的。其構建的VCL庫中的所有組件都可以被繼承以創建新的組件，包括窗體類TForm。相比之下，ActiveX組件缺乏這種靈活性。
Delphi 6的CodeInsight技術(即代碼自動完成功能)是建立在編譯器信息上的，而VB使用的是類型庫信息，使用編譯器信息的好處是更具靈活性。不過，時常有程序員抱怨Delphi 6的代碼提示時間太長。
高效的編譯
可以說，Delphi 6是Windows平臺上最快的高級語言本地代碼編譯器了。編譯速度快有什麼好處呢？快速的編譯器可以讓你頻繁地在修改代碼和編譯運行的狀態間切換。至少，我自己已經非常習慣了這樣的工作方式：運行程序看一下效果，退出程序修改少量代碼再運行程序。而Delphi 6的編譯器從來不會讓我有等待的感覺。
高效的執行
Delphi 6與C++Builder使用的是同一個後端優化器，因此其生成代碼的效率與優秀的C++編譯器生成代碼效率相同。
Delphi 6生成完全本地代碼，因此Delphi 6編譯結果的可執行文件可以被獨立執行、分發(對於“綠色軟件”的開發，這一點十分重要)。不需要其他運行庫支持。當然，你也可以選擇動態鏈接編譯，這樣可以大大減小可執行文件的長度，不過這種情況下在分發程序時，必須同時分發必要的運行庫文件。
構建Windows/Linux 應用
Delphi 6 與Kylix兼容。使用Kylix，可在Linux平臺上重新編譯基於Windows平臺的CLX應用；而利用Delphi 6，即可在Windows上重新編譯基於CLX組件的Linux應用。Delphi 6包含BaseCLX、VisualCLX、DataCLX和NetCLX四個組件。
與AppServer集成
Delphi 6通過最新SIDL與AppServer連接。它爲AppServer應用開發出高性能、具有豐富GUI環境的客戶端應用，通過Internet將AppServer的EJB功能作爲遵循業界標準的SOAP/XML Web服務發佈到全球。(李爭)
編後語
現在，各種開發工具的功能相互大量重複，一個大而全的工具幾乎總是可以被幾個別的工具代替。工具的選擇確實非常讓人迷惑，但是，無論是開發人員還是管理人員都應該意識到：工具只能起到協助的作用，嚴格的軟件工程管理和開發人員的技術水平纔是軟件開發成功的關鍵。成功開發加上有效的管理和市場運作，才能構成一個完整的成功軟件。 小資料
開發工具的對壘
軟件開發人員沒有人會不知道微軟的.NET和Sun的J2EE。二者儘管所提供的方法不同，但都具有許多非常優秀的特點。
二者的可移植性都非常好。.NET的核心只能工作在Windows環境下，但從理論上講可以支持多種語言開發?只要這些語言的子集已經定義好，併爲他們建立了IL編譯器?。對於J2EE來說，只要遵循Java VM?規則?和一組平臺需要的服務，就可以在任何平臺上工作。因爲所有定義J2EE平臺的規範，都已經向公衆公佈，所以，許多供應商也提供兼容產品和開發環境。
.NET並不是一種精巧的標誌，而是微軟策略的重大轉移，它將給其操作系統平臺帶來更大的支持率。現在他們正努力把Java和開放資源自身所特有的語言逐步開放，然後實現直接滿足開發商的需要。Java清除了平臺的障礙。但是爲了用J2EE來做開發工作，用戶必須在Java環境下工作。而.Net是想讓用戶使用自己選擇的語言來建造.NET應用程序，這是十分美妙的。
對於微軟的開發商，.NET是一個好的構架，用戶可以將許多事情交給微軟的體系結構去完成。ASP.NET比ASP好，ADO.NET比ADO和DCOM出色，C＃比C和C＋＋更好。所以，如果現在正在微軟的開發構架中從事開發工作，將.NET的元件採納到你的體系結構中，顯然是一個明智的選擇。不過，雖然.NET平臺描繪了美好的藍圖，但其設想要全部成爲現實，還有較長的路要走。例如IL公共語言的運行，目前還有某些明顯的障礙需要克服。想要把每一種語言和元件運行時集成起來，必須定義這種語言的子集/超集，並清晰地影射到IL上；此外必須定義結構，以便提供IL需要的元數據；還有必須要開發適用於兩種編譯語言結構的編譯器，集成到IL部件字節代碼中；同時還要生成對現有IL元件的語言專用接口。
由於歷史的原因，在Java語言中使用非Java語言，必須要開發非Java語言到JavaVM的衆多轉換器。因此，在Java環境中寫代碼，就必須要承受將額外的翻譯工作加到目標構架上。如果Java環境是目標，人們通常會選擇學習Java。而如果目標環境是.NET，那麼人們將會選擇學習C＃。(伊利貴)
64位的軟件開發
因爲在內存容量、I/O處理效率等方面64位系統有着32位系統無可比擬的優勢，因此在高端應用上，Sun、IBM和HP等大腕一直熱衷於64位系統。可以預見，在不久的將來，Intel的64位處理器將成爲Sparc的主要競爭對手。
不過，由於Linux和Windows環境下的主要的應用程序都是32位的，因此，軟件廠商和自由軟件項目必須爲64位系統重寫他們的應用程序。所幸的是，由於Java的盛行以及.NET的出現，這將使得應用程序向Itanium的移植變得非常神速。IBM已經推出了其用於Itanium的Java SDK(軟件開發工具包)，此外，微軟的.NET框架在其發行.NET Server時，也將登陸Itanium。而Borland更是已經使其Java開發工具和服務器可以在Itanium上運行。(伊利貴)