C1G军火库

via Tsung’s Blog

从 Tsung’s Blog 上看到这篇东西，发现里面的一些格言实在太经典、太贴切了！我觉得这个应该是和技术相关的，贴在这里，估计有共鸣的人应该很多。:)

先摘录几个经典的（做了小幅修改，替换了一些繁体术语）：

要殺一個程式設計師不需要刀，改三次需求就好

程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工期實現這樣的需求。
修改需求是對奇蹟吐槽的亵渎行為。
而追加修改則是相信奇蹟還會重現的無謀行動。

追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。

原文出处：程式設計師的格言 « but, or bug
——————————————————————————

程式設計師的格言（盜作不少）

譯自

* プログラマーの格言（盗作多し）
* http://mixi.jp/view_community.pl?id=1772737

(版本2 2008/10/12更新)

譯註

* SE是日本軟體公司裡程式設計師的頭子。自己不太寫程式，主要工作是跟客戶確認規格。
* 程式設計師多半自己不面對客戶。
* 跟PM又不一樣。（有什麼比較貼切的職稱翻譯嗎？）

1. 每天有24小時。
所謂的「今天之內」，是指到明天早上為止。
2. 程式不會照自己所想的跑。只會照所寫的跑。
3. 需求規格在程式寫完後才會敲定。
基本規格要客戶看到成品後才會決定。
詳細規格要使用者用過後才會確定。
4. 我對軟體設計的方式導出的結論，有兩種方式。
一是把軟體設計得單純到很明顯不會有缺陷，
不然就是把軟體設計得複雜到沒有明顯的缺陷。
- C.A.R.Hoare
5. 程式碼不要在開發現場寫！ 去客戶那寫！
除錯不要在期限前做！ 上線後再做！
6. 畫面是藍色的！
(國際太空站太空人重新安裝 Windows NT，日誌中的名句)
7. 先說「沒辦法」的人贏。
8. 有意見的話你寫
9. 要殺一個程式設計師不需要刀，改三次規格就好
10. 首先要先懷疑別人，被懷疑的人或許會把問題解決掉。
（註：通常會「先懷疑自己」）
11. 開發沒有終點。只有釋出(release)。
12. 無論規格多晚才能確定，結案期限永遠不會變。
這是所謂的「期限守恆定理」。
13. 客戶總是覺得水跟追加需求是不用錢的。
14. 付錢愈計較的客人愈囉唆。
15. 在排定開發行程時，總是視而不見一些連小學生都會的算數。
業務部門總是一堆不知道1+1=2的人。
16. 一個人掛了大家都掛了。
17. bug過了一晚可能就變成規格了。
18. 好的規格找一個天才不如找三個凡人。
爛的規格找一百個凡人不如找一個天才。
19. 客製軟體中30%的價格用在確認規格上。
30%用在修改規格上。
30%用在找bug。
結果初期規格反映在價格上占的比例只有10%。
20. 對客戶來說SE是部下，程式設計師是家畜。
對SE來說客人是錢，對程式設計師來說顧客是看不見的病毒。
除了弄完程式以外，沒有其他驅除的辦法。
21. 顧客想受SE喜歡，要自己了解到系統開發需要時間與金錢，早點確定規格。
SE想受顧客喜歡，則要讓程式設計師討厭自己。
22. 很多SE跟程式設計師都暗自想著有錢有閒的話什麼系統都想自己動手做，
不過都沒這種機會。
23. 品質的劣化程度依規格改變的次數與規模而定。
24. 業務是認為空想能夠實現的夢想家。
SE則是深信任何障礙都能突破的冒險家。
程式設計師則是被夢想家和冒險家拋到漆黑海裡的漂流者。
25. 有才能的程式設計師第一次看到設計細節時，要先理解程式的目的。
接下來要設法讓SE了解到以指定的方法、工時並無法完成這個工作。
26. 程式是運氣與直覺堆砌而成的奇蹟。
若不具備這兩者，不可能以這樣的工時實現這樣的規格。
修改規格是對奇蹟吐槽的褻瀆行為。
而追加修改則是相信奇蹟還會重現的無謀行動。
27. 程式設計師聽了「把自己當作顧客去著想！」而開始思考。
啊，像夢一樣。
28. 對於因為興趣而寫程式的人來說，所謂的技術是程式語言能力。
對於因為工作而寫程式的人來說，所謂的技術是邏輯思考能力與人際溝通能力。
程式語言可以看著手冊溝通，客戶不行。
29. 程式系統在交貨之前會不斷縮小。
先用元件定義取悅老闆。
再拿經費概算要部長妥協現實的方案。
在運用會議中，課長會嘗識減少自己責任範圍。
在細節會議中，負責人會把範圍縮到自己記得的部分。
30. SE需要持久力，程式設計師需要爆發力。
31. 準時離開公司，工作會變多。
32. 完美的程式需要完美的時間與金錢。
聽說揮霍著美國的國家預算的NASA，也覺得時間跟錢不夠。
33. 詳細設計要在程式碼的註解裡做完。
註解是唯一的自衛手段，至少要讓自己看懂。
34. 還有時間看程式碼的話就執行他。
CPU跑得比腦細胞快。至少這時候可以休息。
35. 程式的異常該稱為「bug」還是「規格上的限制」是看期限還剩多久決定的。
36. 所謂便服日，好像社會上把他叫做假日
(註) 日本有些公司會有所謂便服日（不用穿西裝的日子），通常是星期五，但…
37. 地獄持續一段時間後，充滿殺氣的怒吼會變多。
再持續一段時間，說話會變少但牢騷會變多，壟罩在凝重的氣氛裡。
再持續下去，反而會海闊天空，四周洋溢充滿活力的聲音。
這種狀態稱為「Programmer’s High」，也是倒下來的人開始出現的時候。
38. 遠處的火災一定燒到這裡。
39. 禱告，然後 “工作” 吧。(修道院的標語)
40. 程式不是用腦記的，要用身體記住。
41. 明天能放假的話死了也罷。
42. 外面有下雨耶，昨天開始下的嗎？
43. 心若不廢掉(消極)，身體會廢掉。
若不讓自己殘忍，自己會被殺。
44. 客戶會說謊，業務會作夢，SE會做白日夢。
程式設計師則惦惦。（愈來愈自言自語）
45. SE總是不講理的(unreasonable)說「沒有辦不到(impossible)」，
業務總是沒辦法(impossible)說「沒道理(unreasonable)」。
46. 規格書就像航海圖，客戶則是洋流。洋流陰晴不定，航海圖就變垃圾。
程式設計師必須在沒有航海圖的海上憑自己的力量找到大陸。
47. 再嘮嘮叨叨下去也是要付錢的。
48. 多想個10秒鐘，你可以不說「嗯，這個做得到」。
49. 人是無法從別人失敗記取教訓的動物。
砍成本、改規格、加需求、趕上線，從來沒有人從眾多失敗中記取教訓。
50. 老手用來提振精神的魔法格言：
「不過比起以前來說算是…」
新人用來提起幹勁的魔法格言：
「把這件工作做完的話…」他們還不知道工作是沒有終點的。
51. 所謂交案期限，是指開發現場從公司換到客戶那裡的日子。
52. 程式、SE、經理不是職種。是職責。
53. 業務是最難搞的客戶。
54. 能夠迅速想到解法的程式設計師太多了。
他們能用一分鐘想到方法，用一天去寫程式。
不需要花一小時想到解法，再用一小時去寫程式。
- Jon Bentley
55. 漂亮的規格，可以從沒有bug出現看出來。
明明爛的就是設計，為什麼是這樣…
56. 上線後的除錯才叫做bug。
57. 追加需求確定後交貨期限就無法確定，
交貨期限確定後追加需求就無法確定。
這稱為「追加需求與交貨期限的測不準原理」。
58. 除三個錯就會冒出一個錯。
這稱為bug的無窮迴圈。
59. 不祥的預感總會實現。
不過程式設計師不會去煩惱不祥的預感，那是SE的工作。
60. 要解決地獄的辦法，就是客戶把錢交出來。
61. 不懂電腦的操作者是發現bug的天才。而且無法重現。
62. 每次開會就更改規格的客戶，
他的操作手冊要等到操作寫好的程式後才能寫出來。
63. 搞不懂的時候，Currency（長整數）比Interger（整數）好用。
Variant（字串、數字都能存的萬能變數）又比Currency（長整數）好用。
安全第一。
（VB程式設計師如是說）
64. 啊，那是微軟的規格。
65. 程式設計師所不滿的規格也一定會讓客戶不滿。
（這是說程式設計師覺得難寫的地方常常是SE溝通有落差）
66. 程式設計師需要的技能，
包括交涉、時程管理、業務分析、提案、設計、程式語言、架構、維護、使用。
SE需要的技能則減掉程式語言、架構、維護與使用。
專案經理需要的能力則再減掉業務分析、提案與設計。
業務需要的能力再扣掉時程管理。
67. 正因為健康，才能做不健康的事。
68. (這個不是 bug 嗎？)
規、規格、是規格啦。不過有一點跟規格不太一樣啦。
69. 那是你說的規格。
70. 開發室沒有窗戶，那是因為以前…
71. 即使爛了也是規格。
72. SE: 真沒辦法。
PG: 也沒註解。
（碰到不知道是誰寫的程式，大家都束手無策的狀態）
73. 為什麼你不能兩三下解決掉他啦。
因為之前兩三下搞定的東西也被你兩三下就否定了。
74. 不會動的bug就只是普通的bug。（會動的bug則能視為規格）
75. 今天好好清理bug，bug應該死光了吧。
咦？Windows也死了唷。
76. 客戶不會去想最壞的情況。要他面對最壞的情況，他會認為是漫天開價。
SE則會顧慮最壞的情況，準備應付最壞的情況。
程式設計師比誰都早預料到最壞的情況，而無視最壞的情況。
77. 唯一不產生bug的方法，就是不寫程式。
第二好的方法，就是在時程跟人員確定之後的每次改規格，都重新檢視過整個專案。
78. 共同責任是程式設計師的責任。
管理職？那是啥？好吃嗎？我沒吃過耶。
79. 如果可以改行的話，想找個準時下班不叫「逃跑」的工作。
80. 對職業程式設計師來說，漂亮的程式是單純而自然的邏輯、簡單而基本的指令、豐富的註解，
也就是新手程式設計師也能馬上動手改的程式。
而要寫出這樣的程式，需要單純、簡單、美麗的規格。
但可惜客人總是喜歡搞很複雜。
81. 設計者應該是不該要求製作者製作出超過設計以上內容的吧…
82. 無論是做的比規格書裡的多，還是只照規格書裡的寫，SE都會找程式設計師的碴。
所以程式設計師只做規格書裡的寫的內容。
83. SE對程式設計師說的「常識」每三小時變一次。
84. 自己看規格書。不能跑的是規格。
85. 「沒辦法」是要看把一天當多少小時來算。
一天常常指的是3人日，一個月常常是指4.5人月喔。
86. 工時要減掉一半的單體測試與一半的系統測試，
而交貨期則要另外加上上線後的兩個月。
87. 能拿到錢的規格變更稱為「受理項目」，
拿不到錢的規格變更則稱為「SE的規格確認失誤」。
程式設計師是這麼看的。
88. 累了。我想睡了。可以回家嗎。
（累了吧，我也累了。好累喔怎麼了。反正就是規格啦，管他的）
89. 試圖降低成本的話，為了配合預算，品質會下降，不過漫天開價做出來的品質也不見得好到哪裡去。
90. REDO到底該怎麼唸一直搞不懂。是利斗嗎、李度嗎、R E D O嗎，難道是 red 零 嗎？ 拜託加上注音吧。
（譯註：我比較煩惱 Linux）
91. 有人在程式碼註解裡寫日記。像「今天是雨天…」，「想回家…」之類的。甚至還有「修改日: 2003/10/10 不能同意你更多」這種註解出現。說到這個，好像也看過「吃大便」這樣的註解。
92. 小學生時第一次看到電腦
國中時第一次學會怎麼用
高中與大學學會程式語言
出社會後才發現自己走錯路
93. 「不要讓老闆當業務比較好」
94. 說來說去，要去研究根本不知道為什麼會動的東西為什麼不會動了，找拿破崙來也沒搞頭。

ex 系列

1. 就算程式裡沒bug，編譯器會有bug。
就算編譯器沒bug，OS會有bug。
就算一切都沒bug，客戶會決定什麼是bug。
2. 規格與規格書是不同的東西。
3. 比期限更重要的是靈感與睡眠。
4. 比知識與經驗重要的是手冊與時間。
5. 能動就好了，能動的話…
6. 過了三天就是別人寫的程式碼。
7. (大搜查線系列)
規格變動不是在會議室裡發生的！是在現場發生的！
8. (大搜查線系列)
異常不是在模擬測試時發生的！是上線後才會發生的！
9. 漂亮的設計三天或許就膩了
骯髒的設計三天就習慣了
10. bug與規格是一體兩面
11. 電腦裡沒有bug，bug常在人心。
12. 無論怎麼檢查，不管怎麼確認，上線前一晚就是睡不著。(RFC968)
13. 估價需要1%的經驗與99%的直覺
14. 沒有什麼事情比直接讓找不到任何bug的程式直接上線還要可怕的了。
15.
* 『程式設計師』＝能將SE條理不通的說明翻譯成程式碼的高手
* 『SE』＝與客戶討論改寫規格書、與程式設計師討論後再改寫規格書，程式出貨後還要繼續改寫規格書的人
* 『PM』＝每天修改自己定下的行程表的人
* 『業界老鳥』＝臉色蒼白缺乏表情的人
* 『外包』＝幫不會寫程式的正職員工寫程式的人
* 『coding』＝複製貼上的工作
* 『單體測試』＝指開始寫程式
* 『除錯』＝把程式碼註解掉的工作
* 『新同事』＝在火燒屁股的專案火上加油的人
* 『出貨日』＝把只完成一半的系統上線的日子
* 『末班電車』＝業界平均的下班時間
* 『颱風假』＝一年一度可以準時下班的業界假日
16. 當誰寫的程式碼跑出bug時，那個人大概都不在了（墨菲定理？）
17. 最終手段
「重開機」
意外的常常都很有效
18. 最強藉口
以前「那是硬體的極限」
現在「那是Windows的規格」
19. 「程式碼的可信度，不會比寫的人還可信。」

使用通过文件名index.php、INDEX.php来区分，windows是不区分大小写的。

一、匈牙利命名法：广泛应用于象Microsoft Windows这样的环境中。

      Windows 编程中用到的变量（还包括宏）的命名规则匈牙利命名法，这种命名技术是由一位能干的 Microsoft 程序员查尔斯·西蒙尼(Charles Simonyi) 提出的。 

匈牙利命名法通过在变量名前面加上相应的小写字母的符号标识作为前缀，标识出变量的作用域，类型等。这些符号可以多个同时使用，顺序是先m_（成员变量），再指针，再简单数据类型，再其他。例如：m_lpszStr, 表示指向一个以0字符结尾的字符串的长指针成员变量。 

    匈牙利命名法关键是：标识符的名字以一个或者多个小写字母开头作为前缀；前缀之后的是首字母大写的一个单词或多个单词组合，该单词要指明变量的用途。

匈牙利命名法中常用的小写字母的前缀：

前　缀       类　　型 
a               数组 (Array)  
b               布尔值 (Boolean)  
by             字节 (Byte)  
c              有符号字符 (Char)  
cb            无符号字符 (Char Byte，没有多少人用)  
cr             颜色参考值 (ColorRef)  
cx,cy         坐标差（长度 ShortInt）  
dw           Double Word  
fn              函数  
h                Handle（句柄）  
i                整型  
l              长整型 (Long Int)  
lp             Long Pointer  
m_          类的成员  
n            短整型 (Short Int)  
np          Near Pointer  
p            Pointer  
s           字符串型  
sz         以null做结尾的字符串型 (String with Zero End)  
w        Word  

二、骆驼命名法:

        骆驼式命令法，正如它的名称所表示的那样，是指混合使用大小写字母来构成变量和函数的名字。例如，下面是分别用骆驼式命名法和下划线法命名的同一个函数：

   printEmployeePaychecks()；

    print_employee_paychecks()；

     第一个函数名使用了骆驼式命名法——函数名中的每一个逻辑断点都有一个大写字母来标记；第二个函数名使用了下划线法—-函数名中的每一个逻辑断点都有一个下划线来标记。

    骆驼式命名法近年来越来越流行了，在许多新的函数库和Microsoft
Windows这样的环境中，它使用得当相多。另一方面，下划线法是c出现后开始流行起来的，在许多旧的程序和UNIX这样的环境中，它的使用非常普遍。

三、帕斯卡（pascal）命名法：

       与骆驼命名法类似。只不过骆驼命名法是首字母小写，而帕斯卡命名法是首字母大写

       如：public void
DisplayInfo();

              string UserName;

              二者都是采用了帕斯卡命名法.

在C#中，以帕斯卡命名法和骆驼命名法居多。

简单说

MyData 就是一個帕斯卡命名的示例 
而myData是一個骆驼命名法,它第一個單詞的第一個字母小寫,後面的單詞首字母大寫,看起來像一個骆驼 
而iMyData是一個匈牙利命名法,它的小寫的i說明了它的型態,後面的和帕斯卡命名相同,指示了該變量的用途. 

这是一个广为流传的关于项目管理的通俗讲解

想首先问大家一个问题：你觉得中国人聪明还是美国人聪明？
我见过最好的回答是美籍华人。
我们说美国人很愚蠢，为什么呢？
你们都考过T或G吧，他们经常会出这么一道题1/3+1/2=？
50%的人回答是2/5，这可是美国研究生入学考试的试题呀！
通常在这个问题之前还有一个1/2+1/2=？为什么？
他们怕太难了，先给个容易的热身一下。
我在美国的时候见过很多的PHD，对于美国人来说if…else…是逻辑，而if…if…else…就成了哲学，也是美国这么多哲学博士的原因：）
我们说美国人很愚蠢，那我们为什么还要学习他们呢？这个问题稍候我们会回答。
再问一个问题：如果你刚买了一个豪华的房子，可你三岁的儿子把整个墙壁上都写上“我爱长城永不到，我爱北京天安门”，你该怎么做？
有的女孩子说暴打，呵呵，这个答案从女生的嘴里说出来还是比较少见。
美国人怎么办？
他们会对孩子说：“你老人家真有绘画的天赋，简直就是毕加索的毕加索，你这一幅画至少能卖100万美金”你们知道美国人喜欢钱，用金钱来量化一定是效果明显。
但显而易见，您老人家把画画在墙壁上是不能永久保存的，所以我明天给你买一个画布，你就尽情的画吧。否则我们要损失多少个毕加索呀！
于是我们就可以看见我们的小宝贝在画布上快乐的滚来滚去。墙面也干净了。

中国人很聪明，从大家就可以看出来，但中国人聪明做工作就有了聪明的做法，他们往往是每个项目都是按照自己的见解来做。
而美国人如何来操作呢，他们就象洗澡，会在面前挂一张纸，上面写着先洗头，再洗耳朵，再细脸，，，这样做事情就有了一定的流程，渐渐的就形成了一套体系。
所以这也是我们今天来探讨项目管理的目的所在。

项目管理分九个知识领域，分别是成本管理、质量管理、时间管理、范围管理、人力资源管理、沟通管理、风险管理、采购管理和整体管理。
其中时间，质量和成本管理构成了三角形
大家在纸上画一个三角形
在各个边上标上时间、质量、成本（等边三角形）
任何一方的移动必定带动其他的变形，如果时间缩短，怎么样？就是我们常说的“献礼工程”，同时必定会影响质量和成本。问大家一个问题，这个三角形中间是什么东东？
对，是范围管理，也就是我们说的项目范围。这也就是我们常说的项目“项目管理三角形”

下面介绍一下项目管理的“项目管理三角形“
项目三角形中的成本，主要来自于所需资源的成本，自然也包括人力资源的成本。这个相信很好理解。
为了缩短项目时间，就需要增加项目成本（资源）或减少项目范围；
为了节约项目成本（资源），可以减少项目范围或延长项目时间；
如果需求变化导致增加项目范围，就需要增加项目成本（资源）或延长项目时间
通过“项目管理三角形“我们了解了项目成本、时间，质量和范围的简单定义。
我们说一个项目经理有多少时间是用来做沟通的工作的？
应该不少于75%的时间是用来沟通的，所以项目管理将项目沟通管理单独列了出来。
所有这些领域都有一个主线就是项目的整体管理来统一的。
由于时间的限制我们不详细讨论其他的知识领域，因为今天是入门的，哈哈

另外项目管理除了九个知识领域，还应该了解5个过程组
5个过程组就是：启动，计划，执行，控制，收尾。
这5个过程组贯穿于每个知识领域的始终，你们了解吗？
举个例子字来说
某人（比喻）好不容易找了个女朋友，为了增进进一步的距离，他想来个欧亚8日游，于是他把自己多年的积蓄——3万元，一次性投入。
但在旅游过程中，他的MM看上了另外一个帅哥，于是人财两空，说明什么问题？
说明他的项目启动的时候就出现了问题，没有很好的做市场调研，结果过程就没有办法控制。
根据PMI的解释，接单之后项目自然转入启动阶段
于是他刻苦的工作，终于又攒了3万，这次他不和美女旅游了，考虑到自己的费用，他请这个姑娘看了场电影。
于是他带这个这个姑娘看了——《第一滴血》
看的那叫爽，姑娘看的也很爽，看看完后她觉得这个家伙有暴力倾向，于是又分手。说明什么问题？
对，没有进行有效的需求调查，也就是在计划的时候没有明确的需求定义。
于是他下次的时候知道了姑娘爱看歌舞剧，于是他就请一个靓女看了《天鹅湖》，可是以外有发生了——
进去后发现座位不在一起，等他们把位子换到一起的时候歌舞剧结束了，这说明什么？
对，说明没有很好的执行，起码在执行过程中没有进行有效的监督。
其他的过程不一一解释，我在这里强调的是收尾的重要性。
我们往往非常注重合同性收尾，却总是忽略管理性收尾。什么是管理性收尾呢？
某人同志吸取了所有的经验教训，终于领了结婚证，还应该干些什么呢？
对了，还应该把所有的经验教训总结一下，以书面的形式汇报给老妈，并张贴于门后。
然后在中堂挂一幅对联：欲谈恋爱者需先阅读门后之——《恋爱指南》
以后凡是自己的兄弟姐妹要谈恋爱的，必须先参阅门后的恋爱指南。
这样能起到什么效果呢，对，以后他们的恋爱项目操作至少能停留在这个水平。
这个过程怎样来保证呢，对，还需要我们的QA人员，也就是他的妈妈负责质量控制。
家规一条，不参阅者或不照此操作者不许谈恋爱！
大公司一般有质量管理部门（QA），QA的成员基本上都是由非常有经验的PM转型过来的老狐狸，是老总接班人的有力争夺者：）
这也是我们说一个失败的项目会培养一批优秀的项目经理的原因。

哪个门后的《恋爱指南》我们称之为文档，文档重要吗？我们说在电信科技处的同志们说重要，为什么因为他们管这个，但对于我们呢？
大家拿起你身边的一只笔，告诉我他多长？
有的说10厘米，有的说10。0987厘米。
我们说他的估算很精确，但不准确！！
这是我如果拿一只笔告诉你正好10厘米，然后和你的笔比对你是不是就比较容易得出测算？
这说明文档是非常重要的，有的人认为文档是最无聊的，项目结束后做个总结不就是了吗。
错，文档的整理应该贯穿于项目管理的始终。
文档的管理是对项目进行良好的跟踪和监控的一个手段，简单的讲就是根据你的项目计划进行你的文档管理。
一般档案分类主线是：立项、计划、执行、结束4大类；然后在每大类中，再根据任务或者团组分类管理，根据哪个需要根据你项目复杂程度和管理习惯，总之原则是方便你对整个项目进度的追踪。
以上我们讲了项目管理的九个知识领域，五大过程组，还有“项目管理三角形“，下面我们讲PMBOK。

PMBOK是项目管理圣经，也就是Project management body of knowledge,项目管理知识体系指南
它是美国项目管理协会（PMI）的核心指导出版物
但它象一本字典，往往你看到第三页会睡着：）
在此简单介绍美国项目管理协会（PMI）和国际项目管理协会（IPMA）
美国项目管理协会只有PMP一个证书，而IPMA有四级，你可以一毕业就可以考试，这个我们后面详细的讲。

下面讲几个名词，如果你掌握了，一和人讲项目管理你就抛出来，一定没有人敢小看你。
他们是WBS、甘特图、基准（BASELINE）、项目干系人和关键路径

WBS是WORK BREAKDOWN STRUCTRE ，工作分解结构
WBS的定义还是很麻烦的，PM要召开团队进行讨论，向成员提供与项目相关的所有详细资料，并把WBS树分解到二层三层。然后要花上一段时间让成员 进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。
比如我们要结婚了，怎么来分解呢
无非是办酒席，拍结婚照，，等等，这个在论坛上曾有人做了详细的分解，大家都可以找到。
我们说为什么WBS重要，而且大部分项目管理的咨询都是针对WBS的咨询
因为WBS做好了，以后工作就有了参考物，你就知道在不同的阶段你应该干什么，完成到什么进度。
其实WBS的划分是没有规则的，主要的考虑角度是方便你做各类的统计工作，为管理服务。
同样的一个项目其管理的侧重点不同，WBS结构的划分也可能是完全不同的。
衡量划分好坏的标准应该是看其是否满足你管理的需要。

甘特图也叫横道图等，很多名称，我们说它是甘特在第一次世界大战时开始使用，它就是在WBS的基础上将WBS形象化老控制进度

对于基准，我象举个例子。
我们在没有结婚之前，你脚踩几只船？
我们说法律允许但道德不允许，但你可以脚踩N只船：）
但当有一天你和你的朋友进了一个小黑屋子，然后带了两个盖章的本本的时候，你还可以脚踩N只船吗？
我们说此时就不允许了，因为你过了一个基准线（BASELINE）
如果你还想脚踩N只船就需要重新回小黑屋子再盖两个章就可以了。
那我们的项目要越轨怎么办，也就是项目变更？
我们说对这样的项目变更会影响各要素比如时间，成本，质量等
我们应该统一由项目管理办公室来进行控制，如果你要变更基准，必须要进行严格的限制。
在客户提出变更请求时，要建立变更申请登记表和变更申请 表，并让客户签字。
有时候一些不是非常关键的模块PM也不至于一点不讲情面，该卖面子的时候还是要卖，尤其是当着对方领导的面，千万要 卖面子，但是也别卖的太干脆，不要让他们得到的太容易。
PM在变更管理中需要做的是分析变更请求，评估变更可能带来的风险和修改基准文件。

如果一个项目进行过程中，比如现在的点心的3G项目，你发现如果再多花一点时间就可以编写出对以后非常有用处的程序，但这个程序不在本项目范围之内，你要不要做？
对，我们说不能做，你可以重新起一个项目来做，但不能在这个项目里做，这样会是我们的项目成本超出，风险增加，而且和其他的项目缺少比对性和参照的价值。

这也是我们说现在有大约80%以上的项目失败的原因，我们说项目失败并不是项目进行不下去了，彻底破产，在PMI有明确的定义，凡是项目的成本超出预算，质量没有得到保证，时间超过预计等等都在失败的范围之内。

这个在华为做的很好，华为有个有名的增量开发的名声。
只用20%的功能先满足你80%的需求，其他的功能我可以开发升级的版本，于是就在小数点后平明的增加数字，于是就是了V1，V1.1，V1.11….等版本
它从来不一下子满足你所有的需求，我们大家想想，谁没有事情拿出自己的手机把所有的PING码都试用一下，我们说没有，我们大部分的需求是在打电话，发消息，打打游戏，对不对？
这点在项目管理中非常重要，请大家结合资料好好研究。

项目干系人是什么东东，谁给我举一个例子？
对，包括项目人员的老婆孩子，正确
我们说有的项目需要的时间很紧张，如果你的项目成功了，但项目的程序员们都成了光棍，那项目还是非常失败，至少不是丧心病狂的PM这么想。
合理解决项目干系人的冲突是个很累的问题，其中还包括你的只能经理们，你的董事长，你的客户，等等，等等，有的说没用？
好，如果你的项目进展不下去，你该怎么办？
对，开会，把你的高层找一个坐到会议室，不用他说话，只让他暧昧的看着大家，大家一定会想，这个家伙一定和领导有关系，我们还是好好的做这个项目，下一个项目再给他使拌子吧：）
所以为了不累死好好分析一下你的项目干系人吧
我们上次讲了一些基础的知识，包括什么是项目管理，项目管理包括什么？

你说项目管理有几个知识领域？
你说项目管理有几个过程组？
让我们想起了泡MM的例子是不是？
还有老母亲做QA的比喻
几天我们着重强调的是

项目是什么?人们常用“时间”，“资源(或缺乏资源)”，“某种工作努力”，“交付物或者产品”，“综合工程”，“缺乏凌驾其他班组的职权”，以及“预算”来给它下定义。实际上，项目是一种独特的工作努力，即遵照某种规范及应用标准去导入或生产某种新产品或某项新服务。这种工作努力应在限定的时间、成本费用、人力资源及资财等项目参数内完成。
首先给大家一个项目的定义，到底什么是项目？
根据PMPBOK的定义，项目是在一段时间内为完成某一独特的产品或提供独特的服务所进行努力的过程。
这个过程受到时间、人力、资源、成本、质量上的限制
项目有几个特征：1.临时性 2.独特性 3.一次性
下面大家告诉我下面哪个是项目：A惠普与康柏机构重组惠普与康柏机构重组。B建造一座新工厂 C改建道路 D工程材料采购 E开发软件包 F结婚典礼 G寻找拉登
有人说是寻找拉登，大家说寻找拉登有明确的结束时间吗？
当然我们可以假设寻找拉登50年如果找不到，项目就结束是不是？
所以说我们今天不讨论哪个到底是项目，所有的问题都要放到具体的环境下，否则没有意义。

下面大家可以开始提问了。

什么是WBS呢？
WBS是工作分解结构，就象一张道路交通图，它能够指引你如何从当前位置到达想去的地方。没有它，你可能就要迷路了。
怎样来做一个好的WBS呢？
有时候在接受新项目时前无例子可借鉴感觉分解时真困难, 因为每个人的解决问题思路不同,同一个项目不同的人有很多种分类, 因为可以按照工作的流程分解,也可以按照系统论的方法进行结构上的分解, 但我觉得有一条很重要的原则应该注意,那就是麦肯锡的精髓,他们在分解工作时非常强调的就是MECE, muturally exclusive, collectively exhaustive, 即相互独立,完全穷尽的原则, 也就是现在较流行的说法”横向到底,纵向到边” , 如果分解时坚持了这个原则, 我想一定会有Perfect 的WBS, 其实WBS并非是PMI的”真传”, 只是被PMI起名为WBS, 有时候工作中我们也会用类似的方法解决问题无非是没有提升到理论高度, 但WBS确实是做事的核心步骤。
做一个WBS需要注意一些什么问题呢？
? 第一级通常与项目生命周期相同(如需求分析，设计，采购，施工……)
? 第一级应在项目进一步分解前完成
? WBS的每一级都是其上一级的片断(Segment)
? 一个工作单元只与一个上层单元相关
? 上层单元的工作内容应该等于其所有直接下层工作单元的总和
? 一个工作单元由一个人负责
? 在整个WBS中使用同一种定义，在整个组织中亦然
? 通过将人员包括进WBS来激励他去完成计划
什么是甘特图呢？
1.以图形或表格的形式显示活动。
2.现在是一种通用的显示进度的方法。
3.构造时应包括实际日历天和持续时间。不要将周末和节假日算在进度之内

什么是风险呢？

首先问一个问题
你们说在一个项目中，初始阶段和结束阶段哪个时候项目的风险大？
对，是开始的时候，因为在开始的时候我无数的不可控制的因素。
那什么阶段的损失大呢？
对，在结束的时候，所以说两者是相反的/
所以说在项目的启动阶段成功的可能性最小，风险发生的概率也就最高，但是这时候一旦预计的风险发生了，损失是最小的。
想想广州和深圳很多烂尾楼？损失会有多少？？？！！！！！

另外我们要明确几个定义：
1是确定性。具有明显的可能性，比如中国和韩国对抗赛，胜负是很明显的：）
2是风险。韩国队能赢中国队几个球是一种风险的预测。
3是未知性。中国和美国比赛门球那就是未知的：）

关系数据库设计之时是要遵守一定的规则的。尤其是数据库设计范式 现简单介绍1NF（第一范式），2NF（第二范式），3NF（第三范式）和BCNF，另有第四范式和第五范式留到以后再介绍。 在你设计数据库之时，若能符合这几个范式，你就是数据库设计的高手。

第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。

第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。
例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）
在应用中使用以上关系模式有以下问题：
a.数据冗余，假设同一门课由40个学生选修，学分就 重复40次。
b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。
c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。
d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。
原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。
解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系

第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，
姓名，所在系，系名称，系地址。
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。
例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件
a.一个仓库有多个职工。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析：由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） -> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）-> ENO。因为 一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 （ENO，PNO）-> QNT。
找一下候选关键字，因为（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。
分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部 分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而P->WNO，故（ENO，PNO）-> WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。
解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO
缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。

一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。

1NF直到BCNF的四种范式之间有如下关系：
BCNF包含了3NF包含2NF包含1NF

小结：
目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新
原则：遵从概念单一化 “一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式”等价”，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。

注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。

关键字： Unicode, Character Set, 字符集, UTF-8, ANSI, ASCII, UTF-7
原文标题： The Absolute Minimum Every Software Developer Absolutely, Positively Must Know
About Unicode and Character Sets（No Excuses!）
原文链接： http://www.joelonsoftware.com/print…es/Unicode.html
作者： Joel Spolsky

ASCII 码
————————————————————————————
7 位（00～7F）。 32 ~ 127 表示字符。32 是空格， 32 以下是控制字符（不可见）。
第8位没有被使用。全世界很多人同时对这个位的含义发展了不同的用处。比如 IBM PC 中的 OEM 字符集。
最后就 128 位以下的用处达成共识，制定了 ASCII 标准。
而 128 位以上的可能有不同的解释，这些不同的解释就叫做 code pages.
甚至有用于在同一台电脑上解释多种语言的 code page.

同时，在亚洲发生了更加疯狂的事情。亚洲语言的字符集通常数以千计， 8 位已经不足以表达，这通常用一种
很凌乱的，叫做 DBCS（双字节字符集,double byte character set） 的系统来解决。
这种系统中，有些字符占用 1 字节，有些 2 字节。这样一来，在字符串中向前解析很容易，而倒退却很麻烦。
程序员们被建议，不要使用 s++ 或 s– 来前进和后退，而使用一些函数，比如 Windows 的 AnsiNext 和
AnsiPrev. 因为这些函数知道是怎么回事。

这些不同的假设（code page）在单个的机器上没有问题。而随着 Internet 的发展，字符串要从一个机器上移到
另一个机器上，这就产生了问题。于是， Unicode 出现了。

Unicode
—————————————————————————————
Unicode 是一个勇敢的成就。它把在这个星球上的每一个合理的文字系统整合成了一个单一的字符集。
很多人还存在这样的误解： Unicode 仅仅是 16 位的这么简单，每个字符占 16 位，所以一共有 65536 个可能的字符。
然而，这是错误的。不过不要紧，因为这是大部分人都会犯的一个普遍的错误。

实际上，Unicode 理解字符的方式是截然不同的，而这是我们必须了解的。
到目前为止，我们都曾经认为：一个字符对应到一些在磁盘上或内存中储存的位（bits）. 如： A -> 0100 0001
而在 Unicode 中， 一个字符实际上对应一种叫做 code point 的东西。
比如 A 这个字符，是抽象的（原文：platonic,柏拉图式的，理想的）一个概念。
无论是 Times New Roman 或者 Helvetica 或者其他的什么字体中，都代表同一个字符。但是它和小写的字母 a 不同。
但是在其他的语言，比如希伯莱语（Hebrew） 或者德语（German）, 阿拉伯语（Arabian） 中，同一个字母的不同的字形代表的含义是否
相同，是有争议的。经过长时间的争论，这些也终于被确定了。

每一个字母表中的每一个抽象的字母，都被赋予了一个数字，比如 U+0::5. 这个叫做 code point.
U+ 表示： Unicode, 数字是 16 进制的。
你可以通过 charmap 命令来查看所有这些编码。（Windows 2000/XP 中）. 或者访问 Unicode 的网站（http://www.unicode.org）
Unicode 中 code point 的数字的大小是没有限制的，而且也早就超过了 65535. 所以不是每个字符都能存储在两个字节中。
那么，一个字符串 “Hello”， 在 Unicode 中会表示成 5 个 code points :
U+0048 U+0065 U+006C U+006C U+006F
只不过是一些数字。但我们现在还没有提到如何在磁盘或者 Email 中表示这些信息，这就是我们下面要提到的编码（Encoding） 干的事情。

Encodings （编码）
————————————————————————-
最初的 Unicode Encoding, 使用两个字节表示一个字符。那么 “Hello” 表示为：
00 48 00 65 00 6C 00 6C 00 6F
实际上，还有一种表示方式：
48 00 65 00 6C 00 6C 00 6F 00
到底高位字节在前还是低位字节在前面，是两种不同的模式。这要看特定的 CPU 在何种模式下工作的更快。 所以这两种都有。
这就有了两种不同的 Unicode 表示方式了，为了区分，人们又采用了一种奇异的方式：
在每一个 Unicode 字符串的前面，加上 FEFF （这称为 Unicode 字节顺序标志，Unicode Byte Order Mark）.
如果你交换高位和低位次序，那么会加上一个 FFFE. 这样，读这个字符串的人才知道要对每两个相邻的字节进行交换。
但在最初的时候，并不是每一个 Unicode 字符串都有这个标志的。

这看起来很不错。可程序员们开始抱怨了，“看看那些零！”。因为有些是美国人，他们使用英语。而英语中很少需要使用 U+00FF 以上的
字符， 有些人无法忍受采用双倍的存储空间来存储每个字符。
基于这些原因，很多人决定忽视 Unicode, 而同时，事情变得更糟了。

然后人们制定了 UTF-8. UTF-8 是用于保存 Unicode code points 的另一套系统。
每一个 U+ 数字，在内存中占用 8 bit. 在 UTF-8 中，任何一个 0~127 的 code point 占用一个字节。
只有 128 以及更大的才占用 2, 3, 直到 6 个字节。
具体如下图所示：

16进制的最小的数 16进制的最大的数 内存中的字节序列
——————————————————————————
00000000 0000007F 0vvvvvvv
00000080 000007FF 110vvvvv 10vvvvvv
00000800 0000FFFF 1110vvvv 10vvvvvv 10vvvvvv
00010000 001FFFFF 11110vvv 10vvvvvv 10vvvvvv 10vvvvvv
00200000 03FFFFFF 111110vv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv
04000000 7FFFFFFF 1111110v 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv 10vvvvvv

这看起来很不错，其中的英文字符和 ASCII 中一样。所以美国人根本没意识到有什么错误。只有世界上的其他国家需要使用高位的字节。
特别的，”Hello” 这个字符串，Unicode code point 为 U+0048 U+0065 U+006C U+006C U+006F， 会被存储为 48 65 6C 6C 6F。
和 ASCII, ANSI, 以及在这个星球上的任何一个 OEM 的字符集中表示的含义都一样。
现在，如果你需要表示重音的字符，或者希腊语，你需要使用多个字节来表示一个 code point. 但美国人不会介意这些。
（UTF-8 还有一个好处就是，老的字符串处理程序使用一个为 0 的字节来表示 null-terminator, 不会截断字符串）

到目前为止已经介绍了三种 Unicode 的表示方法：

传统的双字节表示方法， 称为 UCS-2（因为有 2 个字节） 或者 UTF-16（因为有 16 个位）
而且你还要搞清楚是高位在前的，还是高位在后的 UCS-2.

还有一种就是新的 UTF-8. 如果你的程序只使用英文的话，它仍然会工作正常。

实际上还有一堆的其他办法对 Unicode 进行编码：
有 UTF-7，这种编码方式大部分和 UTF-8 相同，但保证高位一定为 0.
所以如果你必须通过某种 Email 系统传送 Unicode，这些系统认为 7 位足够了，那使用 UTF-7 会正常。
还有 UCS-4, 储存每一个 code point 为 4 个字节。它的优点是每一个字符都保存为同样长的。但很明显，缺点是浪费太多存储空间了。

所以，现在你思考问题要把每一个字符想象成抽象的一个 unicode code point. 而它们同样可以使用任何旧的方式编码。
举例来说，你可以把 Unicode 字符串 Hello （U+0048 U+0065 U+006C U+006C U+006F） 编码（encode）为
ASCII, 或者古老的 OEM 希腊语编码，或者希柏莱 ANSI 编码，等等。而有些字符串不能显示！
也就是说，假如你要表示一个在某个编码中没有对应的 Unicode code point, 通常会显示为一个 ? 或者一个白色的小方框。

英文常用的一些编码有， Windows-1252（Windows 9x 标准 for 西欧语言）
以及 ISO-8859-1, aka Latin-1（对任何西欧语言也有效）
如果用这些编码来尝试存储俄文字符，你会得到一堆的 ?

UTF 7, 8, 16 以及 32 都有一个优点，能够正确的存储任何的 code point.

最简单，也是最重要的几个概念
====================================================================
一个字符串不指定它使用什么编码是没有意义的。
再也不要假定， “纯”文本（plain text） 是 ASCII.
没有 “纯文本” 这个东西。

如果你有一个字符串，在内存中，在文件中，或者在 Email 消息里，你必须知道它的编码是什么。否则你无法正确的解释或者显示给用户。
所有的诸如 “我的网页不能正常显示了”，或者 ”Email 消息不能正常显示了“ 之类的愚蠢问题， 都是因为， 没有告诉你到底是使用的那种编码，
UTF-8 还是 ASCII 还是 ISO 8859-1 或者 Windows 1252 ?? 那么自然无法正常的解释和显示，甚至不知道字符串该在哪里结束。

那么如何保留这样的编码标志，来表示字符串的编码？ 有一些基本的办法。
比如对于 Email 来说，在表单的 header 中加上：

Content-Type:text/plain;charset=”UTF-8″

对于 Web 页面来说，原来的做法是， Web 服务器随着 web 页面本身一起，发送一个类似于 Content-Type 的 http header.
（不是在 HTML 里面，而是作为一个 response header 在 HTML 页之前发送）

这样做有一个问题。如果你的 Web 服务器同时有多个站点，站点由多个不同的人用不同的语言开发的程序混在一起。那么 Web 服务器将无从得知，
每一个文件是用什么编码方式写的。这样也就无法发送正确的 Content-Type header.
如果你能够在每一个 HTML 文件中记录 Content-Type 信息，那么就很方便了。可这念头似乎也很疯狂，因为你还没有知道用什么编码方式去
读取这个文件，又怎么能读出编码信息呢？
幸好，几乎每一种编码中，对 32~127 的字符都解释的相同。所以你可以在每一个 html 文件中这么写：

但是要注意， 这个 meta 标签必须放在 head 中靠前面的位置才能保证不会出问题。 因为 Web 服务器读到这里的时候，就会停止解析，
然后用读到的这个编码方式重新解析页面。

那么，作为 Web 浏览器来说，如果没有在 meta 标签中或者 http headers 中发现 Content-Type, 会怎么样呢？
IE 是这么做的：
先尝试去猜，根据特定的字节出现在各种语言的典型的编码中的频率。
如果编码设定不正常，用户可以通过 View|Encoding 菜单来尝试不同的编码方式。（当然，不是每个人都知道该这样做）

在 VB, COM, Windows NT/2000/XP 中，默认的字符串类型是 UCS-2（2字节）的。
在 C++ 代码中， 我们可以定义字符串为 wchar_t（wide char），同时用 wcs 系列的函数代替 str 系列的函数。
如 wcscat, wcslen, 而不是 strcat, strlen.
在 C 代码中，要创建 UCS-2 字符串的话，只要在前面加一个 “L”, 如 L”Hello”

对于 Web 页面，最好统一为使用 UTF-8 编码。 这个编码已经被各种 web 浏览器支持了很多年了。

转自村子(Double_ycn)

什么是 Unicode?

历史上, 有两个独立的, 创立单一字符集的尝试. 一个是国际标准化组织(ISO)的 ISO 10646 项目, 另一个是由(一开始大多是美国的)多语言软件制造商组成的协会组织的 Unicode 项目. 幸运的是, 1991年前后, 两个项目的参与者都认识到, 世界不需要两个不同的单一字符集. 它们合并双方的工作成果, 并为创立一个单一编码表而协同工作. 两个项目仍都存在并独立地公布各自的标准, 但 Unicode 协会和 ISO/IEC JTC1/SC2 都同意保持 Unicode 和 ISO 10646 标准的码表兼容, 并紧密地共同调整任何未来的扩展.
什么是 UTF-8?

什么是 Unicode?

历史上, 有两个独立的, 创立单一字符集的尝试. 一个是国际标准化组织(ISO)的 ISO 10646 项目, 另一个是由(一开始大多是美国的)多语言软件制造商组成的协会组织的 Unicode 项目. 幸运的是, 1991年前后, 两个项目的参与者都认识到, 世界不需要两个不同的单一字符集. 它们合并双方的工作成果, 并为创立一个单一编码表而协同工作. 两个项目仍都存在并独立地公布各自的标准, 但 Unicode 协会和 ISO/IEC JTC1/SC2 都同意保持 Unicode 和 ISO 10646 标准的码表兼容, 并紧密地共同调整任何未来的扩展.
什么是 UTF-8?

首先 UCS 和 Unicode 只是分配整数给字符的编码表. 现在存在好几种将一串字符表示为一串字节的方法. 最显而易见的两种方法是将 Unicode 文本存储为 2 个 或 4 个字节序列的串. 这两种方法的正式名称分别为 UCS-2 和 UCS-4. 除非另外指定, 否则大多数的字节都是这样的(Bigendian convention). 将一个 ASCII 或 Latin-1 的文件转换成 UCS-2 只需简单地在每个 ASCII 字节前插入 0×00. 如果要转换成 UCS-4, 则必须在每个 ASCII 字节前插入三个 0×00.

在 Unix 下使用 UCS-2 (或 UCS-4) 会导致非常严重的问题. 用这些编码的字符串会包含一些特殊的字符, 比如 ” 或 ‘/’, 它们在 文件名和其他 C 库函数参数里都有特别的含义. 另外, 大多数使用 ASCII 文件的 UNIX 下的工具, 如果不进行重大修改是无法读取 16 位的字符的. 基于这些原因, 在文件名, 文本文件, 环境变量等地方, UCS-2 不适合作为 Unicode 的外部编码.

在 ISO 10646-1 Annex R 和 RFC 2279 里定义的 UTF-8 编码没有这些问题. 它是在 Unix 风格的操作系统下使用 Unicode 的明显的方法.

UTF-8 有一下特性:

* UCS 字符 U+0000 到 U+007F (ASCII) 被编码为字节 0×00 到 0×7F (ASCII 兼容). 这意味着只包含 7 位 ASCII 字符的文件在 ASCII 和 UTF-8 两种编码方式下是一样的.
* 所有 >U+007F 的 UCS 字符被编码为一个多个字节的串, 每个字节都有标记位集. 因此, ASCII 字节 (0×00-0×7F) 不可能作为任何其他字符的一部分.
* 表示非 ASCII 字符的多字节串的第一个字节总是在 0xC0 到 0xFD 的范围里, 并指出这个字符包含多少个字节. 多字节串的其余字节都在 0×80 到 0xBF 范围里. 这使得重新同步非常容易, 并使编码无国界, 且很少受丢失字节的影响.
* 可以编入所有可能的 231个 UCS 代码
* UTF-8 编码字符理论上可以最多到 6 个字节长, 然而 16 位 BMP 字符最多只用到 3 字节长.
* Bigendian UCS-4 字节串的排列顺序是预定的.
* 字节 0xFE 和 0xFF 在 UTF-8 编码中从未用到.

下列字节串用来表示一个字符. 用到哪个串取决于该字符在 Unicode 中的序号.
U-00000000 - U-0000007F: 0xxxxxxx
U-00000080 - U-000007FF: 110xxxxx 10xxxxxx
U-00000800 - U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx
U-00010000 - U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
U-00200000 - U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

xxx 的位置由字符编码数的二进制表示的位填入. 越靠右的 x 具有越少的特殊意义. 只用最短的那个足够表达一个字符编码数的多字节串. 注意在多字节串中, 第一个字节的开头”1″的数目就是整个串中字节的数目.

例如: Unicode 字符 U+00A9 = 1010 1001 (版权符号) 在 UTF-8 里的编码为:

11000010 10101001 = 0xC2 0xA9

而字符 U+2260 = 0010 0010 0110 0000 (不等于) 编码为:

11100010 10001001 10100000 = 0xE2 0×89 0xA0

这种编码的官方名字拼写为 UTF-8, 其中 UTF 代表 UCS Transformation Format. 请勿在任何文档中用其他名字 (比如 utf8 或 UTF_8) 来表示 UTF-8, 当然除非你指的是一个变量名而不是这种编码本身.
什么编程语言支持 Unicode?

在大约 1993 年之后开发的大多数现代编程语言都有一个特别的数据类型, 叫做 Unicode/ISO 10646-1 字符. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.

ISO C 也详细说明了处理多字节编码和宽字符 (wide characters) 的机制, 1994 年 9 月 Amendment 1 to ISO C 发表时又加入了更多. 这些机制主要是为各类东亚编码而设计的, 它们比处理 UCS 所需的要健壮得多. UTF-8 是 ISO C 标准调用多字节字符串的编码的一个例子, wchar_t 类型可以用来存放 Unicode 字符.

软件文档
http://www.51cmm.com/SoftDocuments/

软件工程类文档
http://www.cnsia.com/zygx/zygx.htm

Software Engineering Document Templates
http://www.rspa.com/docs/ 英文

常用文档模板和对照表
http://www.iturls.com/SoftwareEngineering/SE_c.asp

软件开发文档模板
http://www.sawin.com.cn/doc/SD/Document/doctemplate1.htm

资料文档模板
http://www.easyhot.com/