軟體開發之殤是清華大學出版社出版的一本書，一本對於國內軟體行業的發展、現狀、從業人員指導、現存問題的思考和陳述的書籍。
基本介紹
- 書名：軟體開發之殤
- 又名：The secret of software development
- 作者：申思維
- 原版名稱：軟體開發之殤
- ISBN：9787302526988
- 類別：軟體開發
- 頁數：199頁
- 定價：49.00元
- 出版社：清華大學出版社
- 出版時間：2019年7月
- 裝幀：平裝16開
- 開本：170mm x 240mm
內容簡介,作者簡介,圖書目錄,
內容簡介
本書內容包括程式設計師的職業規劃、給程式設計師的職業成長建議、給程式設計師的技術建議、如何管理技術團隊、國內軟體開發之殤、軟體外包公司生存指南。
作者簡介
申思維，畢業於華南理工大學計算機軟體，一直從事於WEB軟體開發領域。參與創立多個軟體公司，具有深厚的全棧開發功力。熟悉網際網路運維，擅長技術團隊的搭建、管理以及人員的培養。
對中國軟體開發領域以及這個行業的前景和職業規劃，有著非常獨到的見解。
圖書目錄
第1章 程式設計師的職業規劃 1
IT從業人員的職位介紹 1
開發人員 1
測試人員 3
產品經理 4
UI設計師 5
運維人員 5
用戶體驗師（UE/UX） 6
技術經理 6
架構師 7
如何選擇程式語言 8
做Web後端開發建議選擇Ruby 8
做Web前端（H5）建議使用Vue.js、React 8
做移動前端（App）建議使用原生語言和React Native 9
理想的職業發展路線 10
#一階段：新手 10
第二階段：熟手 11
第三階段：技術經理 11
第四階段：創業公司CTO 或大公司技術頂層 11
程式設計師的基本門檻 11
英語必須好 12
思維清晰、反應敏捷 13
表達溝通能力強 14
程式設計師的進階門檻 15
具備領導氣質 15
技術過硬 16
IT從業人員的去路 16
繼續做IT 16
小幅轉行 17
大幅轉行 17
不看好的職業：測試、運維、架構師 17
測試 17
運維 18
架構師 21
軟體培訓機構 21
確實能改變少部分人的命運 21
在一定程度上推進了國內技術的發展 22
培訓機構之痛 22
第2章 程式設計師的職業成長建議 25
務必有技術部落格 25
表達能力得到極大提高 25
技術可以得到積累 25
個人部落格是一張好名片 26
不要敝帚自珍 26
要會與人和睦相處，不要任性 27
控制好自己的脾氣 27
越牛就越謙遜 28
溝通能力是立足社會之本 28
溝通能力很重要 28
千萬不要性格內向 29
任務沒能力完成要勇敢地說出來 30
小心程式設計師的膨脹期 30
不要因為被上家公司坑過就對下家公司抱有成見 31
不要論戰 31
使用傳統程式語言的人特別容易心態不好 33
高發誘因1：過於底層的語言 33
高發誘因2：開發人群的職業年齡是2~4年 34
不要踢皮球 35
會錯失機會 35
會使人緣變差 36
會使人平庸 36
要抓住機會帶團隊 36
一個人做不成事情 37
帶團隊能讓人開闊眼界 37
具有帶團隊的經驗能讓人更好地在社會中生存 38
帶團隊是職業生涯注定的方向 38
要有良好的心態 39
每天都要學習 39
不要淪於平庸 40
工作就是#好的學習機會 41
辦公室沒有政治 42
不要參與公司的八卦 42
正確面對公司的裁員 43
敏捷方法論 44
頻繁交付、小步快跑 44
能自動化的都自動化 45
必要的測試 45
每日例會 45
要培養成學習型團隊 46
良好的程式設計師工作習慣 46
晚上十點前睡覺 47
健康問題：不要總低頭弓背 48
離開顯示器和手機才是休息 49
不要沙發椅，要坐硬板凳 49
顯示器要有護目屏 50
程式設計師的工作組成 51
程式設計師的工作不是一直在寫程式 51
技術經理 51
程式設計師要走出去 52
性格內向 52
過分細膩 52
容易自傲自大 52
不要坐井觀天，要多看看外面的世界 53
規劃好業餘生活 55
不要愛上旅遊 55
不要接私活 55
利用業餘時間做教學 56
中國IT公司的特點 56
技術實力層面 56
人員的年紀差距 57
35歲開始失業 57
技術高層不懂技術細節 58
管理更加嚴格 58
國內軟體崗位的地域特點：北上廣深是絕#主力 58
讀書清單 60
《程式設計師修煉之道——從小工到專家》 60
《軟體工程的事實與謬誤》 61
《黑客與畫家》 62
《軟體隨想錄》 63
《人月神話》 63
《人件》 64
職業前輩的部落格 64
第3章 給程式設計師的技術建議 66
程式設計師如何提問 66
使用好鍵盤周邊 67
選擇什麼編輯器 67
要有正確的鍵盤指法 68
好鍵盤很重要，它是我們的武器 69
合適的鍵盤布局 69
使用好“第六根手指” 70
如何使用快捷鍵 70
單鍵快捷鍵 71
兩鍵快捷鍵 71
三鍵快捷鍵 71
快捷鍵的思考 71
薄鍵盤和Mac鍵盤不適合程式設計師 72
程式設計師的理想裝備 73
大屏顯示器 73
機械鍵盤 73
遊戲滑鼠 74
大容量記憶體 74
固態硬碟 74
高速網速 74
版本控制工具 75
控制原始碼的必要性 75
歷史上的一些SCM工具 76
版本控制終#者：Git 76
在技術的天空中留下痕跡 77
必須有技術部落格 77
必須要有Stack Overflow的賬號 78
必須參與開源項目 79
絕#不要寫重複代碼 80
讓程式設計師喪失工作的興趣 80
讓程式難以修改和測試 80
讓人容易辭職 80
解決重複的原則：事不過三 81
命令行在大部分時候要優於圖形操作界面 81
幾個例外 83
操作的選擇：優先使用Linux 84
技術廣度比深度更重要 84
以#價比#高的方式點亮技能樹 85
如何學習多種技能 87
技術債 88
技術債的後果很嚴重 88
典型的技術債1：的底層架構 88
典型的技術債2：的技術實現 88
典型的技術債3：低劣的代碼質量 89
解決方案 89
一種高效的需求分析方法：可視化分析 89
用戶的需求特點：不明確 89
方法概述 91
具體方法 92
幾點注意事項 97
登錄頁面一般分成兩端 98
估算工作量 98
代碼質量 99
良好的命名是#好的注釋 99
為什麼不要注釋 100
不要使用縮寫 102
慎用匈牙利命名法 102
廢代碼 104
看起來美好卻不實用的技術 105
螢幕自動適配 105
語言的化（i18n） 106
多資料庫的同時適配 108
其他 109
為什麼要自己搭建部落格 110
要學會分享和開放 110
部落格是重要的名片和筆記 110
寫部落格可以極大地提高表達能力 111
追求自動化 111
編譯的自動化 111
部署的自動化 111
測試的自動化 112
第4章 如何管理技術團隊 113
基本的管理原則 113
就事論事 113
任務劃分得當、到人 114
公平公正 114
保持開放的氛圍 114
程式設計師的特點 114
容易驕傲 115
程式設計師之間的鄙視鏈 115
比較單純 115
有職業病 116
容易自我關閉 116
技術人員的性格特點 117
實力決定地位 117
誠實才會走遠 117
高壓政策下容易踢皮球 117
性格趨於內向 117
正能量與負能量 118
技術團隊的內部矛盾 118
程式設計師跟產品經理的矛盾 118
UI跟程式設計師和產品經理的矛盾 119
產品經理跟老闆的矛盾 120
程式設計師跟測試人員的矛盾 121
程式設計師跟運維人員的矛盾 121
前端與後端開發人員的矛盾 122
招聘和培養新人 123
如何招聘新人 123
如何培養新人 126
如何對待老員工 127
老員工是公司的財富 127
老員工生產力可能是新人的10倍以上 127
尊重老員工的建議 128
要有領導藝術 128
給老員工成長的空間 128
如何識別項目毒藥 129
脾氣差並與同事發生過爭執的人 129
在代碼中寫過粗口的人 129
工作中喜歡抱怨的人 129
培養自我成長型團隊 129
做好知識分享會 130
鼓勵在項目中使用新技術 130
只招聘聰明人 130
讓團隊散架的因素 130
團隊毒藥 131
不公平的薪水 131
不開心的工作環境 131
絕#不要認為技術人員的生產力是固化的 132
問題1：出高價也招不到合適的人 132
問題2：就算招到也容易離職 132
問題3：人與人的工作效率很不一樣 133
第5章 國內軟體開發之殤 134
行業弊端 134
軟體價格要么低得離譜，要么高得過分 134
存在欺騙和不信任的情況 136
有吃回扣的傳聞 137
程式設計師群體的心理狀態 137
不認權#，誰行誰上 137
清高、難以管理 138
容易跳槽 138
軟體開發的行業真# 138
需求方#關心的三句話 138
軟體項目成功率比較低 138
軟體開發工作量難以計算 139
軟體開發是重度自定義的 139
不存在萬#的 139
軟體的重用和細化粒度 140
國內軟體公司的特點 140
技術含量低 141
普遍英語不好 141
要么是外包公司，要么是網際網路公司 141
外包公司大部分都比較爛 141
大公司的軟體部門其實跟小作坊差不多 142
國內的程式設計師容易安於現狀 142
修改開源項目的極大 143
開源項目的 143
開源項目的特點 144
創業團隊務必要有CTO 145
CTO是技術團隊的組建者 145
CTO是團隊發展的土壤 145
CTO是團隊的舵手 145
CTO的困局 145
合格的CTO的標準 145
技術要全面 146
真實的CTO囧境 146
如何找到靠譜的CTO 147
通過技術圈的朋友來引薦 147
靠譜的CTO可遇而不可求 147
絕#不要找兼職的CTO 148
低工資留不住人 148
簡歷中的尷尬 149
團隊培養的途徑 149
把握好你的CTO 149
技術團隊要少而精 150
正視技術人員的作用 150
技術一般短期內被高估、長期內被低估 150
就差一個程式設計師了 151
好的程式設計師與差的程式設計師的差別 152
#一次和第N次的區別 152
好的程式設計師都是靠項目磨練出來的 152
程式設計師永遠會遇到新問題 153
核心技術變更得比較慢 153
二八定律 153
外包的亂象 154
行業門檻低 154
絕#不要找外地的承接方 154
絕#不要找太便宜的軟體承接方 155
絕#不要貪圖便宜 155
絕#不要找兼職的開發人員 155
經驗：明確網際網路在自己項目中的位置 156
經驗：一個靠譜的技術開發團隊的運營成本 157
經驗：外包項目與自己培養團隊的比較 157
經驗：如何保證你的項目進度 158
經驗：產品經理如何提需求 158
為什麼好的程式設計師或者一#的技術人員難找 159
英語不好 159
人心浮躁 159
為什麼程式設計師通常無法精通多個語言或者技術 160
傳統語言過於笨重 161
使用第三方包也很慢 161
傳統語言與現代語言的對比 162
自有團隊 163
開發初期的費用 163
自有團隊的好處 163
自建團隊的關鍵 164
如何招聘 164
從技術痕跡識人#靠譜 165
軟體與家裝的行業比較 166
都有複雜的流程 166
都是工匠行業，跟流程無關 166
不夠透明的因素 167
期待變革的步履蹣跚 168
需要用戶頻繁的反饋 168
基層員工水平參差不齊 169
這是一個不確定的行業 169
軟體工作量難以準確估算 169
腦力勞動難以衡量 169
工作量無法明確衡量 170
用戶的需求是不明確的 171
行業曙光1：全棧工程師 171
角色的緣起 171
溝通的成本太高 171
不好的流程會催生出壞人 172
不要把程式設計師分成後端和前端 173
全棧工程師的特點 174
實戰情況 176
有可能產生全棧工程師的技術背景 176
行業曙光2：乙方應該按時間收費 177
絕#不要按照模糊的需求來收費 177
可以按照項目收費 177
用時間給程式設計師估價是合理的 178
死亡案例 179
一句話需求 179
超過半年的交付周期 180
不合理的價格 180
層層轉包 180
不要頻繁見面 181
不靠譜的程式設計師 181
異地外包 181
用戶不切實際的過高期待 182
被人用現成的項目去套 182
外行人做的軟體公司必死 183
不要迷信高學歷CTO 183
項目失敗很傷人脈 184
不要迷信海歸 184
不要做人力外派公司 185
員工的歸屬感不強 186
招不到好員工 186
難以直接管理 186
小心花架子技術負責人 186
實戰經驗弱 187
學歷大部分很高 187
背景很高大上 187
結論 188
第6章 軟體外包公司生存指南 189
接項目務必慎重 189
傳統公司的項目不接 189
甲方公司存在內部矛盾的項目不接 190
管理不規範的公司項目不接 191
不守時公司的項目不接 192
要回扣的項目輕易不接 192
網際網路公司的項目更舒服 193
外包公司永遠的痛點：要賬 193
永遠不要跟甲方撕破臉 193
跟甲方保持好關係 194
要賬要找對人 194
需求的特點 194
需求一定比想的要複雜 194
不要使用選單式報價 195
需求是一定會變更的 195
需求不要只增不減 196
如何識別不可或缺的需求 196
軟體外包公司的宿命：倒閉或轉型 196
倒閉 197
轉型做產品 198
軟體公司老闆的特點 198
招不到靠譜員工 198
留不住人 199
解決辦法 199
