├── README.md ├── SUMMARY.md ├── about-functional-programming ├── essence-of-programs.md ├── javascript-functional-parts.md ├── this-features-make-language-difference.md └── why-i-broke-up-with-oop.md ├── about-web-dev ├── choose-programming-languages.md ├── good-understanding-keeps-design-simple.md ├── how-to-evaluate.md ├── principle-of-hurt-once.md ├── problems-in-software-dev.md ├── put-codes-in-right-place.md ├── split-big-problems.md ├── testing.md ├── upgrade-dependencies.md └── why-agile-development-works.md ├── creating-a-great-web-team ├── bian-cheng-shi-yi-zhong-ji-neng.md ├── great-team-cannot-live-without-code-review.md ├── product-released-email.md └── recruiting.md ├── personal-development ├── making-excellent-resume.md └── prefer-good-search-engine.md └── web-dev ├── kill-your-job.md ├── seek-answers-in-specifications.md ├── untitled.md ├── web-dev-vs-frontend-dev.md └── you-need-casual-projects.md /README.md: -------------------------------------------------------------------------------- 1 | # 前言 2 | 3 | 这将会是一本书，书名暂定《函数式 Web 开发随想录》，我们会在这里记录一些思考 —— 关于软件开发（尤其是 Web 开发领域）的思考。 4 | 5 | 软件行业非常朝气蓬勃，UNIX 时间戳 0 的时间是 1970 年 1 月 1 日，距今才 40 多年。40 年间，各种技术不断涌现，很多事情已经焕然一新。然而行业中的智慧，却未像技术一样不断被超越。软件，目前毕竟还是由人来开发为主，依旧受制于人脑的物理限制。人脑的表现在这些年（甚至数千年）并没有巨大的改变。 6 | 7 | 也许未来 AI 终究会代替人去进行软件开发，但如果基于「由人开发软件」这个目前的条件，**如何进行更好的软件开发**，依旧是一个值得探索的问题。 8 | 9 | ## 什么是正确的 Web 开发方式？ 10 | 11 | 很多人认为这个问题没有答案，因为「正确」很难被定义。确实如此，如果我们没有理解问题，就很难得到答案。 12 | 13 | 但是，如果我们定义「正确」代表着： 14 | 15 | 1. 总是能交付价值，通过软件运行来帮助他人 16 | 2. 总是能持续找到成本最低的方式实现需求 17 | 3. 总是能以较低的成本去维护一个长期运行的软件 18 | 4. 无论是通过培养或招聘，总是能找到胜任的工程师 19 | 20 | 那么，是否存在确定的一些方法呢？ 21 | 22 | **我们相信答案是肯定的。** 这个信念指引我们不断去实验、学习和思考，寻找 Web 开发的最佳实践。在这个过程中，我们积累了一些经验总结。回顾这段历程，我们发现这些经验总结也对一些同行有用，因此选择公开出来，与大家一起交流讨论。这就是本书的初衷。 23 | 24 | ## 本书的受众 25 | 26 | 本书的读者群更面向有一定开发经验的软件开发工程师, 除了 Web 开发，相信其他领域的开发工程师也可以从中找到可以印证的观点。 27 | 28 | 本书中的观点大多来自多年的实践总结，一般来说经过了一定的抽象，变成了一些箴言或是原则，需要配合实践才能很好地理解，有些内容可能不是很适合新手程序员。如果你恰好是刚刚入门编程，我很赞赏，但是切莫在没有理解箴言的情况下当做教条去执行，相反，你可能需要的是更明确的、来自导师的指令。 29 | 30 | -------------------------------------------------------------------------------- /SUMMARY.md: -------------------------------------------------------------------------------- 1 | # Table of contents 2 | 3 | * [前言](README.md) 4 | 5 | ## 软件开发 6 | 7 | * [软件开发的困难](about-web-dev/problems-in-software-dev.md) 8 | * [如何选择编程语言](about-web-dev/choose-programming-languages.md) 9 | * [代码库的划分](about-web-dev/put-codes-in-right-place.md) 10 | * [问题拆解](about-web-dev/split-big-problems.md) 11 | * [理解你的需求，是简洁设计的秘密](about-web-dev/good-understanding-keeps-design-simple.md) 12 | * [「受一次伤」原则](about-web-dev/principle-of-hurt-once.md) 13 | * [如何准确评估开发工作量](about-web-dev/how-to-evaluate.md) 14 | * [自动化测试](about-web-dev/testing.md) 15 | * [依赖包升级策略](about-web-dev/upgrade-dependencies.md) 16 | * [敏捷开发为什么能生效](about-web-dev/why-agile-development-works.md) 17 | 18 | ## 关于函数式编程 19 | 20 | * [程序的本质](about-functional-programming/essence-of-programs.md) 21 | * [为什么我和 OOP 分手了](about-functional-programming/why-i-broke-up-with-oop.md) 22 | * [这些特性让编程语言如此不同](about-functional-programming/this-features-make-language-difference.md) 23 | * [Javascript是个混血儿](about-functional-programming/javascript-functional-parts.md) 24 | 25 | ## Web 开发 26 | 27 | * [「Web 开发」和「前端开发」](web-dev/web-dev-vs-frontend-dev.md) 28 | * [关于认知](web-dev/untitled.md) 29 | * [追求：让自己失业](web-dev/kill-your-job.md) 30 | * [你需要有一些业余项目](web-dev/you-need-casual-projects.md) 31 | * [在 Web 规范中寻找答案](web-dev/seek-answers-in-specifications.md) 32 | 33 | ## 团队 34 | 35 | * [编程是一种技能](creating-a-great-web-team/bian-cheng-shi-yi-zhong-ji-neng.md) 36 | * [没有 Code Review 就没有好团队](creating-a-great-web-team/great-team-cannot-live-without-code-review.md) 37 | * [关于招聘](creating-a-great-web-team/recruiting.md) 38 | * [项目上线邮件](creating-a-great-web-team/product-released-email.md) 39 | 40 | ## 个人发展 41 | 42 | * [写一封彰显实力而不失优雅的简历](personal-development/making-excellent-resume.md) 43 | * [Prefer Good Search Engine](personal-development/prefer-good-search-engine.md) 44 | 45 | -------------------------------------------------------------------------------- /about-functional-programming/essence-of-programs.md: -------------------------------------------------------------------------------- 1 | # 程序的本质 2 | 3 | 价值：「程序 = 计算过程 = 数据 + 处理逻辑」，传递我们基于这个认识的一些原则。 4 | 5 | 1. 相比算法，数据结构设计更重要 6 | 2. 提升处理逻辑的可靠性、可复用性 7 | 8 | -------------------------------------------------------------------------------- /about-functional-programming/javascript-functional-parts.md: -------------------------------------------------------------------------------- 1 | # Javascript是个混血儿 2 | 3 | ## 价值 4 | 5 | 高观点下理解Javascript的特性, 有选择地应用它的特性。 6 | 7 | -------------------------------------------------------------------------------- /about-functional-programming/this-features-make-language-difference.md: -------------------------------------------------------------------------------- 1 | # 这些特性让编程语言如此不同 2 | 3 | ## 价值 4 | 5 | 认识到编程语言间到底不同在哪里，我们应该如何学习新的编程语言。 6 | 7 | -------------------------------------------------------------------------------- /about-functional-programming/why-i-broke-up-with-oop.md: -------------------------------------------------------------------------------- 1 | # 为什么我和 OOP 分手了 2 | 3 | 价值: 讨论 OOP 在复用性上的缺点，通过案例来论证 FP 的优势 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/choose-programming-languages.md: -------------------------------------------------------------------------------- 1 | # 如何选择编程语言 2 | 3 | 价值：阐述编程语言选择的看法 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/good-understanding-keeps-design-simple.md: -------------------------------------------------------------------------------- 1 | # 理解你的需求，是简洁设计的秘密 2 | 3 | 价值: 提供保持简洁的最有效的方式。 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/how-to-evaluate.md: -------------------------------------------------------------------------------- 1 | # 如何准确评估开发工作量 2 | 3 | 价值：能够较为准确地评估出工作量 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/principle-of-hurt-once.md: -------------------------------------------------------------------------------- 1 | # 「受一次伤」原则 2 | 3 | 价值：读者可以更好地去理解设计的平衡，如何在持续的维护中，不断让代码更好，同时有不会浪费开发时间。 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/problems-in-software-dev.md: -------------------------------------------------------------------------------- 1 | # 软件开发的困难 2 | 3 | 价值：总结和抽象我们遇到的问题，阐述我们的原则 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/put-codes-in-right-place.md: -------------------------------------------------------------------------------- 1 | # 代码库的划分 2 | 3 | 价值：引入「问题域」的概念，通过合适的架构分层，实现复用。可以解答代码如何归属、模块如何划分的问题。 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/split-big-problems.md: -------------------------------------------------------------------------------- 1 | # 问题拆解 2 | 3 | 价值：学会如何拆解一个大型、复杂的项目。将一个大型工程拆解成模块和任务。 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/testing.md: -------------------------------------------------------------------------------- 1 | # 自动化测试 2 | 3 | 价值：get 重构的方法论。解答：是否应该写测试，应该对什么代码写测试，应该写多少测试，测试代码的维护 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/upgrade-dependencies.md: -------------------------------------------------------------------------------- 1 | # 依赖包升级策略 2 | 3 | 价值: 读者可以了解到一种简单有效的依赖包升级策略，让代码库保持较低的维护成本。 4 | 5 | -------------------------------------------------------------------------------- /about-web-dev/why-agile-development-works.md: -------------------------------------------------------------------------------- 1 | # 敏捷开发为什么能生效 2 | 3 | 价值： 理解敏捷软件开发为什么能生效的原因，而不仅仅停留在执行流程和应用工具。 4 | 5 | 前几天，公司的大牛 沃兹 分享了《领域建模》，因为我是最后才去听的，所以只听了一部分，尽管如此，也收获很多，深有同感。 6 | 7 | 最后讲到敏捷软件开发这一部分，有一些想法先记录下来， 8 | 9 | 说到敏捷软件开发，可能有很多人就会想到 进度看板、快速编码、简单设计、Scrum等等**流程**。 可你有没思考过一个问题：**它为什么能生效呢？** 流程往往容易掌握，也容易**学习**，也更方便被公司执行。 这样就容易产生为了敏捷而敏捷，以至于这两年会有不少 **敏捷已死** 的论调，前些年我和同行交流时，会自豪说我们采用敏捷软件开发， 现在聊时就不好意思说了， 因为他们的HR或管理者会回复，那不是前几年流行的吗？这几年我听说可以使用XXX开发方法，敏捷开发成了流行的服饰，过几年就得换换。 10 | 11 | **敏捷开发为什么能够生效？** 12 | 13 | 所谓的传统的软件开发流程大概是这样 14 | 15 | 需求分析->概要设计->详细设计->编码->测试->维护。 16 | 17 | 并且会重视流程的时间次序，在需求分析和设计阶段往往非常 **全面** 和**小心** ，很怕遗漏什么到后面发现时，这修改成本就大了。 18 | 19 | 也就是说，它基于一个事实， **越后来的修改越难，修改成本和维护成本，会随着时间呈指数级增长**，可能我们可能有在”“软件工程”的书中看过这样的曲线 ，所以我们必须在前面考虑周全，设计全面。 20 | 21 | 这对于软件开发，需求变化没那么快速，需求明确情况下比较好使。 22 | 23 | 而对于Web项目，以及现在的创业型公司，需求其实是边开发边摸索的，很多时候东西没做出来是不知道我们到底要什么，你 **需要的是边做边改才知道做什么**，这样的话这个模型就不符合了。 也就是说根本考虑不周全，也设计不全面，因为待解决的问题不知道是什么。 24 | 25 | 另一方面，如果我们 开发工程师，我更喜欢称我们为“软件工匠” 有一种绝活，**可以拉平上面可怕的指数曲线，让它变成线性**，即让后面的修修改改，揉揉捏捏和前面一样容易 那么开发流程应该怎么设计呢？ 26 | 27 | 于是就有了大家熟知的敏捷流程。所以我们都被带进了一个坑，就是忘记了真正重要的是 **维持这条开发成本曲线线性**，那些流程和工具才生效。 28 | 29 | 那如何才能够拥有这条完美曲线呢？而这也是最难的，难的不是不知道怎么做，而 是 **它不是知识，不是流程和工具，而是技能**。需要刻意练习才能获得。 30 | 31 | **区分知识和技能， 对我们工程师来说非常重要**，这也是为什么很多开发工程师终其一生都停留在 **感觉都会，就是写不出来**的阶段，是因为我们是不可能靠看书，看网页，听分享来掌握技能，这道理很简单，就象不可能靠看书来学会打篮球一样。 32 | 33 | 然后，我想简单聊聊如何保持那条线是线性的。 34 | 35 | 我就以 沃兹 分享的两个方面 领域模型 和单元测试为切入讲讲如何真正敏捷开发。 36 | 37 | 软件开发的结果是代码， 代码就是一种信息的表达方式，更准确地说是 **信息的组织方式**。 通过找到一种组织方式来有效地描述问题，不仅可以描述当前的问题，而且可以描述未来的问题。 38 | 39 | 在这种组织方式里，内含很多预先埋好的维度，会存在一种模型，这种模型内含很多维度，在这些维度方向上，可以自由伸缩，而需求的变更或者增添就相当于在这些维度方向上行走。而这样的结构往往是抽象的，却又能够很好地表达问题域的， 这种东西就叫“领域模型“，如果找到这些维度如何设计这个即抽象又精确的抽型就是”领域建模“需要做的事情。 40 | 41 | 上面说的是一种结果，即我们通过某种神秘的力量，或者说上帝视角，一眼看穿本质，直接还原出问题的领域模型，那么我们就能在修改时不那么费劲，能够将那么成本曲线变成水平。 42 | 43 | 但是现实情况下我们不可能拥有这种能力，所以要采用类似于启发式的探索算法。 44 | 45 | 我们只要 **时时保持当前的结构**，让其拥有清晰的维度，而当前所有的问题点都被有序地包含在内，没有特殊的点偏离。 46 | 47 | 然后基于一个事实，世界是连续的，那么变化也是连续，即需求变更尽量千变万化，但总是在当前的条件下出发完成的， 我们就能够保证 后续的维度成本同样可控，使用这种方法就能够 **维持开发成本曲线成线性**，在这种模式下，我们的开发成本会有两方面的支出。 48 | 49 | 第一步是为了保持这个结构不被破坏，所有点都在所描述的维度内。这个过程叫 **重构**。 50 | 51 | 第二步是在上一步的基础上，在预先设计的维度内，很自然上挂上新变更的需求。 52 | 53 | 上面两步就是真正的敏捷软件开发。尤其是第一步非常重要，也最容易被放弃。 54 | 55 | 正因为第一步是敏捷开发的关键，为了使调调整安全可靠，而强调甚至重新定义了 **单元测试**。 56 | 57 | 刚才说到，我们 必须时刻保持模型的有效性，那么免不了持续对我们的结构中的各个部分折折再重新装装。那么如何保证我们各个模块具有这种容易拆装组合的特性呢？ 答案就是**单元测试**，因为一个模块能被单元测试，那表示它更容易被隔离，更容易重新拆装。所以单元测试在敏捷开发里最重要是为 **保持被测模块的独立性**，或者以往术语叫低耦合，而不仅仅是测试模块是否正常工作。 58 | 59 | 如果一个模块还没产生前，我们就编写好对它的单元测试，那么这个模块必然具有好的特点，否则它就根本写出不来。 60 | 61 | 因为就两种情况： 62 | 63 | 一是已经有模块了，要添加单元测试，那么模块特性好，我们才能更容易添加单元测试，如果太复杂不好添加单元测试，这并不阻止我们继续完成功能，所以多数情况下就会放弃对这个模块的单元测试，最多写上一个TODO，让自己的心里好受些。 64 | 65 | 第二种是，如果先有单元测试，再写实现模块，那么你要把工作进行下去，唯一能做的就是调整单元测试，直到写出模块，然后模块自然具有优秀的特性。 66 | 67 | 这就是TDD，这里的重点是，TDD的T和D不是说先写完好多模块的测试，再写它们的实现，我更倾向于把它看成一个模块包含的两个不可分害的两部分，测试和实现，它们可以交替，轮流，反复，伴随而产生。 68 | 69 | 所以我觉得让敏捷软件开发真正起作用的是，我们应该在开发过程中应用以上实践，只是上述过程并不是个流程，而是个技能，所以需要刻意练习才能得以实施。 70 | 71 | 最后再谈谈简单设计， 有好多对敏捷开发不怎么了解的以为敏捷开发不重视设计，其实经过刚才的分析， 我们知道 **设计在敏捷开发中并不是一步流程，而是贯穿整个开发周期**， 只要还在维护，修改代码，就在时时设计。 上面描述的第一步其实做的就是设计。 72 | 73 | 所以这也是为什么说： 74 | 75 | **重构就是设计**， 这里的设计是动词。 76 | 77 | 相对应的还有一句话： 78 | 79 | **源代码即设计**， 这里的设计是名词。 80 | 81 | -------------------------------------------------------------------------------- /creating-a-great-web-team/bian-cheng-shi-yi-zhong-ji-neng.md: -------------------------------------------------------------------------------- 1 | # 编程是一种技能 2 | 3 | 价值：读者可以认识到编程也是一种技能，也可以通过科学的方法快速培养。 4 | 5 | -------------------------------------------------------------------------------- /creating-a-great-web-team/great-team-cannot-live-without-code-review.md: -------------------------------------------------------------------------------- 1 | # 没有 Code Review 就没有好团队 2 | 3 | 价值：让读者认识到 code review 的重要性。通过我们的 code review 实践更好地去做 code review。 4 | 5 | -------------------------------------------------------------------------------- /creating-a-great-web-team/product-released-email.md: -------------------------------------------------------------------------------- 1 | # 项目上线邮件 2 | 3 | 价值：让读者意识到项目上线邮件的重要性，以及如何写出言简意赅的邮件。 4 | 5 | -------------------------------------------------------------------------------- /creating-a-great-web-team/recruiting.md: -------------------------------------------------------------------------------- 1 | # 关于招聘 2 | 3 | 价值： 4 | 5 | 1. 让读者意识到招聘的重要性，我指的是真正的意识到。 6 | 2. 让读者 get 到一些分辨好程序员的一些 tips. 7 | 8 | -------------------------------------------------------------------------------- /personal-development/making-excellent-resume.md: -------------------------------------------------------------------------------- 1 | # 写一封彰显实力而不失优雅的简历 2 | 3 | ## 好简历提升获得好工作的概率 4 | 5 | 这是一个真实案例。 6 | 7 | 小 Y 是一名从业一年多的前端开发工程师，因为个人发展的关系，希望能加入到一个更大的开发团队。于是她写了一份简历投到招聘平台上。 8 | 9 | 然而不幸的是，简历如石沉大海，过了两周仍然没有人联系她。 10 | 11 | 后来在大鱼的指点下，她优化了一下简历，作了一些调整。重新投递后，第二天就接到了电话面试。 12 | 13 | 这次调整为什么这么有效？因为结构调整后，呈现了读者最关心的内容。 14 | 15 | ## 简历读者关心哪些东西? 16 | 17 | * 你是一个什么样的人，你与众不同的地方在哪里？ 18 | * 为什么你能胜任这份工作？ 19 | * 你是如何思考和解决问题的？ 20 | * 你的成功项目有哪些？为什么成功，好在什么地方？为什么有价值, 解决了什么问题？ 21 | 22 | 这些问题回答得越具体越充分，通过简历筛选的概率就越大。 23 | 24 | ## 重点内容 25 | 26 | ### 项目 27 | 28 | #### 什么是项目? 29 | 30 | 项目是最重要的事实证据，无论是筛选简历，还是面试，或是晋升评审，都是围绕项目进行沟通，所以描述好项目是简历中最重要的事情，没有之一。 31 | 32 | 项目可以是一个软件开发项目，如大促活动开发，也可以是一个概念的落地实践，比如在团队中推广某个技术框架, 或是推行一种管理方式。只要是有计划、有目标、有资源投入、有分阶段的过程的，都可以称为项目。 33 | 34 | #### 怎么描述一个项目？ 35 | 36 | 描述清楚以下几点: 37 | 38 | 1. **为什么要做这个项目?** 39 | 40 | 交代一下项目背景，让读者能理解你要解决的问题，和你处于同一个上下文。方便对方更能理解你做的事情。 41 | 42 | 比如: 43 | 44 | * 故障频发，为了解决这个问题，你在团队中推行持续集成 45 | * 为了提高运营效率，要将一些运营动作在线化、产品化 46 | * 为了让大家的学习成长更有动力，你提出了一个学习奖励计划，设计了一套机制 47 | 48 | 2. **遇到了什么挑战? 是如何解决的?** 49 | 50 | 比如: 51 | 52 | * 单元测试乍看起来要花额外的经历去写和维护，看起来是降低了开发效率，受到了一些人的排斥。真实的情况是单元测试对效率和质量都有提升作用，尤其是架构设计的演进的必要条件。这件事需要布道，所以你先在核心系统上小范围使用，大家养成习惯之后就离不开了，然后就大范围推广。 53 | * 对接的运营动作比较多，所以你进行了思考和抽象，设计出一个专用的领域语言，做成了一个通用的系统，能够满足现在和将来的各种运营需求。 54 | * 一开始大家动力不足，于是使用一些游戏化的手段 55 | 56 | 57 | 3. **最终结果如何?** 58 | 59 | 你不能模糊地说「挺好的」，你需要用客观的事实(最好有数据）来表现结果。比如： 60 | 61 | * 单元测试覆盖率 50% 以上的项目，近半年内重大故障数量：0 (原先是多少来着?) 62 | * 每个月节约了 5 天运营投入，每年为公司节省了约 100 万开支 63 | * 团队成长显著，搭建了梯队，主动离职率为 0 64 | 65 | 归纳一下，其实你是在讲述一个 **故事**，一个真实的故事，并且这个故事的主人公就是你。 66 | 67 | #### 案例 68 | 69 | 这个故事是我以前真实的项目。 70 | 71 | > **Demo 中心项目** (2011年) 72 | > 73 | > 在日常工作中，我发现项目的沟通效率很低，设计文件（包括产品文档、交互稿和视觉稿）有变更时，是通过聊天工具同步给其他人的，这样容易只同步到部分项目成员。因此我做了一个简单的系统，把设计稿(demo)放到一个平台上进行管理，有变动的时候会自动同步给项目组的其他人。这个平台推出后获得了非常好的评价，大家再也不用把新的设计稿用阿里旺旺发给 15 个项目小伙伴，取而代之是一句「设计稿更新到 demo 中心了哦亲」。 74 | > 75 | > 这个平台后来整个阿里巴巴集团都在使用。 76 | 77 | 78 | ### 自我介绍 79 | 80 | 一个简历第二重要的是自我介绍。不像项目，自我介绍可以主观一些，怎样自由发挥都没事。比如:「 喜欢钓鱼，很有耐心，善于在过程中寻找乐趣」。 81 | 82 | 然而大部分简历的自我介绍都极度糟糕，他们看上去是这样的： 83 | 84 | > 接触及使用过的技术： 85 | > webpack、sass/less、es6、vue、react、flutter、数据可视化（Echarts、D3）、webgl 3D图形渲染、Node、源码解析（jquery、vue）、TypeScript、Angular2+ 86 | 87 | 这样的: 88 | 89 | > 本人拥有四年的_Web开发_及设计经验、精通 _HTML_、_HTML5_、_CSS_、_CSS3_、_JavaScript_、_Node_、_VUE_、_ES6_ 等前端开发技能，拥有开发 _PC_、H5 等多端项目经验；精通_Node_、 _Express_等_后端开发_技能，熟练使用Java、Spring、_MyBatis_、Mysql等_后端开发_技能；熟练使用Git、_SVN_等_代码管理工具_ 90 | 91 | 嗯，还不错。不过大部分情况下这些技术太普通了，没有什么值得放到自我介绍中炫耀的。 92 | 93 | 优秀的自我介绍是这样的: 94 | 95 | > 7年工作，不断在反思中进步，挫折中前行。从后端到前端，从小前端到大前端，从小白到资深，从独当一面到全栈的路上，不断前行。若是人生须有信仰，代码就是我的上帝。 96 | 97 | 是不是感觉这个人（声明: 这个人不是我）很栩栩如生? 你的自我介绍也要让人第一眼就知道你什么如何与众不同。 98 | 99 | ## 加分项 100 | 101 | * 在公司或者学校获得的，有代表性的奖项，比如 102 | * 公司的最佳新人奖 103 | * 在校期间获得奖学金 104 | * 层级获得计算机竞赛的奖（我相信如果有，你肯定不会忘记写） 105 | 106 | * 暗示你通过层层选拔之后脱颖而出的事情 107 | * 在大厂实习过 108 | * 获得某大厂的 offer 109 | * 担任公司技术委员会的评委 110 | 111 | ## 其他的小 tips 112 | 113 | * 不要用「我有很深的造指」这种既很浮夸又有错别字的话。 114 | * 不要假定读者知道一些「知名」的信息，比如「我曾经是 RubyConf 讲师」，你要解释一下 RubyConf 在行业内的影响力。当然如果你的对象是一家用 Ruby 的公司（基本可以断定是一家好公司），那就不必解释了。但是你也不知道哪天谁会看到你的简历呢？ 115 | 116 | ## 总结 117 | 118 | 再也不要在简历中列你会什么、你做了什么了? 读者更关心你能不能胜任他的岗位。讲讲你的故事，让他感受到你能胜任。人都是故事的奴隶，是吧? 119 | -------------------------------------------------------------------------------- /personal-development/prefer-good-search-engine.md: -------------------------------------------------------------------------------- 1 | # Prefer Good Search Engine 2 | 3 | 价值: 读者认识到搜索引擎是程序员最重要的工具之一 4 | 5 | -------------------------------------------------------------------------------- /web-dev/kill-your-job.md: -------------------------------------------------------------------------------- 1 | # 追求：让自己失业 2 | 3 | 价值: 让读者能意识到「赋能」的重要性。 4 | 5 | -------------------------------------------------------------------------------- /web-dev/seek-answers-in-specifications.md: -------------------------------------------------------------------------------- 1 | # 在 Web 规范中寻找答案 2 | 3 | 价值：让读者认识到 Web 规范的重要性，平时多从规范中寻找答案，少看二手信息。 4 | 5 | -------------------------------------------------------------------------------- /web-dev/untitled.md: -------------------------------------------------------------------------------- 1 | # 关于认知 2 | 3 | 价值：认知 = 知晓原理，我们更应该关注技术背后的原理 4 | 5 | -------------------------------------------------------------------------------- /web-dev/web-dev-vs-frontend-dev.md: -------------------------------------------------------------------------------- 1 | # 「Web 开发」和「前端开发」 2 | 3 | **价值：** 4 | 5 | 解决「我是否应该学习后端」「我是否应该掌握全栈技术」这样的困惑。 6 | 7 | **材料** 8 | 9 | \*\*\*\* 10 | 11 | -------------------------------------------------------------------------------- /web-dev/you-need-casual-projects.md: -------------------------------------------------------------------------------- 1 | # 你需要有一些业余项目 2 | 3 | 价值：让读者知道业余项目的重要性，通过业余项目去实验新技术，通过生产项目去发挥更大的价值。 4 | 5 | --------------------------------------------------------------------------------