search

lzh2nix / articles

用 issue 来管理个人博客
https://github.com/lzh2nix/articles
63 stars 13 forks source link

程序员修炼之道:从小工到专家 阅读笔记 #147

Open lzh2nix opened 2 years ago

lzh2nix commented 2 years ago

content

lzh2nix commented 2 years ago

序言(2022.05.04)

最近自己也遇到了一些瓶颈,感觉自己的水平停在哪里好久没有前进了. 一直在找一些提高的方法, 在看老许的《架构师》课程中也提到一点就是向行业内的牛人学习, 学习优秀的设计, 学习他们的思考方式. 其实对我们也就两种方式:

代码方面可以后面找一些基于 golang的 5 万行左右的项目分析一下(差不多1个月能搞完的项目).

书籍方面可以参考下面的四本书:

5月就以<<程序员的修炼之道>>开始, 项目还是以最熟悉的 emitter 开始

image

序言里的这个点一些子戳中的我的要害. 就是要在项目中作出更有见识的决策.

编程是一门艺术,因为你在不断的创造

编程是一门艰难的工作, 鼓吹方法学的大环境下并没有针对当前问题的完美解.

image

关于工作的意义

image

这个小故事很有意思, 一下子指出了工作的意义. 日拱一卒, 长期的坚持下来必有结果.

每天为提炼你所拥有的技能而工作,为把新的工具添加到自己的技能列表中而工作.

Back To Top

lzh2nix commented 2 years ago

ch1 注重实效的哲学(2022.05.05)

注重实效的程序员的几个特征:

在所有弱点中, 最大的弱点就是害怕暴露弱点. —- J.B.Bossuet

第三条 Provide Options, Don’t Make Lame Excuses 提供各种选择,不要蹩脚的借口

在走向任何人, 告诉他们自己某件事情做不到,为何耽搁,为何出问题之前, 先停下来,听一听自己心里的声音. 在头脑中预演一遍场景,看看其他人会说什么.

熵(entropy): 某个系统中“无序”的总量

破窗理论:一扇窗户破了, 如果不及时修复,很容易引发下一扇窗户的破损

第四条 Don’t Live with Broken Windows 不要容忍破窗户

不要留着”破窗户“(低劣的设计,错误的决策, 糟糕的代码)不修, 发现一个修正一个.

第五条 Be a Catalyst for Change 做变化的催化剂

第六条 Remember The Big Picture 记住大图景

留心大图景, 要持续不断的观察周围发生的事情,而不只是你自己在做的事情

第七条 Make Quality a Requirements Issue 使质量成为需求问题

今天的了不起的软件常常比明天完美的软件更可取,如果你给用户某样东西,让他们及早的使用,他们的反馈常常会把你引向更好的最终解决方案. 而且最好是模块化的交付, 整体式软件需要达到所需的质量花费的时间会更长.

第八条 Invest Regularly In Your Knowledge Portfolio 定期为你的知识资产投资

知识资产的投资也讲究一下几点:

关于技术投资:

第九条 Critically Analyze What You Read and Head 批判的分析你读到的和听到的

了解你的听众:

image

第十条 It’s Both What You Say and the Way You Say it 你说什么和你怎么说同样重要

Back To Top

lzh2nix commented 2 years ago

ch2 注重实效的途径(2022.05.07)

系统中的每一项知识都必须具有单一,无歧义,权威的表示

第十条 DRY-Don’t Repeat Yourself 不要重复你自己

几种常见的重复:

第十二条 Make It Easy To Reuse 让复用变的简单

正交性:

image

第十三条 Eliminate Effects Between Unrelated Things 消除无关事物之间的影响

我们要设计自足的组件, 独立,具有单一,良好定义的目的

正交系统的两个好处: 提好生产力和降低风险

提高生产力:

降低风险:

对于正交设计, 有一个测试方法, 设计好组件, 问问你自己: 如果我显著的改变某个特定功能背后的需求, 有多少模块会收到影响 ? 在正交系统中答案应该是一个.

第十四条 There Are No Final Decision 不存在最终的决策

保持架构的灵活性, 变更随时都会到来, 尤其是在新的项目中在你完成工作之前, 需求就可能发生变化了, 所以你要做好需求随时发生变化的准备.

第十五条 Use Tracer Bullets To Find The Target 用曳光灯去寻找目标

其实就是快速的Demo或者POC 具有一下的优点:

第十六条 Prototype to Lean 为了学习而制作原型

原型制作是一种学习经验. 其价值并不在于所产生的代码,而在于学习到的经验教训,那才是原型的要点所在. 制作架构原型的一些注意点:

避免被原型误导

第十八条 Estimate To Avoid Surprises 估算,以避免发生意外

通过估算对事物的数量级有个大概的直觉,确定方案的可行性. 当编码时,你将能够知道哪些子系统需要优化,哪些可以放在一边.

第十九条 Iterate the Schedule with the Code 通过代码对进度表进行迭代

通过对进度表的不断的迭代了来提供自己对“进度”的估算能力.

Back To Top

lzh2nix commented 2 years ago

ch3 基本工具(2022.05.09)

第二十一条 Use the Power of Command Shells 利用命令行 shell 的力量

去熟悉 shell 然后使用 shell 提供的各种强大功能.

第二十二条 Use a Single Editor Well 用好一种编辑器

选择一种编辑器,彻底了解它, 并将其用于所有任务的编辑工具

第二十三条 Always Use Source Code Control 总是使用源码控制

调试就是解决问题, 要据此发起进攻

第二十四条 Fix the Problem, Not the Blame 要修正问题, 而不是发出指责

最容易欺骗的一个人的你自己, 在调试时关闭保护自我(Ego)的防御意识, 忘掉你可能遇到的任何项目压力,记住调试的第一指责:

第二十五条 Don’t Panic 不要恐慌

第二十六条 Don’t Assume it Prove It 不要假定, 要证明

当遇到让你吃惊的 bug 的时候, 除了只是修正它之外, 你还需要确定先前为什么没有找到这个故障. 考虑是否可以通过单元测试或者其他测试, 以让他们有能力找出这个故障.

第二十七条 Learn a Text manipulation Language 学习一种文本操作语言

Perl/Python/shell 都是选择

第二十九条 Write Code That Writes Code 编写能编写代码的代码

对开发最有帮助的就是api文档的生成(TODO 给七牛许式框架增加一个 api 文档生成工具)

Back To Top

lzh2nix commented 2 years ago

ch4 注重实效的偏执(2022.05.14)

第三十条 Your Can’t Write Perfect Software 你不可能写出完美的软件

这刺痛了你? 不应该的. 把它视为生活的公里, 接受它, 拥抱它, 庆祝它. 因为完美的软件不存在.

第三十一条 Design with Contracts 通过合约进行设计

image

错误信息好偏向消费者

第三十二条 Crash Early 早奔溃 erlang的 let’s It Crash

在自责中有一种满足感. 当我们自责自己时, 会觉得再没有人有权利责备我们

— 王尔德

第三十三条 If It Can’t Happen, Use Assertions to Ensure That it Won’t 如果它不可能发生, 用断言确保它不会发生

断言才能保证事情绝不可能发生

第三十四条 Use Exceptions For Exceptional Problems 将异常用于异常的问题

第三十五条 Finish What Your Start 要有始有终

分配某项资源的例程或对象应该负责释放该资源

Back To Top

lzh2nix commented 2 years ago

ch5 弯曲或折断(2022.05.20)

把代码组织成最小的单元(模块), 并限制它们之前的交互, 如果随后出于折中必须替换某个模块,其他模块仍能继续工作.

第三十六条 Minimize Coupling Between Modules 使模块之间的耦合减少到最少

第三十七条 Configure, Don’t Integrate 要配置不要集成

系统要高度可配置, 不仅是像素颜色和提示文字这样的事物,而且包括诸如算法,数据库,中间件等更深层次的选择.

第三十八条 Put Abstractions In Code,Details in Metadata 把抽象放进代码, 细节放进元数据

image

第三十九条 Analyze Workflow to Improve Concurrency 分析工作流, 以改善并发性

第四十条 Design Using Services 用服务进行设计

服务: 定义良好,具有一致接口之后的独立,并发的对象

第十一条 Always Design For Concurrency 总是为并发进行设计

Back To Top

lzh2nix commented 2 years ago

ch6 当你编码时(2022.05.21)

第四十四 Don’t Program by Coincidence 不要靠巧合编程

何时可以考虑重构?

第四十七条 Refactor Early, Refactor Often 早重构, 常重构

两个原则:

第四十八条 Design to Test 为测试而设计

第四十九条 Test Your Software, or Your Users Will 测试你的软件, 否则你的用户就得测试

第五十条 Don’t Use Wizard Code You Don’t Understand 不要使用你不理解的向导代码

Back To Top