mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-06-16 18:10:13 +08:00
[docs improve]网站图标样式完善&技术文章部分完善
This commit is contained in:
guide
parent
83efb36fb5
commit
7b97616764
@ -8,7 +8,7 @@ export const navbarConfig = defineNavbarConfig([
|
||||
{ text: "技术文章", icon: "article", link: "/high-quality-technical-articles/" },
|
||||
{
|
||||
text: "网站相关",
|
||||
icon: "info",
|
||||
icon: "about",
|
||||
children: [
|
||||
{ text: "走近作者", icon: "zuozhe", link: "/about-the-author/" },
|
||||
{
|
||||
|
||||
@ -1,8 +1,8 @@
|
||||
@font-face {
|
||||
font-family: "iconfont"; /* Project id 2922463 */
|
||||
src: url('iconfont.woff2?t=1655095748938') format('woff2'),
|
||||
url('iconfont.woff?t=1655095748938') format('woff'),
|
||||
url('iconfont.ttf?t=1655095748938') format('truetype');
|
||||
src: url('iconfont.woff2?t=1655098798936') format('woff2'),
|
||||
url('iconfont.woff?t=1655098798936') format('woff'),
|
||||
url('iconfont.ttf?t=1655098798936') format('truetype');
|
||||
}
|
||||
|
||||
.iconfont {
|
||||
@ -13,6 +13,22 @@
|
||||
-moz-osx-font-smoothing: grayscale;
|
||||
}
|
||||
|
||||
.icon-experience:before {
|
||||
content: "\e72b";
|
||||
}
|
||||
|
||||
.icon-code:before {
|
||||
content: "\e7fc";
|
||||
}
|
||||
|
||||
.icon-interview:before {
|
||||
content: "\e65d";
|
||||
}
|
||||
|
||||
.icon-about:before {
|
||||
content: "\e6e5";
|
||||
}
|
||||
|
||||
.icon-search:before {
|
||||
content: "\e7de";
|
||||
}
|
||||
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -54,7 +54,7 @@ export const sidebarConfig = defineSidebarConfig({
|
||||
},
|
||||
{
|
||||
text: "个人经历",
|
||||
icon: "zuozhe",
|
||||
icon: "experience",
|
||||
prefix: "personal-experience/",
|
||||
collapsable: false,
|
||||
children: [
|
||||
@ -62,9 +62,19 @@ export const sidebarConfig = defineSidebarConfig({
|
||||
"8-years-programmer-work-summary",
|
||||
],
|
||||
},
|
||||
{
|
||||
text: "程序员",
|
||||
icon: "code",
|
||||
prefix: "programmer/",
|
||||
collapsable: false,
|
||||
children: [
|
||||
"how-do-programmers-publish-a-technical-book",
|
||||
"efficient-book-publishing-and-practice-guide",
|
||||
],
|
||||
},
|
||||
{
|
||||
text: "面试",
|
||||
icon: "mianshi",
|
||||
icon: "interview",
|
||||
prefix: "interview/",
|
||||
collapsable: false,
|
||||
children: [
|
||||
@ -78,14 +88,17 @@ export const sidebarConfig = defineSidebarConfig({
|
||||
icon: "work",
|
||||
prefix: "work/",
|
||||
collapsable: false,
|
||||
children: ["get-into-work-mode-quickly-when-you-join-a-company"],
|
||||
children: [
|
||||
"get-into-work-mode-quickly-when-you-join-a-company",
|
||||
"employee-performance",
|
||||
],
|
||||
},
|
||||
],
|
||||
// 必须放在最后面
|
||||
"/": [
|
||||
{
|
||||
text: "面试准备",
|
||||
icon: "mianshi",
|
||||
icon: "interview",
|
||||
prefix: "interview-preparation/",
|
||||
collapsable: true,
|
||||
children: [
|
||||
|
||||
@ -5,11 +5,19 @@ tag:
|
||||
- 练级攻略
|
||||
---
|
||||
|
||||
> 普通程序员要想成长为高级程序员甚至是专家等更高级别，应该注意在哪些方面注意加强？
|
||||
> **推荐语** ：普通程序员要想成长为高级程序员甚至是专家等更高级别，应该注意在哪些方面注意加强？开发内功修炼号主飞哥在这篇文章中就给出了七条实用的建议。
|
||||
>
|
||||
> 开发内功修炼号主飞哥在这篇文章中就给出了七条实用的建议。
|
||||
> **内容概览** ：
|
||||
>
|
||||
> 原文：https://mp.weixin.qq.com/s/8lMGzBzXine-NAsqEaIE4g
|
||||
> 1. 刻意加强需求评审能力
|
||||
> 2. 主动思考效率
|
||||
> 3. 加强内功能力
|
||||
> 4. 思考性能
|
||||
> 5. 重视线上
|
||||
> 6. 关注全局
|
||||
> 7. 归纳总结能力
|
||||
>
|
||||
> **原文地址** ：https://mp.weixin.qq.com/s/8lMGzBzXine-NAsqEaIE4g
|
||||
|
||||
### 建议1：刻意加强需求评审能力
|
||||
|
||||
|
||||
@ -5,9 +5,9 @@ tag:
|
||||
- 面试
|
||||
---
|
||||
|
||||
> 经常听到培训班待过的朋友给我说他们的老师是怎么教他们“包装”自己的，不光是培训班，我认识的很多朋友也都会在面试之前“包装”一下自己，所以这个现象是普遍存在的。但是面试官也不都是傻子，通过下面这篇文章来看看面试官是如何甄别应聘者的包装程度。
|
||||
> **推荐语** ：经常听到培训班待过的朋友给我说他们的老师是怎么教他们“包装”自己的，不光是培训班，我认识的很多朋友也都会在面试之前“包装”一下自己，所以这个现象是普遍存在的。但是面试官也不都是傻子，通过下面这篇文章来看看面试官是如何甄别应聘者的包装程度。
|
||||
>
|
||||
> **原文地址** ： https://dwz.cn/mUjRa2Jr
|
||||
> **原文地址** ： https://my.oschina.net/hooker/blog/3014656
|
||||
|
||||
## 前言
|
||||
|
||||
@ -78,7 +78,7 @@ tag:
|
||||
|
||||
**背景公司入职时间、项目立项实现、完工时间、产品技术栈、迭代流程的核实**
|
||||
|
||||
很多应聘者对于简历过于包装，只为了追求更高的薪资。当我们问起：你是 xx 年 xx 月入职的该公司？你们项目是 xx 年 xx 月上线的？你们项目使用到 xx 技术？你们每次上线前夕是如何评审的。面对这些问题，应聘者给出的答案经常与简历不符合。这样问题就来了。关于项目使用到的技术，很多项目我们可以通过搜索该项目的地址、APP。通过 http 协议、技术特征、抛出异常特征来大致判别对方使用到的技术。如果应聘者给出的答案明显与之不匹配，嘿嘿。
|
||||
很多应聘者对于简历过于包装，只为了追求更高的薪资。当我们问起：你是 xx 年 xx 月入职的该公司？你们项目是 xx 年 xx 月上线的？你们项目使用到 xx 技术？你们每次上线前夕是如何评审的。面对这些问题，应聘者给出的答案经常与简历不符合。这样问题就来了。关于项目使用到的技术，很多项目我们可以通过搜索该项目的地址、APP。通过 HTTP 协议、技术特征、抛出异常特征来大致判别对方使用到的技术。如果应聘者给出的答案明显与之不匹配，嘿嘿。
|
||||
|
||||
**通过技术深度，甄别对方的技术水平**
|
||||
|
||||
@ -90,19 +90,19 @@ tag:
|
||||
|
||||
笔者最近接待的面试者，很多面试者的简历上，写着层出不穷的各种技术，为了不跨越求职者的技术栈，笔者专门挑应聘者简历写到或用到的技术来进行询问。笔者举几个例子。
|
||||
|
||||
**1)某求职者简历上写着熟练使用 redis。**
|
||||
**1)某求职者简历上写着熟练使用 Redis。**
|
||||
|
||||
1. 介绍一下你使用过 redis 的哪些数据结构，并描述一下使用的业务场景；
|
||||
2. 介绍一下你操作 redis 用到的是什么插件；
|
||||
1. 介绍一下你使用过 Redis 的哪些数据结构，并描述一下使用的业务场景；
|
||||
2. 介绍一下你操作 Redis 用到的是什么插件；
|
||||
3. 介绍一下你们使用的序列化方式；
|
||||
4. 介绍一下你们使用 redis 遇到过给你印象较深的问题；
|
||||
4. 介绍一下你们使用 Redis 遇到过给你印象较深的问题；
|
||||
|
||||
**2)某求职者声称熟练 http 协议并编写过爬虫。**
|
||||
**2)某求职者声称熟练 HTTP 协议并编写过爬虫。**
|
||||
|
||||
1. 介绍一下你所了解的几个 http head 头并描述其用途；
|
||||
1. 介绍一下你所了解的几个 HTTP head 头并描述其用途；
|
||||
2. 如果前端提交成功，后端无法接受数据，这时候你将如何排查问题；
|
||||
3. 描述一下 http 基本报文结构;
|
||||
4. 如果服务器返回 cookie，存储在响应内容里面 head 头的字段叫做什么;
|
||||
3. 描述一下 HTTP 基本报文结构;
|
||||
4. 如果服务器返回 Cookie，存储在响应内容里面 head 头的字段叫做什么;
|
||||
5. 当服务端返回 Transer-Encoding：chunked 代表什么含义
|
||||
6. 是否了解分段加载并描述下其技术流程。
|
||||
|
||||
@ -110,6 +110,6 @@ tag:
|
||||
|
||||
大体上的套路便是如此：你说你杀过猪。那么你杀过几头猪，分别是啥时候，杀过多大的猪，有啥毛色。事实上对方可能给你的回答是：杀过、十几头、杀过五十斤的、杀过绿色、黄色、红色、蓝色的猪。那么问题就来了。
|
||||
|
||||
然而笔者碰到的问题是：使用 git 两年却不知道 github、使用 redis 一年却不知道数据结构也不知道序列化、专业做爬虫却不懂 content-type 含义、使用搜索引擎技术却说不出两个分词插件、使用数据库读写分离却不知道同步延时等等。
|
||||
然而笔者碰到的问题是：使用 Git 两年却不知道 Github、使用 Redis 一年却不知道数据结构也不知道序列化、专业做爬虫却不懂 `content-type` 含义、使用搜索引擎技术却说不出两个分词插件、使用数据库读写分离却不知道同步延时等等。
|
||||
|
||||
写在最后，笔者认为在招聘途中，并不是不允许求职者包装，但是尽可能满足能筹平衡。虽然这篇文章没有完美的结尾，但是笔者提供了面试失败的各种经验。笔者最终招到了如意的小伙伴。也希望所有技术面试官早日找到符合自己产品发展的 IT 伙伴。
|
||||
|
||||
@ -5,9 +5,9 @@ tag:
|
||||
- 面试
|
||||
---
|
||||
|
||||
> **内容总结：**
|
||||
> **推荐语** ： 从面试官和面试者两个角度探讨了技术面试！非常不错！
|
||||
>
|
||||
> 从面试官和面试者两个角度探讨了技术面试！非常不错！
|
||||
> **内容概览：**
|
||||
>
|
||||
> - 通过技术基础考察候选者，才能考察到候选者的真实技术实力：技术深度和广度。
|
||||
> - 实战与理论结合。比如，候选人叙述 JVM 内存模型布局之后，可以接着问：有哪些原因可能会导致 OOM , 有哪些预防措施? 你是否遇到过内存泄露的问题? 如何排查和解决这类问题?
|
||||
|
||||
@ -5,19 +5,17 @@ tag:
|
||||
- 面试
|
||||
---
|
||||
|
||||
> **内容总结** ：
|
||||
> **推荐语** ：本文的作者，今年 36 岁，已有 8 年 JAVA 开发经验。在阿里云三年半，有赞四年半，已是标准的大龄程序员了。在这篇文章中，作者给出了一些关于面试和个人能力提升的一些小建议，非常实用！
|
||||
>
|
||||
> 本文的作者，今年 36 岁，已有 8 年 JAVA 开发经验。在阿里云三年半，有赞四年半，已是标准的大龄程序员了。
|
||||
>
|
||||
> 下面是本文作者关于面试和个人能力提升的一些小建议（很实用） ：
|
||||
> **内容概览** ：
|
||||
>
|
||||
> 1. 个人介绍，是对自己的一个更为清晰、深入和全面的认识契机。
|
||||
> 2. 简历是充分展示自己的浓缩精华，也是重新审视自己和过往经历的契机。不仅仅是简要介绍技能和经验，更要最大程度凸显自己的优势领域（差异化）。
|
||||
>2. 简历是充分展示自己的浓缩精华，也是重新审视自己和过往经历的契机。不仅仅是简要介绍技能和经验，更要最大程度凸显自己的优势领域（差异化）。
|
||||
> 3. 我个人是不赞成海投的，而倾向于定向投。找准方向投，虽然目标更少，但更有效率。
|
||||
> 4. 技术探索，一定要先理解原理。原理不懂，就会浮于表层，不能真正掌握它。技术原理探究要掌握到什么程度？数据结构与算法设计、考量因素、技术机制、优化思路。要在脑中回放，直到一切细节而清晰可见。如果能够清晰有条理地表述出来，就更好了。技术原理探究，一定要看源码。看了源码与没看源码是有区别的。没看源码，虽然说得出来，但终是隔了一层纸；看了源码，才捅破了那层纸，有了自己的理解，也就能说得更加有底气了。当然，也可能是我缺乏演戏的本领。
|
||||
> 5. 要善于从失败中学习。正是在杭州四个月空档期的持续学习、思考、积累和提炼，以及面试失败的反思、不断调整对策、完善准备、改善原有的短板，采取更为合理的方式，才在回武汉的短短两个周内拿到比较满意的 offer 。
|
||||
> 6. 面试是通过沟通来理解双方的过程。面试中的问题，千变万化，但有一些问题是需要提前准备好的。
|
||||
>
|
||||
>
|
||||
> **原文地址** ：https://www.cnblogs.com/lovesqcc/p/14354921.html
|
||||
|
||||
从每一段经历中学习，在每一件事情中修行。善于从挫折中学习。
|
||||
|
||||
@ -5,15 +5,7 @@ tag:
|
||||
- 个人经历
|
||||
---
|
||||
|
||||
> **《一个中科大差生的 8 年程序员工作总结》** 这篇文章是我上上个星期发现的一篇好文，我刚刚才把它看完。
|
||||
>
|
||||
> 说实话，我对别人的经历还是非常感兴趣的。高中、大学那会，看过了很多人的传记。
|
||||
>
|
||||
> 这篇文章讲述了一位中科大的朋友 8 年的经历：**从 2013 年毕业之后加入上海航天 x 院某卫星研究所，再到入职华为，从华为离职。**
|
||||
>
|
||||
> 除了丰富的经历之外，作者在文章还给出了很多自己对于工作/生活的思考。我觉得非常受用！我在这里，向这位作者表达一下衷心的感谢。
|
||||
>
|
||||
> 我对这篇文章进行了重新排版，在这里分享一下（已经通过微信联系原作者申请了转载权限）！
|
||||
> **推荐语** ：这篇文章讲述了一位中科大的朋友 8 年的经历：从 2013 年毕业之后加入上海航天 x 院某卫星研究所，再到入职华为，从华为离职。除了丰富的经历之外，作者在文章还给出了很多自己对于工作/生活的思考。我觉得非常受用！我在这里，向这位作者表达一下衷心的感谢。
|
||||
>
|
||||
> **原文地址** ：https://www.cnblogs.com/scada/p/14259332.html
|
||||
|
||||
|
||||
@ -5,7 +5,9 @@ tag:
|
||||
- 个人经历
|
||||
---
|
||||
|
||||
> 内容总结：
|
||||
> **推荐语** ：很实用的工作经验分享，看完之后十分受用！
|
||||
>
|
||||
> **内容概览** ：
|
||||
>
|
||||
> - 要学会深入思考，总结沉淀，这是我觉得最重要也是最有意义的一件事。
|
||||
> - 积极学习，保持技术热情。如果我们积极学习，保持技术能力、知识储备与工作年限成正比，这到了 35 岁哪还有什么焦虑呢，这样的大牛我觉得应该也是各大公司抢着要吧？
|
||||
@ -16,7 +18,7 @@ tag:
|
||||
> - 平时积极总结沉淀，多跟别人交流，形成方法论。
|
||||
> - ......
|
||||
>
|
||||
> 原文地址：https://www.nowcoder.com/discuss/351805
|
||||
> **原文地址** ：https://www.nowcoder.com/discuss/351805
|
||||
|
||||
先简单交代一下背景吧，某不知名 985 的本硕，17 年毕业加入滴滴，当时找工作时候也是在牛客这里跟大家一起奋战的。今年下半年跳槽到了头条，一直从事后端研发相关的工作。之前没有实习经历，算是两年半的工作经验吧。这两年半之间完成了一次晋升，换了一家公司，有过开心满足的时光，也有过迷茫挣扎的日子，不过还算顺利地从一只职场小菜鸟转变为了一名资深划水员。在这个过程中，总结出了一些还算实用的划水经验，有些是自己领悟到的，有些是跟别人交流学到的，在这里跟大家分享一下。
|
||||
|
||||
|
||||
@ -0,0 +1,139 @@
|
||||
---
|
||||
title: 程序员高效出书避坑和实践指南
|
||||
category: 技术文章精选集
|
||||
tag:
|
||||
- 程序员
|
||||
---
|
||||
|
||||
> **推荐语** ：详细介绍了程序员出书的一些常见问题，强烈建议有出书想法的朋友看看这篇文章。
|
||||
>
|
||||
> <br/>
|
||||
>
|
||||
> **原文地址** ：https://www.cnblogs.com/JavaArchitect/p/14128202.html
|
||||
|
||||
古有三不朽， 所谓立德、立功、立言。程序员出一本属于自己的书，如果说是立言，可能过于高大上，但终究也算一件雅事。
|
||||
|
||||
出书其实不挣钱，而且从写作到最终拿钱的周期也不短。但程序员如果有一本属于自己的技术书，那至少在面试中能很好地证明自己，也能渐渐地在业内积累自己的名气，面试和做其它事情时也能有不少底气。在本文里，本人就将结合自己的经验和自己踩过的坑，和大家聊聊程序员出书的那些事。
|
||||
|
||||
## 1.出书的稿酬收益和所需要的时间
|
||||
|
||||
先说下出书的收益和需要付出的代价，这里姑且先不谈“出书带来的无形资产”，先谈下真金白银的稿酬。
|
||||
|
||||
如果直接和出版社联系，一般稿酬是版税，是书价格的 8%乘以印刷数（或者实际销售数），如果你是大牛的话，还可以往上加，不过一般版税估计也就 10%到 12%。请注意这里的价格是书的全价，不是打折后的价格。
|
||||
|
||||
比如一本书全价是 70 块，在京东等地打 7 折销售，那么版税是 70 块的 8%，也就是说卖出一本作者能有 5.6 的收益，当然真实拿到手以后还再要扣税。
|
||||
|
||||
同时也请注意合同的约定是支付稿酬的方式是印刷数还是实际销售数，我和出版社谈的，一般是印刷数量，这有什么差别呢？现在计算机类的图书一般是首印 2500 册，那么实际拿到手的钱数是 70*8%*2500，当然还要扣税。但如果是按实际销售数量算的话，如果首印才销了 1800 本的话，那么就得按这个数量算钱了。
|
||||
|
||||
现在一本 300 页的书，定价一般在 70 左右，按版税 8%和 2500 册算的话，税前收益是 14000，税后估计是 12000 左右，对新手作者的话，300 的书至少要写 8 个月，由此大家可以算下平均每个月的收益，算下来其实每月也就 1500 的收益，真不多。
|
||||
|
||||
别人的情况我不敢说，但我出书以后，除了稿酬，还有哪些其它的收益呢？
|
||||
|
||||
- 在当下和之前的公司面试时，告诉面试官我在相关方面出过书以后，面试官就直接会认为我很资深，帮我省了不少事情。
|
||||
- 我还在做线下的培训，我就直接拿我最近出的 Python 书做教材了，省得我再备课了。
|
||||
- 和别人谈项目，能用我的书证明自己的技术实力，如果是第一次和别人打交道，那么这种证明能立杆见效。
|
||||
|
||||
尤其是第一点，其实对一些小公司或者是一些外派开发岗而言，如果候选人在这个方面出过书，甚至都有可能免面试直接录取，本人之前面试过一个大公司的外派岗，就得到过这种待遇。
|
||||
|
||||
## 2.支付稿酬的时间点和加印后的收益
|
||||
|
||||
我是和出版社直接联系出书，支付稿酬的时间点一般是在首印后的 3 个月内拿到首印部分稿酬的一部分（具体是 50%到 90%），然后在图书出版后的一年后再拿到其它部分的稿酬。当下有不少书，能销掉首印的册数就不错了，不过也有不少书能加印，甚至出第二和第三版，一般加印册数的版税会在加印后的半年到一年内结清。
|
||||
|
||||
从支付稿酬的时间点上来，对作者确实会有延迟，外加上稿酬也不算高，相对于作者的辛勤劳动，所以出书真不是挣钱的事，而且拿钱的周期还长。如果个别图书公司工作人员一方面在出书阶段对作者没什么帮助， 另一方面还要在中间再挣个差价，那么真有些作践作者的辛勤劳动了。
|
||||
|
||||
## 3.同图书公司打交道的所见所闻
|
||||
|
||||
在和出版社编辑沟通前，我也和图书公司的工作人员交流过，不少工作人员对我也是比较尊重，交流虽然不算深入，但也算客气。不过最终对比出版社给出的稿酬等条件，我还是没有通过图书公司出书，这也是比较可惜的事情。下面我给出些具体的经历。
|
||||
|
||||
- 我经常在博客园等地收到一些图书公司工作人员的留言，问要不要出书，一般我不问，他们不会说自己是出版社编辑还是图书公司的工作人员。有个别图书公司的工作人员，会向作者，尤其是新手作者，说些“出版社编辑一般不会直接和作者联系”，以及“出书一般是通过图书公司”等的话。其实这些话不能算错，比如你不联系出版社编辑，那么对方自然不会直接联系你，但相反如果作者直接和出版社编辑联系，第一没难度，第二可能更直接。
|
||||
- 我和出版社编辑交流大纲时，即使大纲有不足，他们也能直接给出具体的修改意见，比如某个章节该写什么，某个小节的大纲该怎么写。而我和个别图书公司的工作人员交流过大纲时，得到的反馈大多是“要重写”，怎么个重写法？这些工作人员可能只能给出抽象的意见，什么都要我自己琢磨。在我之前的博文[程序员怎样出版一本技术书](./how-do-programmers-publish-a-technical-book)里，我就给出过具体的经历。
|
||||
- 由于交流不深，所以我没有和图书公司签订过出书协议，但我知道，只有出版社能出书。由于没有经历过，所以我也不知道图书公司在合同里是否有避规风险等条款，但我见过一位图书公司人员人员给出的一些退稿案例，并隐约流露出对作者的责备之意。细思感觉不妥，对接的工作人员第一不能在出问题的第一时间及时发现并向作者反馈，第二在出问题之后不能对应协调最终导致退稿，第三在退稿之后，作者在付出劳动的情况下图书公司不仅不用承担任何风险，并还能指摘作者。对此，退稿固然有作者的因素，但同是作者的我未免有兔死狐悲之谈。而我在出版社出书时，编辑有时候甚至会主动关心，主动给素材，哪怕有问题也会第一时间修改，所以甚至大范围修改稿件的情况都基本没有出现。
|
||||
- 再说下图书公司给作者的稿酬。我见过按页给钱，比如一页 30 到 50 块，并卖断版权，即书重印后作者也无法再得到稿酬，如果是按版税给钱，我也见过给 6%，至于图书公司能否给到 8 个点甚至更高，我没见到过，所以不知道，也不敢擅拟。
|
||||
|
||||
我交流过的图书公司工作人员不多，交流也不深，因为我现在主要是和出版社的编辑交流。所以以上只是我对个别图书公司编辑的感受，我无意以偏概全，而和我交流的一些图书公司工作人员至少态度上对我很尊重。所以大家也可以对比尝试下和图书公司以及出版社合作的不同方式。不管怎样，你在写书甚至在签出书协议前，你需要问清楚如下的事项，并且对方有义务让你了解如下的事实。
|
||||
|
||||
- 你得问清楚，对方的身份是出版社编辑还是图书公司工作人员，这其实应当是对方主动告之。
|
||||
- 你的书在哪个出版社出版？这点需要在出书协议里明确给出，不能是先完稿再定出版社。而且，最终能出版书的，一定是出版社，而不是图书公司。
|
||||
- 稿酬的支付方式，哪怕图书公司中间可能挣差价，但至少你得了解出版社能给到的稿酬。如果你是通过图书公司出的书，不管图书公司怎么和你谈的，但出版社给图书公司的钱一分不会少，中间部分应该就是图书公司的盈利。
|
||||
- 最终和你签订出书合同的，是图书公司还是出版社，这一定得在你签字前搞明白，哪怕你最终是和图书公司签协议，但至少得知道你还能直接和出版社签协议。
|
||||
- 你不能存有“在图书公司出书要求低”的想法，更不应该存有“我能力一般，所以只能在图书公司出书”的想法。图书公司自己是没有资格出书的，所以他们也是会把稿件交给出版社，所以该有的要求一点也不会低。你的大纲在出版社编辑那边通不过，那么在图书公司的工作人员那边同样通不过，哪怕你索要的稿酬少，图书公司方面对应的要求一定也不会降低。
|
||||
|
||||
如果你明知“图书公司和出版社的差别”，并还是和图书公司合作，这个是两厢情愿的事情。但如果对方“不主动告知”，而你在不了解两者差异的基础上同图书公司合作，那么对方也无可指摘。不过兼听则明，大家如果要出书，不妨和出版社和图书公司都去打打交道对比下。
|
||||
|
||||
## 4.如何直接同国内计算机图书的知名出版社编辑联系
|
||||
|
||||
我在清华大学出版社、机械工业出版社、北京大学出版社和电子工业出版社出过书，出书流程也比较顺畅，和编辑打交道也比较愉快。我个人无意把国内出版社划分成三六九等，但计算机行业，比较知名的出版社有清华、机工、电子工业和人邮这四家，当然其它出版社在计算机方面也出版过精品书。
|
||||
|
||||
如何同这些知名出版社的编辑直接打交道？
|
||||
|
||||
- 直接到官网，一般官网上都直接有联系方式。
|
||||
- 你在博客园等地发表文章，会有人找你出书，其中除了图书公司的工作人员外，也有出版社编辑，一般出版社的编辑会直接说明身份，比如我是 xx 出版社的编辑 xx。
|
||||
- 本人也和些出版社的编辑联系过，大家如果要，我可以给。
|
||||
|
||||
那怎么去找图书公司的工作人员？一般不用主动找，你发表若干博文后，他们会主动找你。如果你细问，“您是出版社编辑还是图书公司的编辑”，他们会表明身份，如果你再细问，那么他们可能会站在图书公司的立场上解释出版社和图书公司的差异。
|
||||
|
||||
从中大家可以看到，不管你最终是否写成书，但去找知名出版社的编辑，并不难。并且，你找到后，他们还会进一步和你交流选题。
|
||||
|
||||
## 5.定选题和出书的流程
|
||||
|
||||
这里给出我和出版社编辑交流合作，最终出书的流程。
|
||||
|
||||
第一，联系上出版社编辑后，先讨论选题，你可以选择一个你比较熟悉的方向，或者你愿意专攻的方向，这个方向可以是 java 分布式组件，Spring cloud 全家桶，微服务，或者是 Python 数据分析，机器学习或深度学习等。这方面你如果有扎实的项目经验那最好，如果你当下虽然不熟悉，但你有毅力经过短时间的系统学习确保你写的内容能成系统或者能帮到别人，那么你也可以在这方面出书。
|
||||
|
||||
第二，定好选题方向后，你可以先列出大纲，比如以 Python 数据分析为例，你可以定 12 个章节，第一章讲语法，第二章讲 numpy 类等等，以此类推，你定大纲的时候，可以参考别人书的目录，从而制定你的写作内容。定好大纲以后，你可以和编辑交流，当编辑也认可这个大纲以后，就可以定出版协议。
|
||||
|
||||
对一般作者而言，出版协议其实差不多，稿酬一般是 8 个点，写作周期是和出版社协商，支付周期可能也大同小异，然后出版社会买断这本书的电子以及各种文字的版权。但如果作者是大牛，那么这些细节都可以和出版社协商。
|
||||
|
||||
然后是写书，这是很枯燥的，尤其是写最后几章的时候。我一般是工作日每天用半小时，两天周末周末用 4,5 个小时写，这样一般半年能写完一本 300 页的书，关于高效写书的技巧，后文会详细提及。
|
||||
|
||||
在写书时，一般建议每写好一个章节就交给编辑审阅，这样就不会导致太大问题的出现，而且如果是新手作者，刚开始的措辞和写作技巧都需要积累，这样出版社的编辑在开始阶段也能及时帮到作者。
|
||||
|
||||
当你写完把稿件交到编辑以后，可能会有三校三审的事情，在其中同我合作的编辑会帮助我修改语法和错别字等问题，然后会形成一个修改意见让我确认和修改。我了解下来，如果在图书公司出书，退稿的风险一般就发生在这个阶段，因为图书公司可能是会一次性地把稿件提交给出版社。但由于我会把每个章节都直接提交给出版社编辑审阅，所以即使有大问题，那么在写开始几个章节时都已经暴露并修改，所以最后的修改意见一般不会太长。也就是说，如果是直接和出版社沟通，在三校三审阶段，工作量可能未必大，我一般是在提交一本书以后，由编辑做这个事情，然后我就继续策划并开始写后一本书。
|
||||
|
||||
最后就是拿稿酬，之前已经说了，作者其实不应该对稿酬有太大的期望，也就是聊胜于无。但如果一不小心写了本销量在 5000 乃至 10000 本左右的畅销书，那么可能在一年内也能有 5 万左右的额外收益，并能在业内积累些名气。
|
||||
|
||||
## 6.出案例书比出经验书要快
|
||||
|
||||
对一些作者而言，尤其是新手作者，出书不容易，往往是开始几个章节干劲十足，后面发现问题越积越多，外加工作一忙，就不了了之了，或者用 1 年以上的时间才能完成一本书。对此，我的感受是，一本 300 到 400 书的写作周期最长是 8 个月。为了能在这个时间段里完成一本书，我对应给出的建议是，新手作者可以写案例书，别先写介绍经验类的书。
|
||||
|
||||
什么叫案例书？比如一本书里用一个大案例贯穿，系统介绍一个知识点，比如小程序开发，或者全栈开发等。或者一本书一个章节放一个案例，在一本书里给出 10 个左右 Python 深度学习方面的案例。什么叫经验类书呢？比如介绍面试经验的书就属于这这种，或者一些技术大牛写的介绍分布式高并发开发经验的书也算经验类书。
|
||||
|
||||
请注意这里并没有区分两类书的差异，只是对新手作者而言，案例书好写。因为在其中，更多的是看图说话，先给出案例（比如 Python 深度学习里的图像识别案例），然后通过案例介绍 API 的用法（比如 Python 对应库的用法），以及技术的综合要点（比如如何用 Python 库综合实现图像识别功能）。并且案例书里需要作者主观发挥的点比较少，作者无需用自己的话整理相关的经验。对新手作者而言，在组织文字介绍经验时，可能会有自己明白但说不上来的感觉，这样一方面就无法达到预期的效果，另一方面还有可能因为无法有效表述而导致进度的延迟。
|
||||
|
||||
但相反对于案例书，第一案例一般可以借鉴别人的，第二介绍现存的技术总比介绍自己的经验要容易，第三一般还有同类的书可以供作者参考，所以作者不大需要斟酌措辞，新手作者用半年到八个月的时间也有可能写完一本。当作者通过写几本书积累一定经验后，再去挑战经验类书，在这种情况下，写出来的经验类书就有可能畅销了。
|
||||
|
||||
那么具体而言，怎么高效出一本案例书呢？
|
||||
|
||||
- 对整本书而言，先用少量章节介绍搭建环境和通用基本语法的内容。
|
||||
- 在写每个章节案例时，用到总分总的结构，先总体介绍下你这个案例的需求功能，以及要用的技术点，再分开介绍每个功能点的代码实现，最后再总结下这些功能点的使用要点。
|
||||
- 在介绍案例中具体代码时，也可以用到总分总的结构，即先总体介绍下这段代码的结构，再分别给出关键代码的说明，最后再给出运行效果并综述其中技术的实现要点。
|
||||
|
||||
这样的话，刚开始可以是 1 个月一个章节，写到后面熟练以后估计一个月能写两个章节，这样 8 个月完成一本书，也就不是不可能了。
|
||||
|
||||
## 7.如何在参考现有内容的基础上避免版权问题
|
||||
|
||||
写书时，一般多少都需要参考现有的代码和现有的书，但这绝不是重复劳动。比如某位作者整合了不同网站上多个案例，然后系统地讲述了 Python 数据分析，这样虽然现成资料都有，但对读者来说，就能一站式学习。同样地，比如在 Python 神经网络方面，现有 2,3 本书分别给出了若干人脸识别等若干案例，但如果你有效整合到一起，并加他人的基础上加上你的功能，那对读者来说也是有价值的。
|
||||
|
||||
这里就涉及到版权问题，先要说明，作者不能抱有任何幻想，如果出了版权问题，书没出版还好，如果已经出版了，作者不仅要赔钱，而且在业内就会有不好的名声，可谓身败名裂。但其实要避免版权问题一点也不难。
|
||||
|
||||
- 不能抄袭网上现有的内容，哪怕一句也不行。对此，作者可以在理解人家语句含义的基础上改写。不能抄袭人家书上现有的目录，更不能抄袭人家书上的话，同样一句也不行，对应的解决方法同样是在理解的基础上改写。
|
||||
- 不能抄袭 Github 上或者任何地方别人的代码，哪怕这个代码是开源的。对此，你可以在理解对方代码的基础上，先运行通，然后一定得自己新建一个项目，在你的项目里参考别人的代码实现你的功能，在这个过程中不能有大段的复制粘贴操作。也就是说，你的代码和别人的代码，在注释，变量命名，类名和方法名上不能有雷同的地方，当然你还可以额外加上你自己的功能。
|
||||
- 至于在写技术和案例介绍时，你就可以用你自己的话来说，这样也不会出现版权问题。
|
||||
|
||||
用了上述办法以后，作者就可以在参考现有资料的基础上，充分加上属于你的功能，写上你独到的理解，从而高效地出版属于你自己的书。
|
||||
|
||||
## 8.新手作者需要着着重避免的问题
|
||||
|
||||
在上文里详细给出了出书的流程，并通过案例书，给出了具体的习作方法，这里就特别针对新手作者，给出些需要注意的实践要点。
|
||||
|
||||
- 技术书不同于文艺书，在其中首先要确保把技能知识点讲清楚，然后再此基础上可以适当加上些风趣生动的措辞。所以对新手作者而言，甚至可以直接用朴素的文字介绍案例技术，而无需过多考虑文字上的生动性。
|
||||
- 内容需要针对初学者，在介绍技术时，从最基本的零基础讲起，别讲太深的。这里以 Python 机器学习为例，可以从什么是机器学习以及 Python 如何实现机器学习讲起，但如果首先就讲机器学习里的实践经验，就未必能确保初学者能学会。
|
||||
- 新手作者恨不得把自己知道的都写出来。这种态度非常好，但需要考虑读者的客观接受水平所以需要在写书前设置个预期效果，比如零基础的 Python 开发人员读了我的书以后至少能干活。这个预期效果别不可行，比如不能是“零基础的 Python 开发人员读了我书以后能达到 3 年开发的水准”。这样就可以根据预先制定的效果，制定写作内容，从在你的书就能更着重讲基础知识，这样读者就能有真正有收获。
|
||||
|
||||
不过话说回来，如果新手作者直接和出版社编辑联系，找个热门点的方向，并根据案例仔细讲解技术，甚至都有可能写出销量过万的畅销书。
|
||||
|
||||
## 9.总结：在国内知名出版社出书，其实是个体力活
|
||||
|
||||
可能当下，写公众号和录视频等的方式，挣钱收益要高于出书，不过话可以这样说，经营公众号和录制视频也是个长期的事情，在短时间里可能未必有收益，如果不是系统地发表内容的话，可能甚至不会有收益。所以出书可能是个非常好的前期准备工作，你靠出书系统积累了素材，靠出书整合了你的知识体系，那么在此基础上，靠公众号或者录视频挣钱可能就会事半功倍。
|
||||
|
||||
从上文里大家可以看到，在出书前期，联系出版社编辑和定选题并不难，如果要写案例书，那么在参考别人内容的基础上，要写完一般书可能也不是高不可攀的事情。甚至可以这样说，出书是个体力活，只要坚持，要出本书并不难，只是你愿不愿意坚持下去的问题。但一旦你有了属于自己的技术书，那么在找工作时，你就能自信地和面试官说你是这方面的专家，在你的视频、公众号和文字里，你也能正大光明地说，你是计算机图书的作者。更为重要的是，和名校、大厂经历一样，属于你的技术书同样是证明程序员能力的重要证据，当你通过出书有效整合了相关方面的知识体系后，那么在这方面，不管是找工作，或者是干私活，或者是接项目做，你都能理直气壮地和别人说：我能行！
|
||||
@ -0,0 +1,92 @@
|
||||
---
|
||||
title: 程序员怎样出版一本技术书
|
||||
category: 技术文章精选集
|
||||
tag:
|
||||
- 程序员
|
||||
---
|
||||
|
||||
> **推荐语** ：详细介绍了程序员应该如何从头开始出一本自己的书籍。
|
||||
>
|
||||
> <br/>
|
||||
>
|
||||
> **原文地址** ：https://www.cnblogs.com/JavaArchitect/p/12195219.html
|
||||
|
||||
在面试或联系副业的时候，如果能令人信服地证明自己的实力，那么很有可能事半功倍。如何证明自己的实力？最有信服力的是大公司职位背景背书，没有之一，比如在 BAT 担任资深架构，那么其它话甚至都不用讲了。
|
||||
|
||||
不过，不是每个人入职后马上就是大公司架构师，在上进的路上，还可以通过公众号，专栏博文，Github 代码量和出书出视频等方式来证明自己。和其它方式相比，属于自己的技术图书由于经过了国家级出版社的加持，相对更能让别人认可自己的实力，而对于一些小公司而言，一本属于自己的书甚至可以说是免面试的通行证。所以在本文里，就将和广大程序员朋友聊聊出版技术书的那些事。
|
||||
|
||||
## 1.不是有能力了再出书，而是在出书过程中升能力
|
||||
|
||||
我知道的不少朋友，是在工作 3 年内出了第一本书，有些优秀的，甚至在校阶段就出书了。
|
||||
|
||||
与之相比还有另外一种态度，不少同学可能想，要等到技术积累到一定程度再写。其实这或许就不怎么积极了，边写书，边升技术，而且写出的书对人还有帮助，这绝对可以做到的。
|
||||
|
||||
比如有同学向深入了解最近比较热门的 Python 数据分析和机器学习，那么就可以在系统性的学习之后，整理之前学习到的爬虫，数据分析和机器学习的案例，根据自己的理解，用适合于初学者的方式整理一下，然后就能出书了。这种书，对资深的人帮助未必大，但由于包含案例，对入门级的读者绝对有帮助，因为这属于现身说法。而且话说回来，如果没有出书这个动力，或者学习过程也就是浅尝辄止，或者未必能全身心地投入，有了出书这个目标，更能保证学习的效果。
|
||||
|
||||
## 2.适合初级开发，高级开发和架构师写的书
|
||||
|
||||
之前也提到了，初级开发适合写案例书，就拿 Python 爬虫数据分析机器学习题材为例，可以先找几本这方面现成的书，这些书里，或者章节内容不同，但一起集成看的话，应该可以包含这方面的内容。然后就参考别人书的思路，比如一章写爬虫，一章写 pandas，一章写 matplotlib 等等，整合起来，就可以用 若干个章节构成一本书了。总之，别人书里包含什么内容，你别照抄，但可以参考别人写哪些技术点。
|
||||
|
||||
定好章节后，再定下每个章节的小节，比如第三章讲爬虫案例，那么可以定 3.1 讲爬虫概念，3.2 讲如何搭建 Scrapy 库，3.3 讲如何开发 Scrapy 爬虫案例，通过先章再节的次序，就可以定好一本书的框架。由于是案例书，所以是先给运行通的代码，再用这些代码案例教别人入门，所以案例未必很深，但需要让初学者看了就能懂，而且按照你给出的知识体系逐步学习之后，能理解这个主题的内容。并且，能在看完你这本书以后，能通过调通你给出的爬虫，机器学习等的案例，掌握这一领域的知识，并能从事这方面的基本开发。这个目标，对初级开发而言，稍微用点心，费点时间，应该不难达到。
|
||||
|
||||
而对于高级开发和架构师而言，除了写存粹案例书以外，还可以在书里给出你在大公司里总结出来的开发经验，也就是所谓踩过的坑，比如 Python 在用 matplotlib 会图例时，在设置坐标轴方面有哪些技巧，设置时会遇到哪些常见问题，如果在书里大量包含这种经验，你的书含金量更高。
|
||||
|
||||
此外，高级开发和架构师还可以写一些技术含量更高的书，比如就讲高并发场景下的实践经验，或者 k8s+docker 应对高并发的经验，这种书里，可以给出代码，更可以给出实施方案和架构实施技巧，比如就讲高并发场景里，缓存该如何选型，如何避免击穿，雪崩等场景，如何排查线上 redis 问题，如何设计故障应对预案。除了这条路之外，还可以深入细节，比如通过讲 dubbo 底层代码，告诉大家如何高效配置 dubbo，出了问题该如何排查。如果架构师或高级开发有这类书作为背书，外带大厂工作经验，那么就更可以打出自己的知名度。
|
||||
|
||||
## 3.可以直接找出版社，也可以找出版公司
|
||||
|
||||
在我的这篇博文里，[程序员副业那些事：聊聊出书和录视频](https://www.cnblogs.com/JavaArchitect/p/11616906.html)，给出了通过出版社出书和图书公司出书的差别，供大家参考，大家看了以后可以自行决定出书方式。
|
||||
|
||||
不过不管怎么选，在出书前你得搞明白一些事，或许个别图书出版公司的工作人员不会主动说，这需要你自己问清楚。
|
||||
|
||||
- 你的合作方是谁？图书出版公司还是出版社？
|
||||
- 你的书将在哪个出版社出版？国内比较有名的是清华，人邮，电子和机械，同时其它出版社不能说不好，但业内比较认这四个。
|
||||
- 和你沟通的人，是最终有决定权的图书编辑吗？还是图书公司里的工作人员？再啰嗦下，最后能决定书能否出版，以及确定修改意见的，是出版社的编辑。
|
||||
|
||||
通过对比出版社和图书出版公司，在搞清楚诸多细节后，大家可以自己斟酌考虑合作的方式。而且，出版社和图书公司的联系方式，在官网上都有，大家可以自行通过邮件等方式联系。
|
||||
|
||||
## 4.如果别人拿你做试错对象，或有不尊重，赶紧止损
|
||||
|
||||
我之前看到有图书出版公司招募面向 Java 初学者图书的作者，并且也主动联系过相关人员，得到的反馈大多是：“要重写”。
|
||||
|
||||
比如我列了大纲发过去，反馈是“要重写”，原因是对方没学过 Java，但作为零基础的人看了我的大纲，发现学不会。至于要重写成什么样子 ，对方也说不上来，总之让我再给个大纲，再给一版后，同样没过，这次好些，给了我几本其它类似书的大纲，让我自行看别人有什么好的点。总之不提（或者说提不出）具体的改进点，要我自行尝试各种改进点，试到对方感觉可以为止。
|
||||
|
||||
相比我和几位出版社专业的编辑沟通时，哪怕大纲或稿件有问题，对方会指明到点，并给出具体的修改意见。我不知道图书出版公司里的组织结构，但出版社里，计算机图书有专门的部门，专门的编辑，对方提出的意见都是比较专业，且修改起来很有操作性。
|
||||
|
||||
另外，我在各种渠道，时不时看到有图书出版公司的人员，晒出别人交付的稿件，在众目睽睽之下，说其中有什么问题，意思让大家引以为戒。姑且不论这样做的动机，并且这位工作人员也涂掉了能表面作者身份的信息。但作者出于信任把稿件交到你手上，在不征得作者同意就公开稿件，说“不把作者当回事”，这并不为过。不然，完全可以用私信的方式和作者交流，而不是把作者无心之过公示于众。
|
||||
|
||||
我在和出版社合作时，这类事绝没发生过，而且我认识的出版社编辑，都对各位作者保持着足够的尊重。而且我和我的朋友和多位图书出版公司的朋友交流时，也能得到尊重和礼遇。所以，如果大家在写书时，尤其在写第一本书时，如果遇到被试错，或者从言辞等方面感觉对方不把你当会事，那么可以当即止损。其实也没有什么“损失”，你把当前的大纲和稿件再和出版社编辑交流时，或许你的收益还能提升。
|
||||
|
||||
## 5.如何写好 30 页篇幅的章节？
|
||||
|
||||
在和出版社定好写作合同后，就可以创作了。书是由章节构成，这里讲下如何构思并创作一个章节。
|
||||
|
||||
比如写爬虫章节，大概 30 页，先定节和目，比如 3.1 搭建爬虫环境是小节，3.1.1 下载 Python Scrapy 包，则是目。先定要写的内容，具体到爬虫小节，可以写 3.1 搭建环境，3.2 Scrapy 的重要模块，3.3 如何开发 Scrapy 爬虫，3.4 开发好以后如何运行，3.5 如何把爬到的信息放入数据库，这些都是小节。
|
||||
|
||||
再具体到目，比如 3.5 里，3.5.1 里写如何搭建数据库环境 3.5.2 里写如何在 Scrapy 里连接数据库 3.5.3 里给出实际案例 3.5.4 里给出运行步骤和示例效果。
|
||||
|
||||
这样可以搭建好一个章的框架，在每个小节里，先给出可以运行通的，而且能说明问题的代码，再给出对代码的说明，再写下代码如何配置，开发时该注意哪些问题，必要时用表格和图来说明，用这样的条理，最多 3 个星期可以完成一个章节，快的话一周半就一个章节。
|
||||
|
||||
以此类推，一本书大概有 12 个章节，第一章可以讲如何安装环境，以及基础语法，后面就可以由浅入深，一个章节一个主题，比如讲 Python 爬虫，第二章可以是讲基础语法，第三章讲 http 协议以及爬虫知识点，以此深入，讲全爬虫，数据分析，数据展示和机器学习等技能。
|
||||
|
||||
按这样算，如果出第一本书，平均下来一个月 2 个章节，大概半年到八个月可以完成一本书，思路就是先搭建书的知识体系，写每个章节时再搭建某个知识点的框架，在小节和目里，用代码结合说明的方式，这样从简到难，大家就可以完成第一本属于自己的书了。
|
||||
|
||||
## 6.如何写出一本销量过 5 千的书
|
||||
|
||||
目前纸质书一般一次印刷在 2500 册，大多数书一般就一次印刷，买完为止。如果能销调 5000 本，就属于受欢迎了，如果销量过万，就可以说是大神级书的。这里先不论大神级书，就说下如何写一本过 5000 的畅销书。
|
||||
|
||||
1 最好贴近热点，比如当前热点是全栈开发和机器学习等，如何找热点，就到京东等处去看热销书的关键字。具体操作起来，多和出版社编辑沟通，或许作者更多是从技术角度分析，但出版社的编辑是从市场角度来考虑问题。
|
||||
|
||||
2 如果你的书能被培训机构用作教材，那想不热都不行。培训机构一般用哪些教材呢？第一面向初学者，第二代码全面，第三在这个领域里涵盖知识点全。如果要达成这点，大家可以和出版社的编辑直接沟通，问下相关细节。
|
||||
|
||||
3 可以文字生动，但不能用过于花哨的文字来掩盖书的内涵不足，也就是说畅销书一定要有干货，能解决初学者实际问题，比如 Python 机器学习方向，就写一本用案例涵盖目前常用的机器学习算法，一个章节一种算法，并且案例中有可视化，数据分析，爬虫等要素，可视化的效果如果再吸引人，这本书畅销的可能性也很大。
|
||||
|
||||
4 一定不能心存敷衍，代码调通不算，更力求简洁，说明文字多面向读者，内容上，确保读者一看就会，而且看了有收获，或许这点说起来很抽象，但我写了几本书以后切身体会，要做到这很难，同时做到了，书哪怕不畅想，但至少不误人子弟。
|
||||
|
||||
## 7.总结，出书仅是一个里程碑，程序员在上进路上应永不停息
|
||||
|
||||
出书不简单，因为不是每个人都愿意在半年到八个月里，每个晚上每个周末都费时费力写书。但出书也不难，毕竟时间用上去了，出书也只是调试代码加写文字的活，最多再外加些和人沟通的成本。
|
||||
|
||||
其实出书收益并不高，算下来月入大概能在 3k 左右，如果是和图书出版公司合作，估计更少，但这好歹能证明自己的实力。不过在出书后不能止步于此，因为在大厂里有太多的牛人，甚至不用靠出书来证明自己的实力。
|
||||
|
||||
那么如何让出书带来的利益最大化呢？第一可以靠这进大厂，面试时有自己的书绝对是加分项。第二可以用这个去各大网站开专栏，录视频，或者开公众号，毕竟有出版社的背书，能更让别人信服你的能力。第三更得用写书时积累的学习方法和上进的态势继续专研更高深技术，技术有了，不仅能到大厂挣更多的钱，还能通过企业培训等方式更高效地挣钱。
|
||||
@ -0,0 +1,132 @@
|
||||
---
|
||||
title: 聊聊大厂的绩效考核
|
||||
category: 技术文章精选集
|
||||
tag:
|
||||
- 工作
|
||||
---
|
||||
|
||||
> **内容概览** ：
|
||||
>
|
||||
> - 在大部分公司，绩效跟你的年终奖、职级晋升、薪水涨幅等等福利是直接相关的。
|
||||
> - 你的上级、上上级对你的绩效拥有绝对的话语权，这是潜规则，放到任何公司都是。成年人的世界，没有绝对的公平，绩效考核尤为明显。
|
||||
> - 提升绩效的打法：
|
||||
> - 短期打法：找出 1-2 件事，体现出你的独特价值（抓关键事件）。
|
||||
> - 长期打法：通过一步步信任的建立，成为团队的核心人员或者是老板的心腹，具备不可替代性。
|
||||
>
|
||||
> <br/>
|
||||
>
|
||||
> **原文地址** ：https://mp.weixin.qq.com/s/D1s8p7z8Sp60c-ndGyh2yQ
|
||||
|
||||
在新公司度过了一个完整的 Q3 季度，被打了绩效，也给下属打了绩效，感慨颇深。
|
||||
|
||||
今天就好好聊聊**大厂打工人最最关心的「绩效考核」**，谈谈它背后的逻辑以及潜规则，摸清楚了它，你在大厂这片丛林里才能更好的生存下去。
|
||||
|
||||
## 大厂的绩效到底有多重要？
|
||||
|
||||
先从公司角度，谈谈为什么需要绩效考核？
|
||||
|
||||
有一个著名的管理者言论，即：企业战略的上三路和下三路。
|
||||
|
||||
> 上三路是使命、愿景、价值观，下三路是组织、人才、KPI。下三路需要确保上三路能执行下去，否则便是空谈。那怎么才能达成呢？
|
||||
|
||||
马老板在湖畔大学的课堂上，对底下众多 CEO 学员说，“只能靠 KPI。没有 KPI，一切都是空话，组织和公司是不会进步的”。
|
||||
|
||||
所以，KPI 一般是用来承接企业战略的。身处大厂的打工者们，也能深深感受到：每个季度的 KPI 是如何从大 Boss、到 Boss、再到基层，一层层拆解下来的，最终让所有人朝着一个方向行动，这便是 KPI 对于公司的意义。
|
||||
|
||||
然鹅，并非每个员工都会站在 CEO 的高度去理解 KPI 的价值，大家更关注的是 KPI 对于我个人来说到底有什么意义？
|
||||
|
||||
在互联网大厂，每家公司都会设定一套绩效考核体系，字节用的是 OKR，阿里用的是 KPI，通常都是「271」 制度，即 ：
|
||||
|
||||
> 20% 的比例是 A+ 和 A，对应明星员工。
|
||||
>
|
||||
> 70% 的比例是 B，对应普通员工。
|
||||
>
|
||||
> 10% 的比例是 C 和 C-，对应需要绩效改进或者淘汰的员工。
|
||||
|
||||
有了三六九等，然后才有了利益分配。
|
||||
|
||||
**在大厂，绩效结果跟奖金、晋升、薪水涨幅、股票授予是直接相关的。在内卷的今天，甚至可以直接划上等号。**
|
||||
|
||||
绩效好的员工，奖金必然多，一年可能调薪两次，晋升答辩时能 PK 掉绩效一般的人，职级低的人甚至可以晋升免试。
|
||||
|
||||
而绩效差的人，有可能一年白干，甚至走人（大厂的末尾淘汰是不成文的规定）。
|
||||
|
||||
总之，你能想到的直接利益都和「绩效」息息相关。所以，在大厂这片高手众多的丛林里，多琢磨下绩效背后的逻辑，既是生存之道，更是一技之长。
|
||||
|
||||
## 你是怎么看待绩效的？
|
||||
|
||||
凡是用来考核人的规则，大部分人在潜意识里都想去突破它，而不是被束缚。
|
||||
|
||||
至少在我刚工作的前几年，看着身边有些同事因为背个 C 黯然离开的时候，觉得绩效考核就是一个冷血的管理工具。
|
||||
|
||||
尤其遇到自己看不上的领导时，对于他给我打的绩效，其实也是很不屑的。
|
||||
|
||||
到今天，实在见过太多的反面案例了，自己也踩过一些坑，逐渐认识到：当初的想法除了让自己心里爽一点，好像起不到任何作用，甚至会让我的工作方式变形。
|
||||
|
||||
当思维方式变了，也就改变了我对绩效的态度，至少有两点我认为是打工人需要看清的。
|
||||
|
||||
**第一，你的上级、上上级对你的绩效拥有绝对的话语权，这是潜规则，放到任何公司都是。**
|
||||
|
||||
大家可以去看看身边发展特别好的人，除了有很强的个人能力以外，几乎都是善于利用规则，而不是去挑战规则的人。
|
||||
|
||||
当然，我并不是说你要一味地去跪舔你的领导，而是表达：工作中不要站在领导的对立面去做对抗，如果领导做法很过分，要么直接沟通去影响他，要么选择离开。
|
||||
|
||||
**第二，成年人的世界，没有绝对的公平，绩效考核尤为明显。**
|
||||
|
||||
我所待过的团队，绩效考核还是相对公平的，虽然也存在受照顾的情况，但都是个例。
|
||||
|
||||
另外就是，技术岗的绩效考核不同于销售或者运营岗，很容易指标化。
|
||||
|
||||
需求吞吐量、BUG数、线上事故... 的确有一大堆研发效能指标，但这些指标在绩效考核时是否会被参考？具体又该如何分配比重？本身就是一个扯不清楚的难题。
|
||||
|
||||
最终决定你绩效结果的还是你领导的主观判断。你所见到的 360 环评，以及弄一些指标排序，这些都只是将绩效结果合理化的一种方式，并非关键所在。
|
||||
|
||||
因此，多琢磨如何去影响你的领导？站在他的视角去审视他在绩效考核时到底关注哪些核心点？这才是至关重要的。
|
||||
|
||||
上面讲了一堆潜规则，是不是意味着绩效考核是可以投机取巧，完全不看工作业绩呢，当然不是。
|
||||
|
||||
“你的努力不一定会被看见” 、“你的努力应该有的放矢”，大家先记住这两条。
|
||||
|
||||
下面我再展开聊聊，大家最最关心的 A 和 C，它们背后的逻辑。
|
||||
|
||||
## 绩效被打A和C的逻辑是什么？
|
||||
|
||||
“铆足了劲拿不到 A，一不留神居然拿了个 C”，这是绝大多数打工人最真实的职场现状。
|
||||
|
||||
A 和 C 属于绩效的两个极端，背后的逻辑类似，反着理解即可，下面我详细分析下 C。
|
||||
|
||||
先从我身边人的情况说起，我所看到的案例绝大多数都属于：绩效被打了 C，完全没有任何预感，主管跟他沟通结果时，还是一脸懵逼，“为什么会给我打 C？一定是黑我呀！”。
|
||||
|
||||
前阵子听公司一位大佬分享，用他的话说，这种人就是没有「角色认知」，他不知道他所处的角色和职级该做好哪些事？做成什么样才算「做好了」？被打 C 后自然觉得是在背锅。
|
||||
|
||||
所以，务必确保你对于当前角色是认知到位的，这样才称得上进入了「工作状态」，否则你的一次松懈，一段不太好的表现，很可能导致 C 落在你的头上，岗位越高，摔得越重。
|
||||
|
||||
有了角色认知，再说下对绩效的认知。
|
||||
|
||||
第一，团队很优秀，是不是不用背 C？不是！大厂的 C 都是强制分配的，再优秀的团队也会有 C。所以团队越厉害，竞争越惨烈。
|
||||
|
||||
第二，完成了 KPI，没有工作失误，是不是就万事大吉，不用背 C？不是，绩效是相对的，你必须清楚你在团队所处的位置，你在老板眼中的排序，慢慢练出这种嗅觉。
|
||||
|
||||
懂了上面这些道理，很自然就能知道打 C 的逻辑，C 会集中在两类人上：
|
||||
|
||||
> 1、工作表现称不上角色要求的人。
|
||||
>
|
||||
> 2、在老板眼里排序靠后，就算离开，对团队影响也很小的人。
|
||||
|
||||
要规避 C，有两种打法。
|
||||
|
||||
第 1 种是短期打法：抓关键事件，能不能找出 1-2 件事，体现出你的独特价值（比如本身影响力很大的项目，或者是领导最重视的事），相当于让你的排序有了最基本的保障。
|
||||
|
||||
这种打法，你不能等到评价时再去改变，一定是在前期就抓住机会，承担起最有挑战的任务，然后全力以赴，做好了拿 A，不弄砸也不至于背 C，就怕静水潜流，躺平了去工作。
|
||||
|
||||
第 2 种是长期打法：通过一步步信任的建立，成为团队的核心人员或者是老板的心腹，具备不可替代性。
|
||||
|
||||
上面两种打法都是大的思路，还有很多锦上添花的技巧，比如：加强主动汇报（抹平领导的信息差）、让关键干系人给你点赞（能影响到你领导做出绩效决策的人）。
|
||||
|
||||
## 写在最后
|
||||
|
||||
有人的地方就有江湖，有江湖就一定有规则，大厂平面看似平静，其实在绩效考核、晋升等利益点面前，都是一场厮杀。
|
||||
|
||||
当大家攻山头的能力都很强时，**到底做成什么样才算做好了？**当你弄清楚了这个玄机，职场也就看透了。
|
||||
|
||||
如果这篇文章让你有一点启发，来个点赞和在看呀！我是武哥，我们下期见！
|
||||
@ -5,9 +5,9 @@ tag:
|
||||
- 工作
|
||||
---
|
||||
|
||||
> 强烈建议每一位即将入职/在职的小伙伴看看这篇文章，看完之后可以帮助你少踩很多坑。整篇文章逻辑清晰，内容全面！
|
||||
> **推荐语** ：强烈建议每一位即将入职/在职的小伙伴看看这篇文章，看完之后可以帮助你少踩很多坑。整篇文章逻辑清晰，内容全面！
|
||||
>
|
||||
> 我对原文进行了内容和排版完善。
|
||||
> <br/>
|
||||
>
|
||||
> **原文地址** ：https://www.cnblogs.com/hunternet/p/14675348.html
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user