不是感情宣泄,因为其中有些行为或思维也是我以前作为低效能程序员的总结。
排过序
正例
《高效能人士的七个习惯》
《深入理解计算机操作系统》
《 Clean Code 》
《 Clean Architecture 》
《重构》
The skill of self confidence | Dr. Ivan Joseph | TEDxRyersonU - YouTube
芯片工程师的一天 | 我如何每天高效工作 12 小时? [经验分享]
如果你没有看过《高效能人士的七个习惯》、《金字塔原理》、《 Clean Architecture 》、《重构》、《实现领域驱动设计》、《微服务架构设计模式》、《测试驱动开发》、《敏捷软件开发:原则、实践与模式》(后面两年本我也没看过,只看过相关的书籍,例如大学学的《软件工程》),你又想短时间内提升自己,你可以挑着这个专栏,如果和你意你可以考虑买一下。我没收过极客或者作者一分钱,只是觉得还行,有一定收获。当然,看了专栏不代表这些书就可以不看了,这些书籍我也看了大半,尤其是《 Microservices Patterns 》也就是《微服务架构设计模式》,力荐。
反例
一年前的自己
历任同事(不包括所有)
我知道我不能说 CSDN 上全是垃圾博客,全是讲一半害人,抄书上的内容,你可以很 “轻易” 得找出能反驳我的博客。每个人都有自己不同的看法,我的看法就是认为 CSDN 是垃圾网站。
——来自一个告 “深山猿” 直接抄袭复制《 MySQL 实战 45 讲》的人,询问 CSDN 客服,告诉极客时间专栏作者。
很明显,我没有对我的承诺准时的付诸实践,没有对自己应该写的内容进行规划,只是按部就班的看完了这几本书,拖延到了现在。我可以找各种借口(国庆回家给家人庆祝生日,忙前忙后,年底工作很重,滨江三大垃圾厂的原则是 124 加班,大小周上班所以没时间,可能有抑郁症了等等),I had a damn good excuse. 但我不喜欢找借口,没做好就是没做好,我会怀有歉意,对我抱有期望的那些人说声对不起。我会去把它做完,有规划有条理的做好后续的每一个步骤。
当然,这期间我还看完了其他书,只是和这个无关,例如《数据密集型应用系统设计》(神书),快看完了《深入计算机操作系统》、《也许你该找个人聊聊》、《真实的幸福》等等,再看了遍《当幸福来敲门》。
编写垃圾代码。
是的,这个和 15,16,17 其实是一个意思,需要再三强调。
什么是垃圾代码?难读懂,一个方法超级多行,也没有注释,更别说在一个方法里,把不同抽象层级上代码混合在一起。写代码并不是什么高难度的活,是个人都能写代码,但是能写出让人看得懂的代码才是真正的开发人员。
尽量让你的代码保持简单,KISS 原则,Keep It Simple, Stupid。但并不是说所有代码都应该写简单,如果是复杂的事物,必须得用复杂代码实现的,那只能这么做。架构也是如此,请让你的设计尽量保持简单。
对人不对事,喜欢一味指责别人。
每一个的抱怨的背后都隐藏了一个事实。找出真相,修复真正的问题。需要你有结构化思维,自顶向下,探清问题本质。如果不会,请参照《金字塔原理》。
请做一个积极主动的人,从自身出发,影响他人。自控力是可以传染的,应该以我如何如何出发,而不是别人如何如何。消极的人,很难进步。
现在项目紧,先把功能写上去,测试后面再补,你先写测试代码慢,你也别写测试了。
(来自从来没写过测试的人说我践行 TDD 有问题,后面当然没有补过测试代码)
你不用管别人代码写得怎样,你管那么多干嘛呢,又不是人人都像你这样,先把功能做了。
(这是低能说的话,不是低效能,全部习惯,只有这个铁板钉钉低能说的话)
想靠别人的指导来让自己的能力提升,依赖别人。
有点关联第 22 个,但不全是。
分享垃圾知识,没有竭尽全力去搜寻有价值的信息。
人一步步地做有挑战的事情才能进步,知其然不知其所以然注定学不到东西。很多时候,你想要了解的知识书上都写了。认为看书很难,英文官方文档不看,转而看那些 CSDN 的垃圾文章都是很低效的行为。
不懂得对不重要也不紧急的事情做丢弃。
艾森·豪威尔矩阵将事情分为,重要紧急,重要不紧急,不重要紧急,不重要不紧急。《高效能人士的七个习惯》里面提到过,《整洁架构》里面也提到过,前者让我们着重做不重要但不紧急的事情,因为如果你只做重要紧急的事情,最后都会成为重要紧急的事。重要但不紧急的事情,例如锻炼身体,学一门乐器,这些都是需要长时间投入,且平时可能觉得收效甚微的事情,但是当你坚持下来一个月,半年,一年,你一定会和从前大不一样。
你一定也有一些一拖再拖,但是其实是很重要的事情。你应该大部分精力做这些事,一部分精力做重要且紧急的事。我看过一些其他工程师的视频,他们介绍他们在一些顶级公司(FAANG)是如何处理那么多的事情,处理开不完的会。一个主要的建议就是把你的事情一个个列出来,定个 Priority,一件件执行。是的,是一件件执行,不要做并发执行,你的人脑是单核,也做不了并行处理,最优的方式是事件循环 Event Loop 处理方式。那些让你同时做多件事的人,非蠢即坏。
我会用就行了,我管这个怎么实现。
将所有事情拖到一个时间,而不是有节奏地做事。
我是为公司工作。
如果你这么想,你很难在工作中达到心流状态。在《心流》这本书中介绍了庖丁解牛、热爱生命的莎拉菲娜、与世无争的柯拉玛,你需要重新设计工作,使得它尽可能接近心流活动,你还得培养自得其乐的性格,加强技巧,选择可行的目标。
其实你真正是在为你自己工作,我也是在为我自己工作,如果可能的话,在公司我自己培养了极其自律的习惯后,我会尝试创业。当然,这个事还没有说一定会去做,也算不上什么目标。
我并不是说要天天加班(垃圾厂124加班不成文规定),大小周恶心员工。相反,我想你应该尽可能在工作时间内完成你的工作,而不是拖到加班。如果你把工作等同于赚钱,那你应该了解赚钱的等级分 4 种,
我工作是因为我能给公司创造价值的同时,让自己更加进步,公司给我一个能犯错、成长的环境,我会竭尽全力做很好,顺便让自己得到成长。当然,别强调加班,如果你的工作效率已经达到甚至超过了公司对你期望,但你的领导只想让你加班,你该早点考虑换下一家公司。Bob 大叔是这么看待加班的,必须满足以下所有条件,才能考虑加班
你能挤出这些时间
短期加班,最多加班两周
你的老板要有后备预案,以防万一加班措施失败了
没有目的的开会,为了开会而开会。
在敏捷开发中,每日的 Standup 是必须的。每人 1-2 分钟,来阐释
并不是领导说要开会而开会,为了开会而开会,既然开会,就要有开会仪式,尊重他人的时间。在开会前准备好你要说的内容,写下来,梳理演讲内容,和他人达成一致。
在《程序员修炼之道》里面也提到了,你不应该只局限于技术书籍的阅读,你应该读读其他类型的书籍。
福特公司开发了世界上第一条流水线(Pipeline),影响了电影制作、CPU、Spring 框架。你们可能觉得这些好像毫无关系,制作汽车的公司怎么会影响制作电影的,还会影响 CPU?事实上,流水线在我们生活中无处不在。
大制片厂的最大特点是流水线(Pipeline)的生产方式。1908 年美国人福特开创性以流水线生产方式,通过组装配件进行汽车生产,从而极大降低了成本,也使大规模的批量生产成为可能,被誉为现代大机器生产的代表。
1913 年,美国独立制片人兼导演托马斯·英斯意识到这种生产方式的价值,便建立了类似的电影生产模式,从此 “流水线的生产方式” 就成为了好莱坞电影工业的标志。
随后,在好莱坞的鼎盛时期,这种方式不断成熟。从而既保证了片源的丰富与稳定,又催生了电影类型片的出现。在这种流水线的生产方式中,导演对电影的整体把控权被剥夺了,取而代之的是强化了制片人的控制权,即形成了制片人中心制。
Spring 的 BeanFactory 是工厂模式,创建 Bean 的各个阶段的 BeanPostProcessor,以及各个阶段都影响着 Bean 这个产品,可以根据不同时间做不同的事情。甚至工厂本身,都能做 BeanFactoryPostProcessor。
多读书,读好书。Read More, Read Better.
这根本不是什么码农成功学,只是在说一些低效习惯罢了。
这些都是些低效能的习惯/思维/语句,我尽我所有做到不会有这些。
1
learningman 2021-09-11 15:26:35 +08:00 7
认为重复的 CRUD 很无趣,总想着换个工作能好点。
不认同,CRUD 就是很没有意思啊 |
2
wangxn 2021-09-11 15:36:30 +08:00
楼上+1
|
3
dongcidaci 2021-09-11 15:43:58 +08:00 2
目前作为一个低效能程序员,对楼主说的很有体会和感悟
|
4
WispZhan 2021-09-11 15:56:12 +08:00 1
总结的挺好
|
5
young1lin OP @learningman 你可以看下文中的这个 The skill of self confidence | Dr. Ivan Joseph | TEDxRyersonU - YouTube,链接点进去。或者你可以看看这个。
3 rules to quickly improve your life 从重复中找到乐趣,找到自信。成功的人不是每天做不一样的事,而是每天重复做同一件事,不断突破自己,不断踏出自己的舒适圈,不断成长。 如果你 CRUD 这些小事做不好,领导是不会说让你想什么技术解决方案的,小事都做不好的人,难做成大事。你可以每次只迈一小步,做任务拆解,从而完成大的任务。而且,CRUD 并不简单,任何事都不简单,你没遇到,不代表不存在。 换一个工作并不能改变这些,这是真的。很多公司是靠业务活的,不是靠创新活的。创新也要了解已有内容,在其基础上进行突破、改进。并且在计算机领域内,如果你不是专门研究某一块知识的人,很多时候,你的任务就是按部就班地完成和实现它。 有些时候,我们改变不了问题,但我们可以改变对问题的态度。或者说,只要能够看到问题的存在,就已经改变了面对问题的态度。 |
6
xianyukang 2021-09-11 16:09:30 +08:00 1
加一条不怎么相关的
31. 融入世俗, 没有享受过用编程进行创造 or 自我表达的快乐 |
7
young1lin OP |
8
janus77 2021-09-11 16:35:14 +08:00 1
我感觉有些似乎自相矛盾或者不够说服力吧
比如上面说不喜欢新技术,后面又说滥用新技术的 比如碎片化工作和拖工期,我觉得空闲时间自己学习并没有什么问题,除非你所指的“低效能”只特指公司工作而不包括个人成长 另外我觉得每天高效工作 12 小时是值得尊敬的事,但不能成为值得推广的事 |
9
w7938940 2021-09-11 16:35:56 +08:00
除了第 24 条,说的就是我
|
10
yrj 2021-09-11 16:50:50 +08:00 via iPad
不幸命中 29
|
11
7gugu 2021-09-11 17:00:58 +08:00
CRUD 确实很无聊😂
|
12
zhoudaiyu 2021-09-11 17:25:54 +08:00 via iPhone
建议加一个,从来不用百度以外搜索引擎搜索技术资料,我亲眼见过我曾经的组长用谷歌搜索百度,然后打开百度再搜索技术相关的文章
|
13
young1lin OP @janus77
上面说的是, [喜欢盲目追逐新技术,不深入了解类似技术的本质] 。如果你说敏捷开发是新技术的话,可能你不是科班出身的,或者上课没认真听讲。可以看看相关书籍,我下面也有提到,或者再看看教材,我们那时候的是当时最新的《软件工程导论》-晏峰写的。 如果了解过一两个框架的源码或者中间件的源码,例如 Spring 的源码,你知道 BeanFactoryPostProcessor,BeanPostProcessor,BeanWrapper 等等,并且你还知道流水线( Pipeline )思想,很多源码,都不是问题。还有 Environment 抽象,你也可以在其他中间件实现类似的,例如 Flink,实现多 Environment 源,用 Spring EL 替换。如果都没看过对应的源码,那么看相应的书籍,可以帮你快速入门如何高效看源码。例如《通用源码阅读指导书》,这本书我看了部分,还是可以的,是可以作为源码阅读的入门书的。 碎片化工作,我们的理解可能出现了分歧,粒度可能不一样。我这里指的是,每过 10 分钟甚至更短,就看一会手机或者干工作之外的事情。如果你理解内存分配,内存碎片的内容,这部分你应该懂了。 如果你真正高效工作的话,一天 12 个小时高效工作,这个是很难做到的。你试过就知道了,我是这样,每天早上把今天的任务拆解了,拆到足够细了,开始工作,每工作 45 分钟,站 3 分钟,期间包括喝水、上厕所,结束后,再进行下一轮的工作周期。借鉴的番茄钟学习法,因为这个真的是有效的。 还有就是,我近半年没加过班了,不是说我不忙,任务不重,或者说公司大部分人都不加班。事实上正好相反,大部分人都 “加班”,由于是弹性打卡,他们早上在公司另一块园区的食堂打卡,然后 9 点多到工位,晚上拖到 8 点算是加班两个小时了。我一般是早上 7 点多到公司,看半小时到一小时书( 8:30 上班),再开始一天的工作计划安排。有时候是 6 点 50 多到公司,所以我每天都是 17:30 准时下班。 有计划,有组织地去完成任务,这是很高效的。你也可以试试。光有目标,没有详尽的计划,这种是很难坚持下来的。让你的工作产出可视化,让你的工作内容有所记录,都是能切切实实提升你的工作效率的。 |
14
young1lin OP @zhoudaiyu
这个我也想加的,而且我想加的是,不会用英文在 Google/Bing 搜索技术问题。但是这个很容易引战,因为会有一大波人跳出来,我就觉得百度好用、你这用 Google 翻墙是犯法、你不支持国产搜索引擎你不爱国之类的话。 用 Google 搜索切切实实得改变了我的一些坏习惯,也提升了我的英文水平(虽然现在一般),我已经可以不看英文字幕,听得懂说话算是标准美式发音(不要经常有缩读、省读、连读等)的视频了。 |
15
fatigue 2021-09-11 17:57:20 +08:00 3
《码农成功学》
|
16
young1lin OP @w7938940
是可以改的,人是会变的,可以一小步一小步地改正。如果现在是,不代表以后也是。 如果想成为更好的自己,那就得付诸一些切实可行的行动。 就算每天只前进 1%,一年后就是 37 倍的成长。如果不知道如何养成一个好习惯,可以看看《 Atomic Habits 》这本书,中文名《掌控习惯》。将养成习惯拆解成了 4 个阶段,提示、渴求、反应、奖励。如何养成一个好的习惯,就是增加 /增强提示,增加渴求,降低反应成本,让奖励可视化。 上面说得可能有些抽象,更为具体,例如你每天做 10 个俯卧撑,限定了当时的环境,比如穿的鞋子,场地还有时间。比如我到 20 点了,穿上运动鞋了,到了某个地方,就该做俯卧撑了。你渴望拥有八块腹肌,以及健硕的胸肌,那么就得把这些渴求展现出来。降低反应成本就是你一天只做 10 个,多了就不做,一天做 10 个应该不难吧,对于大多数人来说。这里有个理论是 Five-minutes Rule,意思就是你只做 5 分钟,超过了就不做,但事实上你做了一般都会超过 5 分钟。书上说的是两分钟,和这个是类似的。让奖励可视化,是我们习惯了即时性满足,我们就要让做完这件事奖励马上有反馈。你可以买个习惯笔记本,每天记录自己做了这个习惯,做了就打勾,没做就打叉。看看自己坚持的情况,这也是可以让你的习惯坚持下去的。 上面的习惯记录,让奖励可视化,其实在 Scrum 的 Kanban 也是如此的。 如果你对如何养成习惯感兴趣的话,可以深入看看这本书。或者《微习惯》、《弹性习惯》,都是类似的。 |
17
charlie21 2021-09-11 18:12:18 +08:00 2
7. 从不了解架构,不了解设计(设计就是架构)
29. 喜欢过度设计 |
18
Dragonphy 2021-09-11 19:38:22 +08:00 1
中了好多,也感谢您的资料分享🎉
|
19
whileFalse 2021-09-11 19:48:15 +08:00
@zhoudaiyu 他要是开着翻墙打开谷歌就能封神了
|
20
shm7 2021-09-11 19:48:45 +08:00 via iPhone 1
我做深度学习的,模型部分单元测试真就等同于系统测试…
|
21
hockor 2021-09-11 20:29:40 +08:00 1
总结的很好~
|
22
SekiBetu 2021-09-11 20:56:36 +08:00 1
这些要求忽略了项目时间要求、家庭,只有初入社会的程序员能做到吧,现在的公司项目要求多少天就要多少天做完,哪有那么多时间给你去思考,能抄别人的想法就抄就完事了
|
23
40EaE5uJO3Xt1VVa 2021-09-11 21:16:38 +08:00 1
你说的对
|
24
Turkestan 2021-09-11 21:37:39 +08:00 1
你说的对
补充一点:31. 沟通能力极差,比如只会在 v 站发泄情绪 感觉这一点比上面的条条框框都重要 |
26
lanlanye 2021-09-11 21:42:17 +08:00
可是写不写单元测试经常取决于 deadline 怎么破?
|
27
chaleaoch 2021-09-11 21:47:08 +08:00
我就知道有一本很有名的
深入理解计算机系统 深入理解计算机操作系统 是什么? 有链接吗大佬? |
28
young1lin OP @chaleaoch 我写错了,就是《深入理解计算机系统》就是那个黑皮书,如果有人把上面的题目全部做完做对了,可以说是深入理解了。
我买的是这个,其实如果认真看,这个不是很难的,一步步来,https://detail.tmall.com/item.htm?id=560961072406&spm=a1z09.2.0.0.459f2e8d3OJGZx&_u=b23btt1t3854 |
29
young1lin OP @Turkestan 是的,要做个积极主动的人,并且要学会有效沟通。后面这个,我正在改,已经写到了下半年的绩效考核中,自我练习以及查看对应书籍,如《金字塔原理》、《卓有成效的管理者》。
|
31
ruixue 2021-09-11 22:41:37 +08:00 4
“比如用户名很奇怪,经常改变,不同的地方用户名不一样。”
这有什么问题吗?用户名不包含和自己相关的真实固定信息、不同时间 /不同地方使用不同的用户名都是很好的保护自己隐私的习惯,可以大幅降低遭到人肉搜索网络暴力的可能性。怎么就成了“害群之马”了? 难不成大家都从接触互联网开始就决定好一个固定的网络 ID,哪里都用这个,一直用到去世,才能不被归为“害群之马”? |
32
HytonightYX 2021-09-11 23:48:38 +08:00
最近做一个新的功能,看到第 29 条突然醒悟到自己是过度设计了,而且在非核心功能上花了太多的时间,感谢楼主
|
33
godpeo 2021-09-12 00:13:35 +08:00 via iPhone
CRUD 是什么
|
34
WilliamYang 2021-09-12 00:22:00 +08:00 2
楼主总结的很厉害,是一个真正会写代码的工程师
|
35
secondwtq 2021-09-12 00:54:27 +08:00
高质量主题的特点:
木有二维码 |
36
Brentwans 2021-09-12 01:19:12 +08:00
这些楼主是照着某位同事总结的吗?有些好具体啊。
|
37
BiteTheDust 2021-09-12 02:04:42 +08:00 5
感觉太过上纲上线了
|
38
zhoudaiyu 2021-09-12 07:33:07 +08:00 via iPhone
@whileFalse 是啊 开着代理打开谷歌,然后在谷歌搜索百度,然后点开百度再搜索别的,我服了
|
39
chenyu0532 2021-09-12 08:43:24 +08:00
中了 1 、28 、30
1:我确实不大喜欢写测试单元,写的也比较少,个人觉得还是打 log 比较好 28:确实没看过操作系统的书。平时工作业务逻辑的东西占了绝大多数,个人觉得设计模式更重要一些,所以平时看的也更多 30:少数时候确实忘了 |
40
hanxiV2EX 2021-09-12 09:12:29 +08:00 via Android 1
那我就推荐这本书吧
程序员修炼之道:通向务实的最高境界(第 2 版) |
41
JounQin 2021-09-12 09:39:50 +08:00 via iPhone
写单元测试这个事儿吧,写 Library 那肯定得写,而且必须 100% coverage,但是写 App ?哪有那么多时间啊,需求天天催,自己天天义务性主动加班可能都来不及,所以先把功能做完,后面有时间了再慢慢加。
|
42
Lemeng 2021-09-12 09:52:28 +08:00
有些同意,有些有点偏薄
|
43
aLazarus 2021-09-12 10:01:55 +08:00
关于 CURD 的那一条,我认为楼主想的是,在 CURD 的基础上去寻求突破或者优化。而不是眼睛都不睁开一下就一直在 curd 。
这点我在新公司发现尤为明显,大家都在考虑如何高效并且更高可用性的去优化 curd,这个过程带来的进步是让人享受的。甚至实习生都在问“怎么能把这段代码写的漂亮点” |
44
TUNGH 2021-09-12 10:05:58 +08:00
总结的不错
|
45
Saxton 2021-09-12 10:07:40 +08:00 2
事实上,只要不被老板压榨什么都好,我这个星期连续上了 7 天班,现在还在上班,加班给所谓有钱的客户开发定制功能,星期五提出需求,星期日就要,你跟我谈什么架构,什么设计模式,直接就是 ifelse 上去了,脱了工期都没得饭吃
|
46
JerryCha 2021-09-12 11:18:13 +08:00
哈哈哈,楼主快去应聘招银网络科技体验一把 kanban board 带来的效率提升
|
47
EPr2hh6LADQWqRVH 2021-09-12 11:38:08 +08:00 3
这帖子这么火难以置信,
这么多人活在臆想里吗 上来就给我单元测试, 你真写过单元测试? 你见识过高效能 HR 办理离职手续的速度吗 |
48
CX 2021-09-12 13:27:04 +08:00
从最初的热爱到养家糊口,浮躁的行业风气也有一定责任吧?
|
49
datafeng 2021-09-12 13:36:48 +08:00
学院派?
|
50
ClericPy 2021-09-12 13:56:39 +08:00
有一说一, 除了 29 条正在改正, 其他的居然几年前就纠正过来了, 这么一想还是挺感谢前东家的
|
52
6IbA2bj5ip3tK49j 2021-09-12 15:24:31 +08:00
为何现在这么流行这一套话术:居高临下指指点点,然后再加上一句“共勉”。
|
53
rus4db 2021-09-12 17:01:06 +08:00
①感谢分享
②标准是用来要求自己的,不是用来要求别人的 ③标准是因人因时因地因事而异的 ④要区分“术”与“道” |
54
winrar 2021-09-12 18:19:19 +08:00 1
CSDN 属实垃圾
|
55
index90 2021-09-12 18:28:28 +08:00 2
CRUD 怎么无聊啊,CRUD 最难了
读写缓存,分布式事务,一致性 别跟我说什么都依赖 RDBMS |
56
wtdd 2021-09-12 19:06:51 +08:00
其实用一个字“菜”就能结束的话题……
|
57
lshero 2021-09-12 19:54:59 +08:00
虽然说得很好,但是还是很想知道因果关系。
|
58
hyy1995 2021-09-12 20:08:29 +08:00
某同事读了不知道一本什么书,书中写道:“好的代码是不需要注释的,代码本身就是注释,写注释只会加重负担,因为你代码改了,注释也得改”,然后他自己的代码就真的没有注释……
还好我跟他之间目前没有业务交集,这类人合作起来是真的难受 |
59
hyy1995 2021-09-12 20:25:06 +08:00
|
60
Rexviv 2021-09-12 21:01:21 +08:00 1
@xgfan 每个人读完文章感受不同,我以及楼里对楼主表示称赞的并没有感受到楼主的居高临下。虽然楼主的总结不适用于所有人,甚至很大可能只适用于包含他在内的少部分人,但是楼主经过总结分享出来让大家参考,是不错的举动。为什么要对其进行阴阳怪气呢?(如果你是因为经常看到带有“共勉”的文章里都是输出自己的观点并强加别人,所以对这类文章感到反感,那么你在别人的贴里输出自己的情绪是不是应该反思“己所不欲,勿施于人”)
为楼主鸣不平确实有点越俎代庖,我也不想引起一场骂战,我没有针对你的意思,但是“居高临下”真的很刺眼。 |
61
zhuzhibin 2021-09-12 21:19:56 +08:00
看完了 开始焦虑了 卷
|
62
6IbA2bj5ip3tK49j 2021-09-12 21:22:34 +08:00
@Rexviv 低能效都让 lz 定义完了。这还站的不高?
你没感受到那是你的事。再说了,我也没阴阳怪气啊。 |
63
auh 2021-09-12 21:26:25 +08:00 1
书中写到,认真耕地,你就是牛
|
64
Rexviv 2021-09-12 21:31:02 +08:00
@xgfan 首先,我关注的重点在于他分享出来可以供大家参考,你关注的重点是他凭什么有资格进行这样的定义。在这方面,楼主到底是自我感觉良好才发出来以博关注,或者发出来用以分享自己的感悟,我不得而知。但你说得对的一点是,每个人都有自己的感受,我修为还是不够回复了你。你就当我没回复过你,仅仅只表达了“我没感到楼主居高临下,感谢分享”。
|
65
crclz 2021-09-12 22:43:18 +08:00
个人认为,最重要的书籍是 DDD 、IDDD ( lz 也提到了);再配上足够的实践量和回顾书籍(看很多遍)。
基于这些你才有可能 clean code 、clean architecture 、tdd 、能够写单元测试、避免过度设计、减少单个函数行数…… |
66
zoharSoul 2021-09-12 23:12:44 +08:00
自相矛盾 没啥意义.
建议写明是后端程序员的感悟 |
67
young1lin OP @hyy1995 我没说 《 Clean Code 》全部接受,如果你看过我下面提到的《设计模式之美》——王争写的,他在里面提到过,好的代码无需注释有点极端了,我也是认同他的话的。我看一本书,是觉得他有可取之处,不是说全部接受的。
|
68
young1lin OP @lshero 根据那基本书,和这些视频(当然不止这些,有些不是特别特别好,我就没发了),还有我以前 /现在,还有我的历任同事(不包含全部)。我写完后,才发现原来这些早有前人总结过了。
我的下半年绩效考核里面,就有 30% 是有效沟通,是我自己写的,这方面我是有待改进的。有些问题我也不是全部都改掉了,但我想写下来,记录下来。正如我发的评论的视频,3 rules to quickly improve your life 最后一个就是 Record Everything,是有效的。 |
69
young1lin OP @WilliamYang 其实,还有待改进
|
70
young1lin OP @xgfan 我只是记录下,就算我不写这些,如果你看了那些书,Review 以前的自己,看看历任同事,抑或是极客的专栏,或许你写得比我更多。
|
72
volvo007 2021-09-13 00:28:12 +08:00
和乙方打交道还真遇过一个……
因为刚上手任务,又是跨行业,我建议他不要只盯着当前 task 的客户数据看,而是把整体的数据都看一下了解一下数据特点。 一周之后我问看了没有,答曰看了。我随便问了几个数据特征相关的,比如目前有多少客户的数据、有没有特别有特点的(比如周期出现大幅波动),就开始不高兴了。我追问了一下之后居然发火了,反问我看这些东西对当前业务有什么帮助……真牛,干了不到一个月跳槽走了,希望他在下家做得开心。 |
73
jsjjdzg 2021-09-13 09:48:59 +08:00
已经开始焦虑了,卷起来 😃
|
74
dawdling 2021-09-13 10:38:17 +08:00
这些其实不仅仅是一个体现在工作上的低效能程序员,就是人本身比较低效能。
|
75
SWALLOWW 2021-09-13 11:42:55 +08:00
你们卷把,我是咸鱼,看完前两条就不想看了,想点踩,
道理我都懂,可不适合我 |
76
mac20221225 2021-09-13 13:55:46 +08:00 via Android
第 22 条中了
|
77
Akiya 2021-09-13 15:09:28 +08:00
上班一半以上时间都是在刷手机摸鱼,你是装了监控吗
|
78
iugo 2021-09-29 13:05:28 +08:00
对于团队
我觉得这几点需要在团队中特别强调: - 不做任务拆解, 没有记录拆解. - 不 Review 自己的代码(哪怕是 stage 时稍微看看自己将要提交的内容). - 不写单元测试. - 沟通选择口述, 不做文本和图片记录. - 命名无关紧要. 另外, 这些我也很看重: - 遇到问题选择忽略, 而不是思考各种可能性及解决方式并且记录. - 知其然, 不想知其所以然. - 抵触修改自己或团队内部其他人之前写的代码. |