飛揚天下

引言：

GameByro作為一款次世代引擎，使用了復雜的材質系統，用來滿足各種各樣的需求。材質代表了物體受到光照后所呈現出的質感，而這種質感在計算機圖形學中需要著色代碼來完成，所以當前流行的圖形引擎設計是使用被渲染對象的材質與shader相關聯，GameByro也不例外。GameByro的材質系統可以通過shade tree生成shader程序，增強了應用程序層對可編程渲染管線的控制能力。

渲染架構概覽：

在GameByro中，對象表面的色彩、紋理、光滑度、透明度、反射率、折射率、發光度等可視屬性與傳統的材質系統分離，獨立的成為了對象的渲染屬性（NiProperty），而材質（NiMaterial）僅用來對著色程序的封裝，這樣就實現了渲染數據和渲染方法的分離，降低了耦合性。如上所說的這些可視屬性在Gamebyro中會封裝成一個屬性對象，在應用程序中如果對對象掛載這個屬性對象，在GPU程序中就可以訪問這個屬性對象的值。渲染屬性對象可以在創建時指定其類型，如紋理、浮點、矩陣、向量或數組，此外一些全局性的對象也可以通過在Shader中用語意聲明為全局object對象，如燈光和攝影機等，這樣就可以以同樣的方式來訪問這些對象上的屬性。

GameByro每一幀的渲染（NiRenderFrame）劃分為多個步驟（NiRenderStep），每個步驟又包含很多個批（NiRenderClick），NiRenderFrame封裝了上層對渲染系統調用的接口，而NiRenderClick則代表了圖形硬件的一次繪制操作（對渲染隊列中所有的對象的頂點緩存調用DrawPrimitive），當應用程序調用NiRenderFrame的Display接口時, NiRenderFrame會依次調用每一個NiRenderStep的Render()接口，NiRenderStep就會執行所有的NiRenderClick操作。

對于每個NiRenderClick來說，首先要設置視口和渲染目標，也就是渲染數據流的入口和出口。視口建立以后就可以通過關聯的攝影機對場景圖中的對象進行裁剪（默認的有視口裁剪和遮擋裁剪，此外還可以通過回調函數加入自己的裁剪方式），將未被裁剪的對象放入渲染隊列。然后Gambyro會根據材質來對渲染隊列中的對象進行排序，讓材質相同的對象處于相鄰位置，這樣可以減少切換shader的開銷。

如圖所示為幀渲染系統的結構圖（簡化版）

材質系統：

GameByro中的材質代表渲染對象所采用的方法。前面說過。紋理屬性包含了著色所需的原料，那么材質就指定了對這些原料的加工方法。基于當前可編程渲染管線設計，材質就成為連接對象與GPU程序的中間層，應用程序可以通過材質將shader應用于幾何體。

NiMaterial類是所有材質的基類，這個類通過一個Map來保存當前應用程序中所有NiMaterial的指針，當然這個Map是靜態也就是說相當于全局變量，通過static NiMaterial* NiMaterial:: GetMaterial(const NiFixedString& kName)接口對這個全局的Map進行訪問。也就是說，當前環境中所有的NiMaterial對象是通過NiMaterial類來管理的。此外NiMaterial類還通過靜態成員變量保存了一個工作路徑（即shader文件路徑），通過這個路徑加載shader文件。NiMaterial就像是一個中介，全權代理對對象的渲染工作。用戶可以通過重載NiMaterial來實現自己的渲染機制。每個NiMaterial都是全局性的，可以作用于多個甚至是所有的渲染對象，但一個渲染對象也可以擁有多個NiMaterial，但只能有一個處于激活狀態的NiMaterial。

NiMaterial的派生類NiFragmentMaterial提供了對可編程渲染管線完整的控制機制，內部保存了NiShader的哈希表、一個NiGPUProgramCache數組。并且NiFragmentMaterial會生成一個用來編譯GPU程序的shade tree（后面會有解釋）。這樣的話，每個NiFragmentMaterial可以對應多個shader程序，這樣就提供了一種機制，在運行時根據不同的運行環境和渲染對象不同的狀態，來選擇合適的shader程序。在NiRenderClick依次渲染可見集中的每個對象時，首先會判斷其是否需要被渲染的標記（flag），如果需要被渲染，則使用NiMaterial::IsShaderCurrent接口判斷當前shader（上一次渲染所使用的shader）是否有效，所謂有效就是仍然存在并且可以應用于本次的渲染對象，如果無效，則會調用NiMaterial::GetCurrentShader獲得shader，用于本次渲染。NiMaterial::GetCurrentShader會根據渲染對象的屬性和當前環境硬件條件來選擇合適的shader程序。當然，可以通過重載IsShaderCurrent和GetCurrentShader接口來指定自己的有效性判斷規則和如何選擇shader程序的方案。 NiFragmentMaterial提供了一套搭建shade tree的框架，用戶可以通過重載來搭建自己的shade tree，當然，如果不想通過shade tree的形式生成shader程序也可以，使用NiSingleShaderMaterial可以從文件生成shader程序。

Shade Tree：

什么是shade tree呢？我們通常編寫的shader代碼是線性執行的，即每個pass流程執行的是文本上定義好的shader流程，每一段shader功能模塊是按一定順序依次執行的。如果需要修改流程中的某一部分就需要更改相關的shader代碼并重新編譯。而shade tree將shader代碼以樹形結構組織起來，每一個shader代碼塊（一般是一個函數）都會被編譯成一個節點，通過定義輸入變量和輸出變量來提供數據流的入口和出口，這些節點的插入和刪除可以通過應用程序來控制，從而靈活的控制整個渲染過程。這樣shader程序中的一些核心模塊可以由美術通過工具生成，然后插入到shade tree中，只要輸入和輸出的接口不變，就無須修改其他代碼，從而降低了美術開發shader的門檻。

GameByro通過以下幾個類搭建shade tree:

l NiMaterialConfigurator：shade tree被封裝在這個對象中，Uniform constants被封裝在NiMaterialResource中，而NiMaterialNode封裝了相關的shader代碼，所有的資源和節點通過NiMaterialResourceBinding連接起來。當所有的連接都確立以后，NiMaterialConfigurator會調用Evaluate接口生成GPU程序和一個輸入Uniform資源的集合。

l NiMaterialFragmentNodes：這個類包含了一個shader代碼片段的集合，這些代碼片段為不同的平臺和編程語言所編寫。這就為shader程序員提供了更大的靈活性，用以控制他們的代碼在不同平臺和圖形硬件上的表現。例如：在高端平臺可以采用高級的shader model提供更好的效果，而在低端平臺上可以關閉一些特效來加快速度。

l NiMaterialNodeLibraries：這個類是一個NiMaterialNode的集合，其實也就是一個shader庫。它允許shade tree節點完全基于數據驅動。shader庫的生成可以通過兩種方式，解析XML文件或用XML文件生成C++代碼。GameByro提供了相關的解析器和代碼生成器。

l NiMaterialResources：shade tree中的Uniform constants，支持多種數據類型，包括Constant、Predefined、Attribute、Global、Object。

固定管線的渲染：

GameByro支持固定管線的渲染，其紋理混合過程如下。

固定管線的著色處理流程

上圖很清楚的顯示出了每個stage的操作，平行的表示兩張紋理的采樣是同時進行的，特定情況下右邊的紋理可能被忽略。

大部分情況下，應用程序不會使用上面所有的stage，開啟或者關閉那個stage可以由應用程序來指定。

以下為多重采樣的原理圖:

固定管線的紋理多重采樣

缺省的著色處理流程：

GameByro提供了一個默認的著色處理流程，封裝在NiMaterial的派生類NiStandardMaterial中，這個類執行類似于固定管線的流程，在不同階段將紋理采樣、并將采樣到的數據混合到最終的結果中去。

GameByro默認的材質系統的特性如下：

• Skinned and unskinned transformations. Skinned transformations can support up to 30 bones per draw call.
• Vertex colors
• Base maps
• Normal maps
• Parallax maps
• Dark maps
• Detail maps
• Bump environment maps
• Gloss maps
• Glow maps
• Decal maps (up to 3)
• Cubic and spherical environment maps
• Point/Spot/Directional/Ambient lights contributing to the diffuse, specular, and ambient color. Up to 8 total lights. Per-pixel or per-vertex.
• Projected light maps. Clipped or unclipped. (Up to 3)
• Projected shadow maps. Clipped or unclipped. (Up to 3)
• Texture transforms per map.
• Per-vertex fog

下圖顯示為不同的紋理、燈光、材質屬性的組合過程，不過需要注意的是，視差貼圖和凹凸貼圖屬于特殊的情況，它們僅僅影響到紋理采樣的UV坐標，而并非直接對最后的顏色值產生貢獻。視差貼圖會改變所有貼圖采樣的UV坐標，而凹凸貼圖僅對環境貼圖的UV產生影響。

以上流程完全由shade tree構建，NiStandardMaterial提供了大量的函數接口用于對每個流程的控制，用戶可以通過重載相關的接口，插入自己的shade tree節點，修改每一步的操作或處理過程。例如：

virtual bool HandleBaseMap(Context& kContext, NiMaterialResource* pkUVSet,

NiMaterialResource*& pkDiffuseColorAccum,

NiMaterialResource*& pkOpacity, bool bOpacityOnly);

當然，整個流程的順序和結構修改起來比較困難，如果有需要可以定制自己的材質系統，搭建自己的shade tree。

NiStandardMaterial提供了若干回調函數，這些函數可以動態的修改流程，分割PASS，對shader運行失敗進行容錯。

l SplitPerPixelLights/SplitPerVertexLights:這兩個函數分別作用于逐頂點光照和逐像素光 照，當物體所受的光源數量太多，超過了頂點或像素著色器的能力時，通過這些函數可以將失敗的pass分割成兩個，如果分割出的pass仍然不能執行，那么函數會被遞歸調用，直到每個pass只有一個光源為止。

l SplitTextureMaps：這個函數會把對紋理采樣的pass進行分割，當紋理查詢過多時，頂點或像素著色器就會過于復雜，這時就可能導致shader運行失敗。此函數只能迭代一次，生成一個額外的pass。

l DropParallaxMap：這個函數用來從幾何體上移除視差貼圖，且不產生額外的pass。

l DropParallaxMapThenSplitLights：這個函數首先調用DropParallaxMap移除視差貼圖，然后一直調用SplitPerPixelLights直到失敗為止。

NiMaterialInstance：

NiMaterial并不是直接與NiRenderObject相關聯，而是經過了NiMaterialIstance這個中間層，由它來代理將NiMaterial關聯到幾何體，它負責調用NiMaterial為NiRenderObject生成NiShader，通過改變NiMaterialIstance上的接口SetMaterialNeedsUpdate，可以決定每一幀NiRenderObject所使用的材質是否需要被更換，通過接口SetDefaultMaterialNeedsUpdateFlag，可以決定當前材質所需的數據（即當前渲染流程所需的數據）是否要被更新。這樣每個NiMaterialIstance只能被一個NiRenderObject所擁有，而多個NiMaterialIstance可以共享一個NiMaterial，這樣就減少了重復創建NiMaterial的時間和空間上的開銷，同時降低了渲染對象個材質之間的耦合度。

如下為材質系統的類結構簡化圖：

渲染屬性：

前面提到過，GameByro將渲染所需要加工的數據全部封裝在了NiProperty中，只要在shader中用指定的語法進行聲明，就可以訪問這些屬性的值。

目前引擎中已經定義了12種屬性，均派生自NiProperty，分別代表渲染數據的12種不同類型：

l NiAlphaProperty

l NiDitherProperty

l NiFogProperty

l NiMaterialProperty

l NiRendererSpecificProperty

l NiShadeProperty

l NiSpecularProperty

l NiStencilProperty

l NiTexturingProperty

l NiVertexColorProperty

l NiWireframeProperty

l NiZBufferProperty

用戶也可以自定義屬性類型，但所對應的數據類型要被shader語言所支持。

光照與陰影：

光照與陰影密不可分，因為陰影就是由光照產生的，前面在材質系統中已經提到過光照對著色的影響，這里重點闡述，GameByro是怎樣根據光源產生陰影的。由GameByro提供的陰影均基于ShadowMap技術，

但也提供了ShaowVolume的示例代碼。

Shadowing System是完全建立在幀渲染系統上的， 通過一個RenderClick生成ShadowMap，然后在正常渲染流程開始之前將ShadowMap更新到可見集內每一個渲染對象上。這樣當渲染對象使用NiStandardMaterial時就會根據光源的陰影技術來對ShadowMap進行采樣，并將結果與最終的輸出顏色按一定比例混合。

陰影系統由以下幾個類構成：

• Shadow Write Materials:從NiFragmentMaterial派生，封裝了生成 ShadowMap的算法和著色程序。

GameByro提供了三種類型的Shadow Write Materials，分別為NiPointShadowWriteMaterial、

NiDirectionalShadowWriteMaterial、NiSpotShadowWriteMaterial，適用于三種不同的光源類型。

• Shadow Technique:這個類封裝了陰影算法的細節，包括生成ShadowMap和使用ShadowMap投射陰影。
• Shadow Render Click: 這個類是一個生成ShadowMap的批，這個類的對象是由shadow click generator負責生成。
• Shadow Click Validator: Shadow Render Click:通過此類對象判斷接受陰影的幾何體對于shadow generator來說是否可見。
• Shadow Map: 每個ShadowMap對象包含一個作為陰影圖的紋理，shadowmap對象由shadowManager直接管理，每個shadowmap對象都被一個shadow generator引用。
• Shadow Cube Map: 同shadowmap作用相同，只是陰影圖的紋理類型為CubeMap。主要用于點光源生成的全方向陰影。
• Shadow Generator: 陰影生成器，每個ShadowGenerator都對應一個NiDyamicEffect（NiLight的基類），也就是為這個NiDyamicEffect代表的光源生成陰影， 生成陰影所采用的技術由對象引用的ShadowTechnique來決定。
• Shadow Click Generator: 生成ShadowMap的Shadow Render Click都由此類負責創建。這個類為每個ShadowGenerator指定ShadowMap，并負責每幀更新ShadowMap和ShadowMap所對應的變換矩陣。
• Shadow Manager:所有的ShadowMap、ShadowTechnique、ShadowGenerator、shadow render click對象都由ShadowManager統一管理，并負責使用一個shadow click generator 在每一幀生成一個shadow render click的列表。

陰影系統靜態結構如下：

整個陰影渲染的流程大致如下：

1. 在應用程序初始化階段，通過調用NiShadowManager的Initialize()接口實現對整個陰影系統的初始化，此時應用程序會注冊所有的ShadowTechnique，并初始化NiShadowClickGenerator。

2. 當我們創建一個NiLight以后，我們可以通過NiShadowManager為這個NiLight新建一個NiShadowGenerator，NiShadowGenerator會通過NiLight的類型來選擇合適的NiShadowTechnique，此時NiShadowManager會為新的NiShadowGenerator創建一個NiShadowRenderClick。

3. 當幀渲染系統啟動后，NiShadowRenderClick的PerformRendering()接口會被調用，此時NiShadowRenderClick會通過引用的NiGenerator獲得陰影生成的著色程序和所需的數據（例如深度偏移），同時通過NiGenerator引用的Camera獲得場景圖中的可見集。下一步就是對可見集中的渲染對象添加ShadowWriteMaterial并設為激活狀態，而ShadowWriteMaterial的類型是根據NiDyamicEffect的類型指定的。最后NiRenderClick就會啟動渲染流水線，將可見集中的對象的深度全部渲染到ShadowMap中。

4. 在第一個RenderClick中生成了ShadowMap，下面就要使用這些ShadowMap投射陰影。在每一幀開始之前，用戶還可以自己指定不接受陰影的節點，手動將其插入NiShadowGenerator：：m_kUnaffectedReceiverList中。在渲染BackBuffer的RenderClick中，首先會對場景圖中的節點進行一次遍歷，將不受陰影的節點放入NiShadowGenerator：： m_kUnaffectedCasterList的列表。在對每個節點進行渲染時，會遍歷NiShadowManager中所有的NiShadowGenerator，判斷這些NiShadowGenerator是否對這個節點有影響，判斷的規則是此節點是否存在于UnaffectedReceiverList和UnaffectedCasterList這兩個鏈表中，如果存在于任何一個鏈表，則節點不受此NiShadowGenerator影響，如果受此NiShadowGenerator影響，那么就將該NiShadowGenerator上的ShadowMap和數據更新到節點上的渲染屬性中，NiStandardMaterial會根據這些數據選擇對ShadowMap采樣的方式，并將結果混合到最終的輸出顏色中。

值得注意的是，點光源的shadowMap默認的是采用CubeMap實現，用戶可以通過接口選擇不使用CubeMap實現，當采用CubeMap實現時，光源無法產生軟陰影。

渲染系統的擴展：

為了驗證GameByro渲染系統的擴展性，筆者嘗試著加入了一個后期處理特效Screen Space Ambient Occlusion（SSAO）,即屏幕空間的遮蔽，由于僅僅為了熟悉GameByro的渲染流程，所以筆者并未對SSAO算法做深究，僅僅用了自己簡化的算法。

在渲染過程中先單獨使用一個RanderClick將場景中的深度渲染到一張紋理上，然后在渲染到后臺緩沖區的RenderClick中對深度紋理進行采樣，執行SSAO算法，將結果混合到最終的結果中。采樣點的偏移坐標是通過對一組隨機向量進行歸一化再乘以0~1之間的隨機數而生成的，即長度為0~1之間的隨機向量。

PS代碼如下：

float VerticalRange:GLOBAL; //控制XY方向采樣范圍變量，可以在應用程序層對其進行調整

float HorizontalRange:GLOBAL; //控制在Z方向采樣范圍的變量

float calAO(float2 texCoord,float dw, float dh ) //通過當前像素所標和偏移量計算AO

{

float2 coord = float2(texCoord.x + dw, texCoord.y + dh);

float4 CenterPos = tex2D(DepthSampler,texCoord);

float4 CurPos = tex2D(DepthSampler,coord);

float depthDiff = clamp(CenterPos.z - CurPos.z,0,VerticalRange);

float ao = depthDiff/length(CurPos.xyz - CenterPos.xyz);

return ao;

}

// Pixel shader

float4 PS_SSAO(VS_OUTPUT In) : COLOR

{

float2 texCoord = In.BaseTex;

float depth = tex2D(DepthSampler,texCoord).z;

float ao = 0.0;

float scale = HorizontalRange/depth; //因為采樣范圍會受深度影響，故除以此系數。

for(int i=0; i<32; ++i)

{

float2 offset = arrRandomPt[i].xy* scale;

ao += calAO(texCoord, offset.x, offset.y);

}

ao/=32;

float4 color = tex2D(BaseSampler,texCoord);

color.xyz *= (1.0 - ao);

return color;

}

最終實現效果如下：

SSAO生成的明暗圖 無SSAO材質

以下兩圖上圖為無SSAO效果，下圖為開啟SSAO后的效果。

總結：

GameByro的幀渲染系統是比較靈活，想加入自己的渲染流程是比較容易的，此外由于RenderTarget和RenderView都可以由用戶指定，所以想實現自己的shader效果不是很難。然而，NiStanderMaterial的shade tree比較復雜，總共高達6000行代碼以上，過程非常復雜，這就是說，如果想實現自己的材質處理流程也要付出相當大的工作量，陰影系統雖然實現了較低的耦合度，但是實現過于復雜，不夠簡潔高效。

作者：葉起漣漪

★ 你好，我去殺幾個人，很快回來。
★ 我去后山和黑山老妖研究吃唐僧的事，有事回來再說。
★ 便秘中。。。。。勿攪。。。
★ 你終于來啦，我找你N年了，去火星干什么了？我現在去冥王星，回頭跟你說個事，別走開啊
★ 您所呼叫的用戶尚未安裝QQ......
★ 你呼叫的人現在不在，當你聽到硬盤“咔”的一聲，請對著鼠標留言，謝謝......
★ 主人不在。到哪兒去了？就......就是不告訴你!真要找的話，請按住電腦power鍵4秒鐘后留言......
★ 該用戶沒有回應，可能用戶忙，請稍候再試。或按Ctrl+Alt+Del返回.
★ 自殺中，稍后再說...
★ 有事找我請大叫！
★ 你現在連接到的是海狼的冰箱，放入食物后請斷線，謝謝合作。
★ 我正在下五子棋，上次分心把褲子輸光了。這次再輸會被拍裸照！我可不想讓人看見，等這盤下完了一定回你。
★ 嘀，這里是自動應答，MM請再發一次，我就與你聯系；JJ請再發兩次，我就與你聯系；GG、DD就不要再發了，因為發了也不和你聯系！
★ 騰訊服務器系統崩潰，請稍后再試！
★ 計算機正在處理你的信息，請稍侯，如果長時間沒有響應，請重新啟動計算機！
★ 你好，現在我在玩一個叫CS(或其他)的游戲，有事請按下電腦上“RESET”鍵，在聽到“嘀”一聲之后留言，謝謝
★ 你有權保持沉默，你所說的一切都將被作為存盤記錄。你可以請代理服務器，如果請不起網絡會為你分配一個。
★ 您使用的QQ是未注冊版本。您可以繼續使用本軟件，但將屏蔽發送短信息的功能。支持國產軟件，請您注冊新版！
★ 廣告之后,馬上回來!
★ 正在澡澡哦～～不要偷看～～～嗯～啊～～嗯～啊～～～
★ 在加本人為好友前請詳細閱讀以下條款：1.未滿18歲者請在父母指導下與本人聊天；2.非專業聊天人士，不承擔主動招呼義務；3.謝絕你問我答制。在本人不回復的情況下請自覺停止一切信息！
★ 你所呼叫的用戶正在系統整理，請稍后再呼。
★ 此人正在被國際刑警組織全球范圍內通緝，如果您有此人的消息，請撥打當地報警電話120，請對著電話說如下密語言：我真的不是瘋子，我不是瘋子，我真的不是瘋子！然后匯報你的所在地謝謝合作。我們的專業人員會去保護您的安全。
★ 您的QQ已經中了我安插的病毒，請不斷向本人發信，否則本人一有閑暇立刻動手！
★ 您好，QQ今天休假，我是NETANTS......
★ 由于大氣電離層影響，與該用戶的衛星連接已中斷，請稍后再試。
★ 對不起，由于服務器的原因，您剛才發的信息丟失，請重發一面。
★ 機主正在裸奔，機主已奔出服務區。
★ 正在格式化你的硬盤，請稍候......
★ 唉呀～你可真調皮！你看，我話還沒說完你又來了～～
★ 嗨~我現在不在，如果有事請在聽到“逼”的一聲后留言······逼！
★ 對不起，網路不通，請重新發送...
★ 你要機主不在，請等到“嘟~”聲后拿起鼠標留言。。。
★ 對不起，您所呼叫的用戶不在計算機旁,請你現在立刻猛擊你的顯示器直到它冒火花為止,聽到響聲后我會給你回復
★ 你好。這是騰訊服務中心自動回復。收到這條信息表明您的操作系統出了問題。請按Ctrl+Shift+Del
★ 您所呼叫的用戶先不再服務區內......可能是網絡不通...想解決此類問題...請您將頭用力撞向顯示器......以保證網絡通暢......
★ 本人現在位置：WC； 姿勢：下蹲； 臉部：抽搐； 狀態：用力中。。。。
★ 注意：使用騰訊移動QQ的用戶可能無法立即獲取你的留言。
★ 我去吃飯了，如果你是帥哥，請一會聯系我，如果你是美女.................................就算你是美女，我也要先吃飽肚子啊
★ 你要和我說話？你真的要和我說話？你確定自己想說嗎？你一定非說不可嗎？那你說吧，這是自動回復，反正我看不見
★ 你好，我是XXX的自動回復，現在他不在，跟我說什么我也就這幾句！
★抽筋中……請勿打擾……
★悟空啊，你想和為師說話么？想說話你就說呀，你不說為師怎么知道你想和為師說話呢？

終于結束了近一個小時的枯燥會議，每周五公司級別的項目周會就像一個例行的檢查，多少有點不痛不癢的味道，大部分的時候就是一個例行貫事，每個項目組按照順序匯報一下各自項目組的情況和需要，如果不出現大的問題的話，也就是有本上奏，無本退朝的一個過程。或許有些人覺得這是一個比較浪費時間而且意義不大的會議，每周浪費大伙一個小時的時間去再次陳述這些本來在郵件中已經說明的問題和項目進度，不過存在就有價值，這個會議的最大的功能在于能盡量使各個項目組之間有部分的消息互通，至少能讓大家了解到一點，其他人都在做什么，從而避免了每個項目組過于孤立的現象。
       今天的周會時間有點長，主要由于兩件事情的討論超出了會議的議程安排，第一件事情是大偉負責的項目目前進度出了問題，目前人員處在一個持續加班的緊張狀態，即便如此，對于項目的最終Release時間還是比較確定的狀態，用大偉的話來形容就是：“我們能夠按時完成，但是可能會有點小問題。”一句比較含糊的托詞，如果說套用官方的言詞就是：“對于項目能夠按時完成，我們還是謹慎樂觀。”另外事情對于公司來說是一個好消息，公司將在下個月啟動一個新的項目，這個項目是今年規模最大的一個項目，其業務方向主要針對美國的醫療領域，規模大概有150人/月。
這個項目將會被安排到我們項目組來處理，消息對于我來說就是一個挑戰，對于自己來說，這個規模的項目也是超過了以往的一切項目，在會議上聽到這個項目將由我來接手處理，不由小小的興奮了一把，但是這股興奮的感覺很快就被沖淡，自己粗略的考慮了一下項目組內目前的工作量和目前的人員情況，不由感覺到這個活不太好攬。不過有壓力才有動力，這是我一貫的做事風格，類是這種明知會將苦重重的活，我越能夠信心十足。我簡單的在自己的記事本上寫下了以下下周的關健工作內容：確認項目的具體開始時間和結束時間；調整目前項目組內的工作內容；向客戶先要部分的開發相關資料；了解一下公司內部其它項目組的人員狀況。
       會議后半程的內容我沒有聽多少，只是對于大偉的問題大家有部分的討論，我才回過神來參與，大偉雖然說自己還是有信心能夠保證項目的進度，但是為了保險起見，希望從其它的項目組借調兩個人來協助他們做一些類是測試的工作，這樣的話總的進度就可以進一步得到保證。以目前公司的架構模式，每個項目組相對獨立的運作模式，如果說希望從其它的項目組借調人員，這種短期人員的借調有時候是比較困難，因為每個項目組目前來說都處于比較繁忙的階段，目前閑暇的人員不多，即便其它項目組肯借人，大多放出去的人員也都是能力相對比較弱，正常情況下人不可能把項目組內部優秀的人員借調出去，這或許也是人的一種私心。
       在公司的協調安排之下，最后還是給大偉支援了兩個人員，這才把討論不休的會議打住。會議結束后我還在會議室坐了一會，我的腦袋里還在考慮下周的工作順序，盯著自己的筆記本在對剛剛寫的問題進行細化，把工作分解到下周的每一天。突然一股濃濃的煙味直接灌進我的鼻子，我不用抬頭就能猜出是大偉，這個煙槍一天最少一包煙，如果遇到加班或則心情不好的話，估計兩到三包都有可能。
       “少抽點煙，怎么心情不好？”看著大偉吐著煙圈，我問道。
       “沒有，只是有點累。”大偉嘴里叼著煙，目無表情的應道。
       “我看到你們項目組的那些去年剛剛畢業的學生，最近是天天加班到晚上11點左右。這是怎么回事？”
       “噢，那時我故意的。”
       “故意？”我一時沒有明白，疑惑的問道，“為什么要故意呢？”
       “我是按照我自己的工作能力給那些新人安排工作，如果說我是能夠在上班時間內完成工作的話，那么那些新人肯定需要加班了。這樣他們才能進步。”大偉的表情中開始露出得意的神色。
       “怪不得他們要加班，你工作了多少年，他們才工作多少年，再說了你拿的工資和他們那得工資能一樣嗎？”
       “我就告訴他們，如果你想工資那得和我一樣，那么這些工作你能夠準時完成，那么你就有機會。”大偉熄掉手中煙頭，用雙掌在臉上使勁得措動。
       “那你該不會是按照你的能力來做的項目估算吧？”對于大偉的這個邏輯我并不能茍同，但是我還是想了解項目的問題。
       “嗯…..”大偉支吾著回答到。
       “哈哈，你這是自作自受。”我對著大偉帶著嘲諷的笑聲說道。
       對于大偉的做法我卻是無法茍同，雖然他的失誤在于前期的估算過于樂觀而且并不準確。但是對于給新人安排工作的方式上存在有比較大的問題，如果說前期的估算出現失誤，這些錯誤在后期項目開始過程中還可以進行添加人員的方法進行補救的話，那么對于人員使用不當的問題，就像整個項目過程的絕癥，其會影響到整個項目過程。
       項目組中開發人員從能力上有幾個不同的級別，系統架構師（Systems Architect）,高級工程師（Senior Engineer）,中級工程師（Middle Engineer）和初級工程師（Junior Engineer）等等。對于每個級別上的人員的能力和開發技能都有一定的差異。這些就像我們手的手指一樣，五指有長短，能力個不同。不同能力的人員應該在項目組中相應的工作內容和工作量。
       在正常的項目中我們講究的是人盡其用，但是不能把一個項目在開始的時候就設想是通過發揮項目組人員的超水準的基礎上來完成。很多人都說人在一定的壓力之下，能夠超能力的發揮出他們的水平，但是比代表說所有的人都能夠在這種環境下能夠有說突破，很多人在持續長時間的高壓下會顯得精神不振，萎靡的情況。所以作為項目管理來說，不能再項目一開始的時候就采用這個立足點來進行開發工作。
       對于大偉所說的那種歪論，我只能回應以自作自受的答案。我們給個人都是在逐步的學習和進步，如果說有一定壓力災，對于學習確實是一個比較有效的促進。但是作為項目經理來說，需要明白的是一個問題，我們的職責在于項目，而不是在于鍛煉新人，新人進入項目組織后，通過項目過程的工作和學習能夠提高他們的能力，這些是項目的副產物。而我們首先要保證項目的進度，質量。我在實際的項目開發過程中，對于給新人的工作計劃都是按照其能力的80%-90%進行安排，很少會針對新人能力的100%進行工作任務分派，因為新人由于缺乏經驗，所以在項目實際過程中如果遇到問題，他們解決這些問題的所采用的方法和思路都存在有時間的風險，有時候他們可能由于一個問題會難住他們，消耗掉很長的時間。即便我不斷強調說如果有遇到問題，在一個小時內解決不了的話，就要把問題拋出來給大伙來共同處理，但是往往這個問題被最后迫不得已提出來的時候，都是在一天或則更長的時間之后。新人在開發過程中遇到這些問題的概率非常高，所以在工作安排工程中必須要考慮到這種風險。所著一旦推倒第一張加班的牌，那么后續的將是多米洛效應，加班將一發不可收拾，進入惡性循環階段。
       對于實際的項目中我會采用減算安排工作的方式，那是因為我需要保留對項目整體的進度有更大的回旋緩沖時間。無論對新人還是對高級工程師，中級工程師和初級工程師我都會采用一樣的策略，因為人腦不是機器，所以我們無法保證我們時時刻刻都能正常的滿負荷運轉。但是在平常的學習過程或者非實際項目的鍛煉過程中，我會采用超負荷的工作安排模式，這個時候給人員的工作量安排都是100%-120%的程度，因為這個時候我的主要目的在于人員培養，所以需要一種超強度的環境，營造一種壓力的氣氛。其實開發過程何嘗不是一個不見硝煙的戰場，如果你想要在戰場上不受傷，只有在平時多多受傷，這樣在真實的戰場上才能從容應對。
       對于項目組中我們需要比較清楚的了解每個成員的能力和個性，如果對于他們的能力了解能夠像看著我們手指頭那么清楚，我們就能夠依據他們的長短，讓他們協調發揮出水平來。我們需要避免工作不分能力，均等劃分的安排方式，更不能把項目寄托在成員的超水平發揮的基礎上。在工作中我們需要明白項目的最終目的，項目成功還是鍛煉人員，從而采用減算還是加算得工作安排方式。
作者：Yice(小余)
出處：http://www.yice800.cn

超仔剛剛推門進來，屁股還沒有碰到他的椅子上已經讓人感覺到他歡喜輕飄的神色，我抬頭望著他眼睛，神色中洋溢的滿是歡快。我看著他那興奮的樣子，微微笑著問道：“簽完了？結果還可以嗎？”
“還不錯！”
“能滿意就可以，繼續努力。”
“嗯。”
我知道超仔剛剛和公司簽了新的合同，在新合同里他的工資有了一定的提高，這些都是因為對于他去年的績效考核成績還不錯應該得到的結果。
年底對于我來說，可真是多事之秋，因為我需要在年底前完成對我團隊這些人的一年的績效評定，這些不但關系到他們年終的獎金，也影響到來年他們工資的漲浮。雖然自己一直講究的是賞罰分明的做事方法，但是往往對于我來說要清晰分析哪個人在過去的一年中犯了什么樣的錯，對于這些錯誤去做一個評定，算其功過，工作不亞于一個項目的開發。一方面如果我評定的尺度太嚴格，那么最明顯的一個影響就是年底年終獎金和來年的工資，在工作中涉及到這部分利益的東西處理起來本身就是敏感，所以自己一直都是平時嚴厲甚至苛刻，但是到這個時候，我反而會手下留情，只要態度對位，錯誤可以酌情考慮。對于我來說，一個人的態度決定他的一切。
“我的工作目標就是要替掉你。”這是超仔在面試的時候留給我印象最深的話，也因為這句話我發而對他有不少的好感。人最應該有的是有自信，超仔是剛剛畢業一年的新人，在面試時候做在我前面表情僵硬，全身緊張的他，在我問“你希望進入公司之后，能夠有什么養的發展方向時？”這樣的回答可能是一種自大，但是在我看來，這也是他的自信。也這是這種自信讓我決定錄用這個計算能力不算好，但是我覺得各種條件還算合格的小伙子。
當然我也非全憑一句“就要替掉你。”就把小伙子招聘進來，然后放到自己身邊使勁摟擰，我想自己還不至于有這種變態的愛好。我喜歡面試的時候讓應聘人員都手動填寫一份簡歷，雖然很多時候他們自己都帶了一份打印的現成簡歷，但我還是會讓他們把公司那份表格填寫完整，雖然很多時候他們自要把內容抄寫過去就可以，但是這也是我對他們的第一個考驗。很多程序員的字寫的都有大師級的水平，對于他們來說，楷書，行書都不足以表達他們的意境，狂草，唯有這個才能體現他們的追求。有不少程序員在填寫這個簡歷的時候，字跡就和天書一樣，當然文字也像蛇一般的在紙上盤繞。
對于我來說，我只是通過這張簡歷看看他對自己的一個態度，我不要求他們的字能夠達到書法家的水品，但是至少要工整，整個紙張讓人看起來要干凈清晰。我很難看到你對目前的工作有多少的渴望，但是我可以通過你寫下來的文字看出來你是否重視這個事情，如果連工作機會都不重視，那以后的態度就值得擔憂。所以通過這個我也放棄掉不少的人，雖然有些人在和我免談的時候給我感覺也非常不錯，但是如果兩者結合在一起評定，如果后面沒有做好，那么我只能認為他是學院派的，能說未必能做。
超仔長的不像程序員的樣子，一米七五的個子，相貌也有幾分帥氣，留著平頭短發，每日衣著新潮個性。他平時個性活潑開朗，又一次他還請了一天的假，說是去參加超男的選拔賽，結果回來之后，感慨道：“強人太多了，人外有人。”不過自己到沒有為被淘汰的事情耿耿于懷，倒是很享受樂在其中的過程。
超仔進入公司的時間也只有半年左右，在這邊年里面他不到兩個月就給他轉正了，比公司規定的三個月試用期提前了一個月多。肯學習和努力的態度讓我對自己當初挑選他感到非常滿意。在第一個月培訓的時候，讓他整理了以前遺留的舊的項目，那些項目本身缺少相關部分文檔，但是由于項目一直在延續開發，所以久而久之，也就這么一直持續的做下來，那些已經對這些內容滾瓜爛熟的人也就沒有心情去做，后來者也之能夠在前輩的口傳身教的情況下才能了解其中的奧妙，我一直希望能夠把這部分資料補充完整。但是由于人手上不足，所以就一拖再拖。
公司對新人有比較詳細的培訓計劃，在這些培訓之外，我對超仔說：“你看看這個程序，因為你以后需要維護和開發這個，如果你有時間的話，可以把熟悉開發環境的步驟寫成文檔，文檔的格式可以參考項目組內其他的模板，內容你線考慮一下，但是有一個要求，如果另外一個新人來接觸這個程序，我需要他再看了你的穩當之后，就可以把環境搭配起來。些做的方式可以圖文結合。”
結果在一周之后，超仔就給我說：“小余，我把那份文檔寫了一部分，你先看看有什么問題，如果不行的話我再修改。”
很多人都知道程序員非常討厭寫文檔，所以很多程序員寫出來的文檔比寫出來的代碼還要難讀，有時候讀這種文檔就是一種折磨，比讀法律條款還難受，估計很多時候需要和法律文件一樣，需要再配套上一本詳細的解釋才能把問題說明清楚。
但是超仔的文檔讓我非常滿意的地方在兩個地方，一方面再環境搭建的時候，用了截圖的方式描述，而且每一幅圖都是用作圖工具簡單的剪裁過，只保留關鍵部分，而避免樂像其他人那樣是整個屏幕的圖片，在么個圖中對于操作關鍵區域還用紅色正方形邊寬標注說明，每個圖片還有編號。
另外一個是整個文檔是用Excel文檔做成的，因為公司比較喜歡用Excel做給中開發文檔，但我嘗試著用打印預覽的時候，讓我驚奇的事情發生了，總共10頁的文檔，每一頁都調整過，圖片沒有出現跨頁的問題，而且打印的頁頭和頁尾都修改過了，并沒有保留上個文檔的名稱，作者和日期也都是正確的。
“頁面打印是你調整過的？”看著文檔，我輕聲問道。
“我常常聽到你讓大家發郵件給客戶的時候，要預覽一下。所以我也就調了一下。”
聽到這話，我心中是暗自竊喜，一個新人能夠有這樣的工作意識和態度，實屬可造之才，技術可以學習培養，但是如果你想改變一個人做事態度其難度要遠遠大于技術上的培養過程。
超仔在后續半年的工作中也有犯了不少的錯誤，從剛剛開始技術上弱勢，但是好學肯問，其進步的幅度不小，也使得他在很快的時間內能夠達到對他所定位的能力要求。在于我看來這一切取決于他的態度，態度端正。
“態度端正，學習良好。”我的腦海中突然冒出這幾個字，這不是小學時候，老師在每學期的期末成績單上最喜歡用的兩個評語。什么是態度？怎么才能算是端正呢？我在心中問了一下自己：“我的工作態度算不算端正呢？”或許像超仔這樣的新人屬于上升求學階段，所以憧憬無限，但是對于我來說呢？當年何嘗不是如此，現在還是不是一就有這樣的心境呢？
“哎。”想著想著，不由自己嘆了口氣，難道我老了嗎？怎么我還沒有感覺到青春燦爛，這青春怎么就沒了呢？看看坐在開發室中的其他人：老馬，阿毛，木子，超仔，大師, 杰克這幾個人，我們應該是活力無限的開發團隊。
“Hi,小余，你在嗎？”還沒等我在繼續發愣，MSN上的就彈出消息來。是上海的PM李。
我急忙回過去問有什么事情。
“我剛剛給你發了一封郵件，我把需要像客戶移交的內容重新做了一個整理，你再看看有什么問題沒有？”
我突然記起來，昨天晚上快接近9點的時候，我還在理發店修頭發的時候，就接到李從上海給我打過來的電話，她問我現在有沒有先前她發給我的計劃列表，因為明天客戶需要確認，所以她想今天晚上再把這份計劃列表完善一下，如果我筆記本上有備份的話，給她轉發一份，結果我剛好也只是把郵件接收到公司的機子上。最后我聽到她在電話里說了一句：“那好，我明天早點去公司去修改一下，然后再給客戶。”
李在一個月之前已經和公司提出離職的申請，因為她家庭的原因，她需要到國外發展。應該說再過兩天她就會到美國去了，她本來是這個項目上海的項目經理，但是對于我來說，她是一個非常優秀的項目經理，從她身長我看到了一個項目能夠成功的關鍵，態度。也就是她的這種工作態度，讓整個項目有序穩定的進行。
在聽完李的電話之后，我里一直佩服到，這才是工作態度。
作者：Yice(小余)
出處：http://www.yice800.cn

你有沒有考慮過自己能夠管理多大的項目，能夠帶領多少人員的項目團隊？5人？10人？100人？還是千軍萬馬？但是在現實的項目中，能夠帶領100人員的項目經理未必能夠帶好10人的團隊，反之亦然。因為作為軟件項目來說存在有非常大的差異？無論你是大才還是小才，我們首先要清楚的認識到自己的才能是否能符合項目的實際應用，5人的項目和100人的項目團隊中項目經理的工作重心必然不同，如果不區別對待，那么你的結局是大才小用，或者是小才大用。
項目的差異性
我沒有機會參加類似IBM的OS／360規模的項目，我所能夠參與的最大項目規模不過是100人/月上下的項目，當然也做過產品線的長期開發項目。所以對于那種巨無霸形的項目也只能是望梅止渴，對于其中的奧妙也只能捧讀《人月神話》這類的經典，希望能夠從中吸取精華來強壯自身。
項目的規模不一樣，項目所能夠配備給定的人員也不一樣，對于大型的項目，除了項目經理之外，還會配置項目輔助管理人員和咨詢顧問管理人員等。如果說項目超過了10000人/月這個規模，項目往往會采用縱向切割來進行管理，整個項目會像工廠中產品線生產方式：系統需求；系統設計；配置管理；代碼開發；系統測試；文檔編寫；產品構建等過程，整個項目會根據不同的分工被切割成每個小項目團隊，雖然每個團隊可能的工作都只是針對于局部，在各自的內部這些工作是相對獨立的，但是每個項目又都對其他部分有比較嚴重的依托，比如系統設計是以項目需求為基礎，代碼開發是以系統設計為前提，所有的工作序列彼此關聯，每個工作都可以獨立安排二級甚至三級的項目經理，這樣整個項目的組織管理模式也就形成了金字塔的模式，從項目經理到最底下的開發人員形成一個自頂向下的體系結構。這個時候對于項目經理的主要工作也就不能要求事必躬親，小到一個螺絲釘都要親自過問，對于這種項目經理的要求更多在于總體協調和整體的掌控上面，他就像一個元帥一般的任務，要的是果斷的決策，準確的判斷，良好的協調和豐富的管理經驗。
實際上大部分的項目經理很難有機會成為如此大規模項目的最高決策者，即便有機會參與的時候，更多都是處在二線或者三線的位置，所能夠管理的實際人員也大部分在10人或則20人左右。更多項目經理參與的項目都是中小規模的項目，畢竟中小的項目的數量還是非常巨大，所以有很多的項目經理在從事這種的開發工作。對于項目規模在100人/月的項目對于很多公司來說也算是具備有一定規模的項目，這些項目的人員投入一般都會在10人之上，不會有公司對這種項目采用投入一個人做一百個月的方式。對于10人規模的項目管理對于大部分的項目經理來說可以是一個不小的挑戰，因為雖然說項目的規模不能與上述所說的超級項目抗衡，但是項目在整體過程中所做的事情和上述相當，系統需求，系統設計，配置管理，代碼開發，系統測試，文檔編寫，產品構建等都不會缺少，但是在人員配備里面可沒有二級或則三級的項目經理，甚至很多時候會有人力資源捉襟見肘的情況，在10人的規模里面可是要包含需求做成人員，項目開發人員，測試人員等。在很多的時候一個人需要充當多個角色，可能在某一個階段你需要做需求，當需求做完了之后，你又需要投入開發，后期的時候可能需要做項目文檔和項目部署，甚至用戶培訓。所以對于我的直觀感覺來說，這種項目對于項目經理的能力要求可能更高，如果要做好這種項目的項目經理，首先最好有比較扎實的技術開發能力和工程背景，這樣你的項目估算才能做得比較準確，為后續的開發贏得更多的時間；其次好需要又比較良好的業務知識，因為你可能更多需要做一個用戶的接口，所有的需要都需要通過你和客戶去溝通，以及最終的定案，所以對于業務的熟悉程度也至關重要；再者需要又良好的計劃性，因為這種項目的變數比較多，項目不會像又很長的規劃周期，所以如果控制好這些可變因素，已經如何協調內部的有限資源，讓資源發揮最大的優勢可能成為項目經理每日計劃中關鍵的一部分。
還有不少的項目規模在10人/月左右的項目，這種項目對于很多公司來說屬于不痛不癢的項目類型，因為同一個時期內公司可能會有多個這種類型的項目同時在進行中，在這種情況下項目所能夠獲得的資源就更加有限，往往項目的安置人員也就在5人左右，當然和上面兩種情況類是，項目過程的事情還是不可省缺，但是由于項目總體的規模偏小，所以項目的復雜度也比較容易控制，但是這種項目對于項目經理的要求更多在于技術上的要求，因為如果這個時候在安排一個缺乏技術經驗的人員做項目經理，那么整個項目組的安排出現一個外行領導四個內行的局面，而且四個內行中可能有一半以上是新人或者初級的開發人員，如果再包括測試等一系列的工作，人員分布上就缺乏合理性。所以這個時候的項目經理往往都是技術過硬的人員擔任，這樣可以化解人員不足的問題，但是也有一個問題，對于技術優秀的人員都會有一個通病，首先看不上別人的工作結果和質量，另外一方面往往會以自己的標準去衡量別人和給人安排工作，這樣對于新人或者初級的開發人員來說，他們的工作就會出現不合理的問題。同時在做估算的時候也比較容易出現輕易的問題，以自己的能力估算項目進度，結果造成項目估算不準確，后期嚴重加班的問題。所以這種類型的項目經理需要又良好的技術背景，還需要學習項目的實際管理和合理的人員安排，以及如何做好與項目內部成員的友好溝通和關系。
最后一種項目類型就是那種一個人吃飽，全家不額的類型，項目規模非常小，不到1人/月，所以在這種項目的投入人數往往只有一個人或則兩個人。當然這個時候也不會要求說項目開發的那一系列的工作都做到位，很多時候都是口頭相傳，這種項目的結果大部分之要求軟件代碼和程序能夠滿足要求。所以這個過程中很多人可能認為只要管好自己就可以了，但是我認為，時間雖然短，但是事情還是需要做足，比如說需求的明確文檔化，還有與外界的溝通等一些列過程實際上都可以和正常的模式一樣，對自己的工作也需要有一個良好的計劃，這個時候對于自己的要求就是一個鍛煉的機會，為今后做更大的項目準備好時機。所以這種項目經理的要求實際不抵，如何管理好自己可能會是一個比較大的難題。
項目類型的差異性
項目從規模差異上來說是對一個項目經理的開發能力，管理能力等有不同的要求。但是如果說從項目類型的差異的角度來看，就會對項目經理的一些其他能力又要求，如果說你做的是國內的項目，那么你需要有與客戶溝通的良好能力，能夠有足夠的能力應對客戶的各種要求，如何應對客戶千奇百怪的要求，如何合理的說“NO.”都是你需要具備的能力。如果說是對日，對歐美的外包服務開發，需要有良好的語言溝通能力，比如說日語，英語。還需要了解不同國家的文化差異等等，這個時候你可能需要充當起橋梁的作用，如何與國外的客戶進行溝通和交流，包括有工作安排，技術上等一系列問題的溝通工作。
給自己的定位
項目管理本身就是一個比較復雜的過程，不像行軍打戰那樣，有了一盯一眼的制度就可以管理好項目，因為項目的變數太多，情況迥異，也就沒有放之四海而皆準的管理方法。所以對于不同類型的項目來說，我們需要了解項目的特點，在我們有良好的基礎準備的前提下，根據自己的能力特點，再結合項目的實際情款來不斷調整工作中的方法和內容。
雖然我們很難有一個標準化的管理手冊來指導每一個希望做項目經理的人，但是我們可以從別人身上去借鑒各種成功或則失敗的經驗，特別是別人失敗的經驗，因為別人的成功可能我們很難克隆，但是我們可以避免別人錯誤再我們身上重演。
不想當將軍的士兵不是好士兵，但是不想當項目經理的程序員未必是壞的程序員。畢竟對于技術領域來說，程序員的最終發展方向項目經理未必是一個最優秀的方向，程序員可以走的道路有很多，可以往架構師，分析師，資深技術人員，咨詢師等等。路可能有很多條，而且每一條對于人員的能力要求也都不一樣，都有良好的發展機會。所以對于自己能力的判斷和分析，認清自己，給自己合理的定位是直觀重要。讓自己的才華得到發展和認可是今后職業道路上一個關鍵，自己要才盡其用。
作者：Yice(小余)
出處：http://www.yice800.cn

自己一個人獨自回想工作了這么多年，到底給自己留下了什么？如果要給自己找一個答案，或許有兩個會在今后很長一段時間一直影響自己的東西，一個是在工作了這么多年讓自己明白了我們要擔負什么樣的責任，另外一件是工作這么多年給自己的頸椎留下了不小的病癥。一好一壞或許是這么多年的最大收獲。
我們該如何看待責任
時至今日蒙牛老總牛根生說過的那句話還讓我記憶猶新，“有德有才，破格重用；有德無才，培養使用；有才無德，限制錄用；無德無才，堅決不用。”在我認為德的基本就是這個人的責任心和他的態度。無論是軟件行業還是其他的行業，在很多的時候考核一個人是否符合相應的工作崗位，職位技能往往不是最主要的考核標準，而在所有的考核標準中，人的品性和責任態度才是考核的關鍵。
什么人活得最輕松，不負責人的人。丈夫有責任給妻子一個良好的生活環境；父親有責任給孩子一個良好的生長環境；孩子有責任贍養自己的父母；員工有責任做好自己的本職工作；所有的這些都是一些基本的責任。如果一個人富有責任心，生活中的這些責任會讓自己感覺到沉重的壓力，一旦人在這些壓力的之下，要想過的輕松舒服就很困難。所以如果你希望自己過得輕松寫意，你放下一切的責任態度，做個不負任何責任的人，那么或許你會過得比較輕松，但是你也將成為社會中一個不合格的人。
軟件開發本身屬于腦力密集型的勞動，所有的一切都依托于人，軟件行業本身和其它的制造行業有一個本質性的差異，軟件主要依靠人的智慧來進行工作，雖然我們現在看到很多的軟件工程管理書籍，無論是大師的作品，還是坊間口聲相傳的經驗之談，我們都很難解決一個問題，我們很難像制造行業一樣，讓我們每個程序員寫出來的代碼都能夠像機器加工出來的那樣，每一個行代碼都能夠像一個模子印出來的，很難做到整個團隊寫出的代碼像出至一人之手。所以軟件行業的工程管理比其它的工程來說要存在有更大的困難，那么在這些問題困撓之下，整個行業對人的依賴尤為嚴重，對人的依賴程度也就造成對人本身品德和責任心的要求程度相對要高。
在自己工作這么多年來，感覺最輕松的時候還是剛剛畢業的時候，那個時候是初出校門，作為一個新人進入項目組中，對于自己最大的挑戰主要是能不能按時準確的完成自己相應的模塊開發工作。后來開始負責項目之后，雖然也在做編碼開發工作，但是所擔心的和讓自己歡欣的事情和開始已經完全不同。如果你希望自己能夠能夠作為一個合格的項目經理經理，那么你首先需要明確自己的肩上的擔子的分量。在我們的工作中，我們每個人必須承擔工作的各種責任，如果我們缺失這種看待責任的態度，那么工作最后的結果往往將會以失敗告終。
對于自己在這幾年的最大一個一個收獲就是讓自己更明確到責任重于泰山的道理。當然也是這種態度讓自己能夠堅持著把一個一個項目做下去，做好這些項目。如果要對自己做一個評價，或許在技術上我不敢說自己有十足的優勢，但是這些年養成的這種做事情的方法和態度還能值得一提。
在項目中你該承擔什么責任
如果你要問項目組中誰的壓力最大，一般說來應該是項目經理，當然項目經理所拿的工資相對來說也會比較高，責任和壓力本就應該和報酬成正向比例關系。項目經理對下必須對項目團隊成員負責，向上必須對公司負責，同時還需要縱向向客戶負責，所以項目經理經理就像一個傳動軸承，這個項目的運作應該在他驅使之下有效穩定的運轉。
項目經理需要考慮項目的成本因素，所有的公司都是以盈利為主要目的，有時候公司會出于其他的因素和目的，對于項目的盈利并沒有很嚴格的要求，但是項目經理要有成本的概念和意識，要有團隊的總體成本和利潤要有基本的計算方式。同時還需要控制項目的質量和進度，還有些項目還要求有保密意識和其他的相關要求，這些都是項目經理需要向公司負責的地方。
如何組建好一個團隊，如何培養團隊的成員，讓每個團員很夠在一個比較良好的環境中工作和學習，能夠實現每個人的目標和各自的價值觀，把團隊建設成什么樣類型，和項目經理所采取的方法有直接的關系，有些項目團隊組建后團隊人員如走馬燈似的換，有些團隊組建后隊員除了編碼之后就沒有任何的學習機會，如何利用有限的資源和合理的安排，讓團隊的成員都能夠發揮各自的特長，讓每個人都能夠體現自己的價值，有時候需要替項目組的成員去和公司去爭取他們所應該有的福利和報酬，這就是對項目團隊和團隊成員所要承擔的負責。
我們每一個項目最終都將面對我們的客戶，有時候我們的客戶的要求會讓我們很難接受，甚至有時候會讓我們團隊感覺到很惱火，但是作為一個項目經理需要化解這些對項目團隊一個不利的因素，一方面需要避免影響團隊的士氣，另外一方面需要和客戶進行溝通，明確那些要求可行，那些要求不可行，對于不可行的要求需要給一個比較合理的解釋，避免由于后期無法完成對客戶造成欺騙的行為。同時需要控制項目的整體進度和質量，保證項目最終能夠解決客戶的為，這些就是對客戶負責的一個態度。
如何樹立團隊的責任意識
對于項目組中項目盡力所承擔的責任應該說是最大的，無論項目的成敗都和項目經理由直接的關系，所以任何一個項目做項目總結的時候，如果項目成功的話，需要給項目經理記上一功，如果項目失敗的話，不論任何原因，棒子首先需要打在項目經理的身上。項目經理需要對項目的得失成敗負上完全的責任。
在一個項目團隊中，需要有各個不同的角色相互配合才能最終完成項目，需求調研人員，系統分析人員，高級程序員，初級程序員，測試人員，配置管理人員等，雖然項目經理在項目中的責任最大，但是項目中每一個成員都會有相應承擔的責任，或許說著這都是一些工作的職責，開發人員需要按照開發中的各種要求進行開發工作，測試人員需要按照測試的要求準備測試文檔和數據等，所有的角色都會有各自的工作內容，在實際工作中我們是每一個角色協作來完成項目，有時候由于項目的規模偏小，有些人可能會同時充當多個角色，比如說高級程序員有時候需要同時兼顧系統分析人員，項目經理有時候還需要兼顧測試等等。但是不論規模的大小，項目經理需要非常清晰的意思到每個角色的工作職責，在項目分工中對各種工作要比較清晰，合理化安排。同時也需要讓每個工作的人員清楚的知道自己的工作要求和檢驗的方式，避免含糊性的安排，做到責任清晰。
明確責任的首要是明確工作內容，對于團隊成員中需要做到責任均衡，盡量避免能者多勞的問題，工作中進行工作安排時往往容易把工作重點都落到部分能力較強的人員上，這種安排比較容易造成工作天平的傾斜，一旦傾斜的嚴重，這部分開發人員就比較容易造成由于精力不足造成質量問題。所以項目經理在安排工作中需要有個權衡，如果說存在人員能力不均衡問題，那么在工作安排的時候，需要盡可能抽取重復性的工作，讓能力欠缺的人員做這部分工作，同時需要協調他們學習，也需要明確學習的目標和結果。
對于團隊中我們需要樹立一個責任意識，同時需要有合作精神，在項目開發中整個團隊需要彼此合作，有時候一個人的問題有時候會影響到整個團隊的質量和進度。我們最終給客戶交付的是一個完整的程序，其中任何一個部分出了問題，客戶對整個產品的評價都會因此而改觀，客戶不會說那個模塊怎么怎么樣，而是說你這個程序怎么怎么樣，這就代表說是一個整體的結果，所以項目經理需要在團隊中樹立起這種整體的責任意識，避免團隊中出現個人自管門前雪，不理他人瓦上霜的現象。
你能承受多大責任
你有沒有評價過你的項目經理，你有沒有對你的項目經理感到無奈和氣氛，如果你希望自己能夠往項目經理方向發展，在我看來你首先需要考慮的不是你的技術背景，你的管理經驗是不是足夠，首先要考慮的是你是不是有能夠承受那些責任的心態。如果你是項目經理的話，那么你負責管理的團隊無論人員多少，他們需要在你的協調下工作，那么你肩上擔負的就是那些人的工作結果和評定，還有來自公司的各種壓力和考核。這些比單純寫代碼要勞心許多。
影響項目成敗的因素有很多，但是如果說項目經理缺少責任心，我可以說項目必敗無疑。正是因為這樣，我才會在此一再強調責任心的問題。
作者：Yice(小余)
出處：http://www.yice800.cn

如果你愛他，那么讓他去當項目經理，因為那里會是他事業的天堂；如果你狠他，送他去當項目經理，因為那將是他的地獄。
軟 件開發工作應該屬于分工比較明確的行業，每一個項目的啟動，調研，開發，測試，部署，用戶培訓和后期維護等一系列的過程都有不同的角色參與其中。在這一系 列的角色中項目經理是最直接的管理者，無疑顯得格外的突出和重要。軟件項目開發的成功率本身就不高，在眾多的失敗過程中，由于項目經理在管理上存在的問題 造成項目無法按時交納，質量不高甚至失敗的例子在我看來數不勝數。雖然項目經理的能力并不是項目失敗的直接原因，因為影響項目成敗的因素有很多，但是如果 一個合格的項目經理，對于項目的整個開發過程來說，如何利用他的經驗和能力來有效合理的管理項目進度，從而避免很多無謂的失誤，在項目的最終成敗中還是占 有關鍵作用。
對 于很多從事軟件開發的人來說，項目經理是他們事業上追求的目標，從初出校園的小牛犢，從最低級的學徒似的初級開發人員，再不斷的努力和學習，慢慢得爬到有 經驗的中級程序員，再后來到高級程序員，到后來的大牛人才，慢慢開始帶領新人，開始接觸項目管理上的工作。我想很多人的軌跡都是這么一步一步的過來。在整 個過程中我們彼此都在學習，關于很多的技術方面的知識可以通過網絡和書籍進行學習。但是如何做一名項目經理，如何做好一名項目經理，倒缺乏一個系統的學習 框架，包括我自己在內，也是跟隨前人身邊學習，自己觀察，在一次次錯誤后進行反思后才有所進步。這個話題的文章我考慮了很久后才決定要寫出來，在一系列的 文章中結合我自己的項目和我自己身邊的項目，希望能夠將這些經驗與大伙分享，通過討論，彼此共勉。機會往往是給有所準備的人，不論你現在是否是充當項目經 理的角色，但是如果你有所準備，我想對于你來說機會只是遲早的事情。
項目從規模來說，可以劃分微型項目，小型項目，中型項目和大項目，當然還有超大型的項目，對于工數在一人/月（一個中級程序員開發一個月，總計21個工作日）的項目定為微型項目；對于工數在1人/月到10人/月之間的規模稱為小型項目；對于工數在10人/月到100人/月之間的規模稱為中型項目；如果超過 100人/月的項目稱為大型項目；對于我們所討論的項目管理中，對于超過1000人/月的項目不做討論，因為一般的公司來說，還是比較少能夠遇到中規模的項目。
如 果從類型來說可以簡單的劃分為產品開發和項目開發，產品的開發一般會有后續定期的產品升級性開發，項目的開發時間跨度也會比較長，對于項目的開發來說，一 般是指為了滿足某一特定客戶而開發的軟件，其開發周期往往會比較緊張，后續的開發主要是針對客戶的新功能追加，這種項目的開發往往會劃分為幾個階段分步進 行。
如果從合作方式上也可以劃分為自主研發和外包開發，甚至還有部分項目使用外駐人員進行項目開發，有時候開發還受到地域性的影響，兩地，三地合作開發，國內國外的合作開發，還有甚至多國之間的合作開發。
不 同的項目開發方式都會有不同的問題出現，比如說小型項目和大型項目的人員配備上就不可能一樣，外包開發和自主研發的項目計劃也不一樣，跨地域的合作上的時 間差異和人員的溝通和本公司內部背靠背的模式也不一樣。項目中實際可能發生的事情千奇百怪，這些問題絕大部分都需要項目經理來過問，分析和決策。所以說項 目經理或許對于很多人來說將會是地獄，一旦深陷其中，很難有苦盡甘來的那一天。但是如果方法得當，管理手段有效，能夠合理的規避風險呢？那你將會感到項目 中的一切對你來說游刃有余，團隊中每個人也都能相應發揮自己的特長，也都能從中找到各自的成就感。
生與死只在一線間，好和壞也是如此。希望能夠從項目經理的角度來看看項目實際過程中我們會遇到哪些問題，該如何去處理這些問題，通過著一些列的文章能讓你對項目的整體過程有更全面的了解，同時也能夠讓你更清楚項目經理的日常工作和行為職責。
作者：Yice(小余)
出處：http://www.yice800.cn

作者：Michael Howard
原文出處：Strsafe.h: Safer String Handling in C

　　在微軟公司舉行的Microsoft Windows Security Push 活動期間，一批測試者、程序管理經理和普通程序員共同決定要為 C 語言量身定制一套具有較高安全性的字符串處理函數，并且希望這些函數能被 Windows 程序員和微軟公司內部的程序員所采用。
簡單說來，現有的 C 語言運行時函數實在難以在當今充斥著惡意攻擊企圖的大環境下立足。這些函數要么在返回值和參數上缺乏一致性，要么隱含著所謂的“截斷誤差”(truncation errors) 錯誤，要么無法提供足夠強大的功能。坦言之，調用這些函數的代碼太容易產生“內存溢出”問題了。
　　我們發現，面向 C++ 程序員的類足以應付各種安全處理字符串的編程需要；他們能夠選擇 MFC 的Cstring 類、ATL 的CComBSTR 類 或者STL 的string 類，等等。然而，經典的 C 語言程序仍然普遍地存在，何況許多人正在把 C++ 當作 “改良的 C 語言” 來用，卻把豐富的 C++ 類束之高閣。
　　其實只需要添加一行代碼，你就能在 C 語言代碼中調用安全性良好的 strsafe 系列函數了，詳細請參閱：
《Using the Strsafe.h Functions》
這些新函數包含在一個頭文件和一個函數庫(可選)中，而后兩者能在新版的 Platform SDK 中找到。對，就這么簡單：

#include "strsafe.h"

還等什么呢！
再強調一次，對 strsafe 函數庫的引用是可選的。
為了實現 strsafe 系列函數的目標，你的代碼必須滿足下列條件：

• 始終以 NULL 字符結束字符串。
• 始終檢測目標緩沖區的長度。
• 始終用 HRESULT 語句產生統一的返回值。
• 兼顧 32 位與 64 位兩種運行環境。
• 具有靈活性。

　　我們覺得，缺乏統一性是導致現有許多 C 語言字符串處理函數容易產生安全漏洞的根本原因，而 strsafe 系列函數所帶來的高度統一性恰恰是解決此問題的一劑良藥。然而，strsafe 也不是萬能藥。單純依靠 strsafe 系列函數并不能保證代碼的安全性和堅固性——你還必須開動你的大腦才行——然而這樣對解決問題還是大有幫助的！
下面給出一段采用經典 C 語言運行時間函數的代碼：

void UnsafeFunc(LPTSTR szPath,DWORD cchPath) {
	TCHAR szCWD[MAX_PATH];

	GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD);
	strncpy(szPath, szCWD, cchPath);
	strncat(szPath, TEXT("\\"), cchPath);
	strncat(szPath, TEXT("desktop.ini"),cchPath);
}

　　以上代碼中的 bug 隨處可見 —— 它沒有檢查任何一個返回值，而且在對 strncat 函數的調用中也沒有正確地使用 cchPath (因為MAX_PATH 中保存的是目標緩沖區內剩余空間的長度，而不是目標緩沖區的總長度)。于是，“內存溢出” 問題將會快找上門來。然而，象這樣的代碼片段早已泛濫成災了。如果改用 strsafe 系列函數，那么以上代碼應該變成：

bool SaferFunc(LPTSTR szPath,DWORD cchPath) {
	TCHAR szCWD[MAX_PATH];

	if (GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD) &&
			SUCCEEDED(StringCchCopy(szPath, cchPath, szCWD)) &&
			SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("\\"))) &&
			SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("desktop.ini")))) {

			return true;
	}

	return false;
}						

• 獲取目標緩沖區的當前指針。
• 獲取目標緩沖區的剩余空間長度。
• 以某個特定字符填充空閑緩沖區。
• 一旦字符串處理函數失敗，就把用特定值填充字符串。
• 一旦字符串處理函數失敗，就把目標緩沖區設成 NULL 。

　　如此改進后的代碼性能又如何呢？告訴你一個好消息：它與原先的代碼在性能上幾乎沒有差別。我曾在自己的 1.8 GHz 電腦上測試過混用經典 C 語言中各種字符串連接函數的代碼、混用 strsafe 系列中各種字符串連接函數的代碼和混用 Ex 版本 strsafe 系列中各種字符串連接函數的代碼。它們各自獨立運行一百萬次(沒錯，就是 10,000,000 次)所消耗的時間分別為：

• 經典 C 語言 —— 7.3 秒
• Strsafe 系列—— 8.3 秒
• Strsafe 系列 (Ex 版) —— 11.1 秒

在測試中，調用 Ex 版本的 strsafe 系列函數的程序會在調用失敗時把緩沖區設為 NULL ，并以 0xFE 作為填充字節，代碼如下：

DWORD dwFlags = STRSAFE_NULL_ON_FAILURE | STRSAFE_FILL_BYTE(0xFE);

　　其中設置填充字節的代碼耗時較多。事實上，如果這里僅僅把緩沖區設置為 NULL 的話，則采用 Ex 版本的 strsafe 系列函數的代碼將會與采用普通的 strsafe 系列函數的代碼耗時相同。
　　由此可見，以上三種方案的性能差異極小。我相信你也不會經常在一個程序中數百萬次地反復執行包含大量字符串處理函數的代碼吧！
還有一點值得引起注意：當你引用 strsafe 系列函數時，原有的 C 語言字符串處理函數都將被自動進行 #undef 處理。這也沒問題，因為調試過程中的出錯信息將會告訴你哪些函數已經被相應的 strsafe 系列函數取代了。好了，請放心地使用 strsafe.h 吧！更多相關信息請參閱 《Using the Strsafe.h Functions》。

算法的力量
算法是計算機科學領域最重要的基石之一，但卻受到了國內一些程序員的冷落。許多學生看到一些公司在招聘時要求的編程語言五花八門，就產生了一種誤解，認為 學計算機就是學各種編程語言，或者認為，學習最新的語言、技術、標準就是最好的鋪路方法。其實，大家被這些公司誤導了。編程語言雖然該學，但是學習計算機 算法和理論更重要，因為計算機語言和開發平臺日新月異，但萬變不離其宗的是那些算法和理論，例如數據結構、算法、編譯原理、計算機體系結構、關系型數據庫 原理等等。在“開復學生網”上，有位同學生動地把這些基礎課程比擬為“內功”，把新的語言、技術、標準比擬為“外功”。整天趕時髦的人最后只懂得招式，沒 有功力，是不可能成為高手的。
算法與我
當我在1980年轉入計算機科學系時，還沒有多少人的專業方向是計算機科學。有許多其他系的人嘲笑我們說：“知道為什么只有你們系要加一個‘科學’，而沒 有‘物理科學系’或‘化學科學系’嗎？因為人家是真的科學,不需要畫蛇添足，而你們自己心虛，生怕不‘科學’，才這樣欲蓋彌彰。” 其實，這點他們徹底弄 錯了。真正學懂計算機的人（不只是“編程匠”）都對數學有相當的造詣，既能用科學家的嚴謹思維來求證，也能用工程師的務實手段來解決問題——而這種思維和 手段的最佳演繹就是“算法”。
記得我讀博時寫的Othello對弈軟件獲得了世界冠軍。當時，得第二名的人認為我是靠僥幸才打贏他，不服氣地問我的程序平均每秒能搜索多少步棋，當他發 現我的軟件在搜索效率上比他快60多倍時，才徹底服輸。為什么在同樣的機器上，我可以多做60倍的工作呢？這是因為我用了一個最新的算法，能夠把一個指數 函數轉換成四個近似的表，只要用常數時間就可得到近似的答案。在這個例子中，是否用對算法才是能否贏得世界冠軍的關鍵。
還記得1988年貝爾實驗室副總裁親自來訪問我的學校，目的就是為了想了解為什么他們的語音識別系統比我開發的慢幾十倍，而且，在擴大至大詞匯系統后，速 度差異更有幾百倍之多。他們雖然買了幾臺超級計算機，勉強讓系統跑了起來，但這么貴的計算資源讓他們的產品部門很反感，因為“昂貴”的技術是沒有應用前景 的。在與他們探討的過程中，我驚訝地發現一個O(n*m)的動態規劃（dynamic programming）居然被他們做成了O(n*n*m)。更驚 訝的是，他們還為此發表了不少文章，甚至為自己的算法起了一個很特別的名字，并將算法提名到一個科學會議里，希望能得到大獎。當時，貝爾實驗室的研究員當 然絕頂聰明，但他們全都是學數學、物理或電機出身，從未學過計算機科學或算法，才犯了這么基本的錯誤。我想那些人以后再也不會嘲笑學計算機科學的人了吧!
網絡時代的算法
有人也許會說：“今天計算機這么快，算法還重要嗎?”其實永遠不會有太快的計算機，因為我們總會想出新的應用。雖然在摩爾定律的作用下，計算機的計算能力 每年都在飛快增長，價格也在不斷下降。可我們不要忘記，需要處理的信息量更是呈指數級的增長。現在每人每天都會創造出大量數據（照片，視頻，語音，文本等 等）。日益先進的記錄和存儲手段使我們每個人的信息量都在爆炸式的增長。互聯網的信息流量和日志容量也在飛快增長。在科學研究方面，隨著研究手段的進步， 數據量更是達到了前所未有的程度。無論是三維圖形、海量數據處理、機器學習、語音識別，都需要極大的計算量。在網絡時代，越來越多的挑戰需要靠卓越的算法 來解決。
再舉另一個網絡時代的例子。在互聯網和手機搜索上，如果要找附近的咖啡店，那么搜索引擎該怎么處理這個請求呢?
最簡單的辦法就是把整個城市的咖啡館都找出來,然后計算出它們的所在位置與你之間的距離,再進行排序,然后返回最近的結果。但該如何計算距離呢？圖論里有不少算法可以解決這個問題。
這么做也許是最直觀的，但絕對不是最迅速的。如果一個城市只有為數不多的咖啡館,那這么做應該沒什么問題,反正計算量不大。但如果一個城市里有很多咖啡館,又有很多用戶都需要類似的搜索,那么服務器所承受的壓力就大多了。在這種情況下,我們該怎樣優化算法呢?
首先，我們可以把整個城市的咖啡館做一次“預處理”。比如，把一個城市分成若干個“格子(grid)”,然后根據用戶所在的位置把他放到某一個格子里，只對格子里的咖啡館進行距離排序。
問題又來了，如果格子大小一樣，那么絕大多數結果都可能出現在市中心的一個格子里，而郊區的格子里只有極少的結果。在這種情況下，我們應該把市中心多分出 幾個格子。更進一步，格子應該是一個“樹結構”，最頂層是一個大格——整個城市，然后逐層下降，格子越來越小，這樣有利于用戶進行精確搜索——如果在最底 層的格子里搜索結果不多，用戶可以逐級上升，放大搜索范圍。
上述算法對咖啡館的例子很實用，但是它具有通用性嗎？答案是否定的。把咖啡館抽象一下，它是一個“點”，如果要搜索一個“面”該怎么辦呢？比如，用戶想去 一個水庫玩，而一個水庫有好幾個入口，那么哪一個離用戶最近呢？這個時候，上述“樹結構”就要改成“r-tree”,因為樹中間的每一個節點都是一個范 圍，一個有邊界的范圍（參考：http://www.cs.umd.edu/~hjs/rtrees/index.html）。
通過這個小例子，我們看到，應用程序的要求千變萬化，很多時候需要把一個復雜的問題分解成若干簡單的小問題，然后再選用合適的算法和數據結構。
并行算法：Google的核心優勢
上面的例子在Google里就要算是小case了！每天Google的網站要處理十億個以上的搜索，GMail要儲存幾千萬用戶的2G郵箱， Google Earth要讓數十萬用戶同時在整個地球上遨游，并將合適的圖片經過互聯網提交給每個用戶。如果沒有好的算法，這些應用都無法成為現實。
在這些的應用中，哪怕是最基本的問題都會給傳統的計算帶來很大的挑戰。例如，每天都有十億以上的用戶訪問Google的網站，使用Google的服務，也 產生很多很多的日志（Log）。因為Log每分每秒都在飛速增加，我們必須有聰明的辦法來進行處理。我曾經在面試中問過關于如何對log進行一些分析處理 的問題，有很多面試者的回答雖然在邏輯上正確，但在實際應用中是幾乎不可行的。按照他們的算法，即便用上幾萬臺機器，我們的處理速度都跟不上數據產生的速 度。
那么Google是如何解決這些問題的呢？
首先，在網絡時代，就算有最好的算法，也要能在并行計算的環境下執行。在Google的數據中心，我們使用的是超大的并行計算機。但傳統的并行算法運行 時，效率會在增加機器數量后迅速降低，也就是說，十臺機器如果有五倍的效果，增加到一千臺時也許就只有幾十倍的效果。這種事倍功半的代價是沒有哪家公司可 以負擔得起的。而且，在許多并行算法中，只要一個結點犯錯誤，所有計算都會前功盡棄。
那么Google是如何開發出既有效率又能容錯的并行計算的呢？
Google最資深的計算機科學家Jeff Dean認識到， Google 所需的絕大部分數據處理都可以歸結為一個簡單的并行算法： Map and Reduce（http://labs.google.com/papers/mapreduce.html）。 這個算法能夠在很多種 計算中達到相當高的效率，而且是可擴展的（也就是說，一千臺機器就算不能達到一千倍的效果，至少也可以達到幾百倍的效果）。Map and Reduce 的另外一大特色是它可以利用大批廉價的機器組成功能強大的server farm。最后，它的容錯性能異常出色，就算一個server farm里面的機 器down掉一半，整個farm依然能夠運行。正是因為這個天才的認識,才有了Map and Reduce算法。借助該算法，Google幾乎能無限地 增加計算量，與日新月異的互聯網應用一同成長。
算法并不局限于計算機和網絡
舉一個計算機領域外的例子：在高能物理研究方面，很多實驗每秒鐘都產生幾個TB的數據量。但因為處理能力和存儲能力的不足，科學家不得不把絕大部分未經處 理的數據丟棄掉。可大家要知道，新元素的信息很有可能就藏在我們來不及處理的數據里面。同樣的，在其他任何領域里，算法都可以改變人類的生活。例如人類基 因的研究，就可能因為算法而發明新的醫療方式。在國家安全領域，有效的算法可能避免下一個911的發生。在氣象方面，算法可以更好地預測未來天災的發生， 以拯救生命。
所以，如果你把計算機的發展放到應用和數據飛速增長的大環境下，你一定會發現，算法的重要性不是在日益減小，而是在日益加強。
給程序員的七個建議
（1）練內功。不要只花功夫學習各種流行的編程語言和工具，以及某些公司招聘廣告上要求的科目。要把數據結構、算法、數據庫、操作系統原理、計算機體系結 構、計算機網絡，離散數學等基礎課程學好。大家不妨試試高德納所著The Art of Computer Programming里的題目，如果你能夠 解決其中的大部分題目，就說明你在算法方面有一定的功力了。
（2）多實戰。通過編程的實戰積累經驗、鞏固知識。很多中國大學畢業生缺乏編程和調試經驗；學習C語言，考試過關就算學會了；課題項目中，只要程序能夠編 譯，運行，并且輸入輸出滿足要求就算了事。這些做法是不行的。寫程序的時候，大家必須多想想如何把程序寫得更加精煉、高效、高質量。建議大家爭取在大學四 年中積累編寫十萬行代碼的經驗。我們必須明白的是：好程序員是寫出來的，不是學出來的。
（3）求實干。不要輕視任何實際工作，比如一些看似簡單的編碼或測試。要不懈追求對細節一絲不茍的實干作風與敬業精神。我發現不少程序員對于知識的掌握很 膚淺，不求甚解，沒有好奇心，不會刨根問底。比如，學會了C++，是否了解一個對象在編譯后，在匯編代碼中是如何被初始化的？這個對象的各個成員在內存中 是如何存放的？當一個成員函數被調用時，編譯器在匯編代碼中加入了哪些額外的動作？虛函數的調用是如何實現的? 這些東西恐怕在編程語言或編譯原理中都沒 有詳細提到，只有通過踏實的實干才能真正掌握。
（4）重視數學學習。數學是思維的體操，數學無處不在。學計算機至少要學習離散數學、概率論、布爾代數、集合論和數理邏輯。這些知識并不難，但是對你未來 的工作幫助會很大。 尤其當你對一些“數學密集型”的領域如視頻、圖像處理等有興趣時，這些知識將成為你手中的利器。
（5）培養團隊精神，學會與人合作。今天的軟件工程早已經不是一個人可以單獨操作的，而必須靠團隊合作才能成功。不懂得合作的人是不能成大器的。大家要多去尋找可以與人一起做項目的機會。
（6）激勵創新意識，培養好奇心，不要死記硬背。沒有掌握某種算法技術的根本原理，就不會有應變和創新的能力。想成為一位好程序員（其實從事任何一個行業 都是如此），重要的是要養成鉆研，好奇，創新，動手，合作的優秀習慣，不滿足于填鴨，不滿足于考試交差，不滿足于表象。這不是學幾門課能夠一蹴而就的。
（7）有策略地“打工”。在不影響學業的前提下，尋找真正有意義的暑期工作或兼職。去找一個重視技術的公司，在一個好的“老板”指導下完成真正會被用戶使 用的程序。不要急于去一個要你做“頭”而獨擋一面的地方，因為向別人學習才是你的目的。找工作也是一樣，不要只看待遇和職銜，要挑一個你能夠學習的環境， 一個愿意培養員工的企業，一個重視你的專業的公司。最后，還要挑一個好老板。
希望大家都能把握機會，養成好的學習習慣，把算法學精學透；希望大家都能有一個美好的未來！