软件开发之殇

软件开发之殇
作 者: 申思维
出版社: 清华大学出版社
丛编项:
版权说明: 本书为出版图书,暂不支持在线阅读,请支持正版图书
标 签: 暂缺
ISBN 出版时间 包装 开本 页数 字数
未知 暂无 暂无 未知 0 暂无

作者简介

  申思维,毕业于华南理工大学计算机软件专业,一直从事于WEB软件开发领域。创立多个软件公司,具有深厚的全栈开发功力,后端技术包括Java Web、Ruby on Rails, H5端技术背景是 Vue、jQuery、CSS, 移动端背景是 Android、iOS。熟悉互联网运维,擅长技术团队的搭建、管理以及人员的培养。对中国软件开发领域以及这个行业的前景和职业规划,有着非常独到的见解。

内容简介

本书作者在软件行业从业、创业多年,对中国的软件开发领域理解非常深刻,对这个行业的前景和职业规划有着非常独到的见解。本书可以让大家知道这个行业整体是什么样的。只有了解了这个行业,才能更好地从事这个行业。 本书分为6章,内容包括程序员的职业规划、给程序员的职业成长建议、给程序员的技术建议、如何管理技术团队、国内软件开发之殇、软件外包公司生存指南。 本书既适合准备从事软件开发的求职者、软件开发从业者、项目经理和软件公司的管理人员阅读,也适合其他想要了解这一行业的人士阅读。

图书目录

目 录

第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