(三): 说说代码

最后更新于:2022-04-01 03:38:03

> 原文出处:https://www.phodal.com/blog/rethink-3-about-code/ > 作者: [Phodal Huang](https://www.phodal.com/blog/author/root/) 众所周知在我们公司的面试流程比较复杂——其中有一个是Homework,即给候选人一份作业,三天之内完成代码,然后会对其Review。然后的环节便是到Office结对编程。今天有幸成为一名年轻的面试官,经历了今天两小时的学习后,发现自己在代码方面还是“很弱”。 ## 无关的编程经验 > 只要我有更多时间,我就会写一封更短的信给你。 从小学算起我的编程年限应该也有十几年了吧,笑~~。只是我过去的多年编程经验对于我现在的工作来说,是多年的无关经验(详见《REWORK》——多年的无关经验)。 高中的时候学习了点游戏编程,也因此学了点C++的皮毛,除了学会面向对象,其他都忘光了。随后在学习Linux内核,当时代码里就各种struct。比起之前学过的Logo和QBASIC简直是特别大的进步,然当时觉得struct与面向对象两者间没啥太大区别。在那个年少的时候,便天真的以为程序语言间的区别不是很大。 大学的时候主要营业范围是各种硬件,也没有发现写出好的代码是特别重要的一件事。也试了试Lisp,尝试过设计模式,然后失败了,GoF写DP的时候一定花了特别长的时间,所以这本书很短。期间出于生活压力(没有钱买硬件),便开始兼职各种Web前端开发。 在有了所谓的GNU/Linux系统编译经验、写过各种杂七杂八的硬件代码,如Ada、汇编,要保证代码工作是一件很简单的事,从某个项目中引入部分代码,再从某个Demo中引入更多的代码,东拼西凑一下就能工作了。 多年的无关经验只让我写出能工作的代码——在别人看来就是很烂的代码。于是,虽然有着看上去很长的编程经验,但是却比不上实习的时候6个月学到的东西。 只是因为,我们不知道: 我们不知道。 ## 代码整洁 过去,我有过在不同的场合吐槽别人的代码写得烂。而我写的仅仅是比别人好一点而已——而不是好很多。 然而这是一件很难的事,人们对于同一件事物未来的考虑都是不一样的。同样的代码在相同的情景下,不同的人会有不同的设计模式。同样的代码在不同的情景下,同样的人会有不同的设计模式。在这里,我们没有办法讨论设计模式,也不需要讨论。 我们所需要做的是,确保我们的代码易读、易测试,看上去这样就够了,然而这也是挺复杂的一件事: 1. 确保我们的变量名、函数名是易读的 2. 没有复杂的逻辑判断 3. 没有多层嵌套 4. 减少复杂函数的出现 然后,你要去测试它。这样你就知道需要什么,实际上要做到这些也不是一些难事。 只是首先,我们要知道我们要自己需要这些。 ## 别人的代码很烂? 什么是很烂的代码? 应该会有几种境界吧。 1. 不能工作,不能读懂 2. 不能工作,能读懂 3. 能工作,很难读懂 4. 能工作,能读懂,但是没有意图 5. 能工作,能理解意图,但是读不懂 如果我们能读懂,能理解意图,那么我们还说他烂,可能是因为他并不整洁。这就回到了上面的问题,模式是一种因人而异的东西。 我们在做Code Review的时候,总会尝试问对方说: “这样做的意图是”。 对于代码来说也是如此,如果我们能理解意图的话,那么我们要理解代码相对也比较容易。如果对方是没有意图,那么代码是没救的。 ## 自我救赎 于是,回到开始的地方,现在的我还是只能写出整洁的代码。
';

(二): 如何照顾团队中的新人

最后更新于:2022-04-01 03:38:00

> 原文出处:https://www.phodal.com/blog/rethink-one-help-new-hire/ > 作者: [Phodal Huang](https://www.phodal.com/blog/author/root/) 当我们在说照顾的时候,我们实际上是在给新人减压。当我们在说容忍犯错的时候,我们实际上说你可以犯一两个错误。减压更像是在塑造一种更好的学习体验,或者说更愉快地学习方式。 ## 学习与构建系统 学校的时候,学习倾向于理论性的学习。 工作的时候,学习倾向于应用性的学习。 两种不同方式有着不同的区别,即一个广度,一个深度。 在构建系统的时候,通常我们需要一个基本能工作的系统,其次在系统不断开发的过程中。我们对于深度了解的需求已经变得比广度更为重要。 故而,在一个以产品为主的开发团队中,在早期他们更需要那些有广度和速度作为支撑的开发人员,在后期则需要以深度作为支撑的开发人员。 两种人才可以在不同的时期发挥着重要的作用。 ## 学习体验 在《认知设计》一书中,提到了下面的学习体验,即"流"(Flow)。而在我们学习的过程中,我们也会有类似的学习过程。 ![document/2015-09-25/5604ddf6a0951](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604ddf6a0951.png) 如在早期我学习Emcas和GNU/Linux的时候,也曾经放弃过,虽然在当时我已经读过Linux内核。然而,在应用之前进行理论学习并没有卵用。 通常我们会有类似于下面的学习体验,对于一本书来说有下面的体验似乎也是一件很不错的事: 1. 在最开始学习的时候,我们需要一点理论基础,以及我们需要学点什么。 2. 然后,我们需要构建一个简单可用的系统,以获取信心。如果我们在这一步没有想象中,那么简单,那么我们可能会放弃学习。或者等到某个时期成熟的时刻,如在我开始学习《设计模式》的时候,那么本书的高度太高了。直到有一天,我了解到了一本叫《Head First设计模式》的书,才重新把GoF的书看了一遍,发现其实也没有想象中的难。 3. 接着在我完成了某个功能之后,那么我可能继续学习某个理论,用于支撑我的下一步计划。 4. 在那之后,我觉得这一步可能也不是那么难,因为已经有了前面的基础。如果在一步失败的时候,那么我们可能会继续寻找某些可靠的方案,又或者是理论支撑。 5. 。。。 6. 直到有一天,我们来到了一个瓶颈的前面,现有的方案已经不满足我们的需求。对于这个问题,我们可能已经没有一个更好的解决方案。于是,我们可能就需要创建一个轮子,只是在这时,我们不知道怎样去造轮子。 7. 于是我们开始学习造轮子。 8. .... 只有当我们保持一个学习的过程,才会让我们在这一步步的计划中不会退缩,也不能退缩。 ## 如何照顾团队中的新人 在前面,我们已经说了足够多的废话,来支撑我们的标题。 在上篇[《如何构建理想的开发团队》](https://www.phodal.com/blog/rethink-one-build-dream-team/)中我们说到了一点,即结对编程。在结对编程中会存在至少三种模式: 1. Coach模式。在我现有的经验里,这个模式对新人会帮助比较大。通常来说,我们是要分解任务,然后带领新人一步步完成任务。或许你注意到就是上文中说到的那个心流的过程。在这个过程中,很容易明白这是怎样的情况。 2. 导航模式。在一步中,有经验的人更多的是充当观察模式。有时,当新人不知道往哪个方向就知道提示。当新人犯错时,**最好**看着ta犯错。 3. Pair模式。理想的结对编程便是在这样的模式之中。而要达成这样的目标需要两个人之间有很好的默契,以及在某方面相接近的能力。在一步中,如果可以平衡好两人的步骤,那么对新人的自信心想必是有很大的帮助。 采用结对编程不仅可以提高新人的水平,对于老人的能力也是很大输出。即之前别人输入我们脑子中的想法,我们需要再传递出来。对于程序员这一类人必然会有很大的提高,如果你不擅长表达的话。 ### 结论 所以,我们所说的照顾实际上是一个更好的学习体验。 1. 最开始的时候教会如何细分任务,并带领他学习 2. 给他指导,让他自己完成工作。 很我时候,我们总是局限于第二步,故而无法更好地指导他们完成工作。
';

(一): 如何构建理想的开发团队

最后更新于:2022-04-01 03:37:58

> 原文出处:https://www.phodal.com/blog/rethink-one-build-dream-team/ > 作者: [Phodal Huang](https://www.phodal.com/blog/author/root/) ## ReThought (一): 如何构建理想的开发团队 **引言**: 过去,关于理想的开发团队似乎是一个热门的话题,所以我也来凑凑热闹。人们想要理想的开发团队,只是因为在传递知识的时候很痛苦。人们总在说,这个地球多你一个不多,少你一个不少。假想有一天你们团队中的主力走了,那么你们的团队会怎样?塞翁失马,焉知非福。 也许上个月我们团队里走了个汉子,来了一个萌妹子。也许下个月会走个老人,那必然也会来个新人。对于个人来说,这是件好事。但是对于团队来说,则有待商榷。于是,也将过去的一系列思考整理成一些文章,方便和以后的想法进行一些对比——有时候会发现最初的想法都挺好的,只是没有记录下来。 ## 最初的团队 ![document/2015-09-25/5604dd1c91eca](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd1c91eca.png) 有时,我在想最理想的团队莫过于一些创业团队了—— 分工明确。那些还存活着的公司在过去都有着那样理想的团队,然而随着公司业务与团队人数的增长,离这一些越来越远。 在我认识的那些创业公司的前端人员中,多数可能还充当着后台 API、App的开发,原因可归类为: 1. 招不到人 2. 没有钱 3. 不知道招什么人 (他们自己并没有意识到自己不知道) 如《REWORK》一书中所说的那样,只有在你真正受不了时才招人。如果同那些大公司一样,漫无目的地进行撒网,那么早晚会死在这条路上。通常在那些存活下来的团队(也包含没有存活下来的团队)里,一个人可能身兼多职,会有小部分的重叠,但是不会太多。 在这一个时期主导团队往往是Idea的所有者,Owner找来一个技术人员,这个技术人员再依照短处去寻找需要的人才。 ![document/2015-09-25/5604dd2e45779](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd2e45779.png) 随着公司业务的发展,出于个人、家庭、团队因素,总有些人会离职(人总是有需求的,WiFi应该是最底层的吧),总需要迎进新人。 ## 有序的团队 最初整个宇宙是混乱的、整个系统是混乱的、整个组织是混乱的。通过不断地分门别类,整个系统看上去似乎有序了。 ![document/2015-09-25/5604dd42aa87c](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd42aa87c.png) 在这样的团队里,A做着A应该去做的事,B做着B应该去做的事。 1. 如果A和B很熟悉,可能产生出ab —— 可能是一个新的系统,也可能是一个新的生物。 2. 如果A和B不熟悉,那么通过公司的各种各样活动会帮ta们产生ab。 3. 如果A和B不得已熟悉,那么我想这个ab可能是API。 在最初的团队里,A和B可能只隔着10cm,后来他们越来越远。 职能分明的团队是一个解耦后的系统,他们间的沟通需要比原来花费更大的开销。在传统IT公司及大部分的互联网公司都有这样的"最后一公里"问题。引自之前的文章[《知识论(一): 知识传递》](https://www.phodal.com/static/media/uploads/rethink/https://www.phodal.com/blog/knowledge-transfer-part-1/) : > 传统软件开发流程中,知识传递的方式主要在于文档,而我相信在网上已经有足够的证据可以表明,程序员既讨厌看文档,又讨厌写文档。 无论是在系统集成环节,又或者是在交接环节,人们所做的一件事只是知识传递。因为职责让你不可能接触太多的东西,就好比原来你可以每天吃一点的药,突然要你在短期内吃完。 ## 理想团队 团队类似于人物文明,更多地在于文化与知识的传承。人们想要一个理想的团队,但是他们往往并不知道他们真正的问题不在于团队本身——而在于团队是如何协作的。 ### 理想型A 在多数的公司里,团队的组成方式类似于下图: ![document/2015-09-25/5604dd517f559](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd517f559.png) 如果有一天大牛出车祸了,中牛roll off了,团队就剩下一堆绿帽子了... 在这样的团队里,我们可能会用下面的方式来教授团队的成员: ![document/2015-09-25/5604dd59cbf5d](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd59cbf5d.png) 即类似于传统的授课制: 1. 你今天去把《Thinking Java》看一遍 2. 你今天去把《设计模式》看一下 3. ... 在这时候,那些领悟力比较好的就在NB的路上了,但是每次只会有那么一两个人。 ### 理想型B 在另外一个理想型的团队里,人们想要的是这样的结构。 ![document/2015-09-25/5604dd649376a](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd649376a.png) 我想不到这样的团队还有怎样的知识可以传递。在这样的团队里,传递知识是相当于容易,因为大家很容易就懂得别人说的内容。 让团队中的每一个人都是全栈程序员的难度很大,然而这并不意味着这样的团队不可构建。 ## 构建理想团队 在过去我们有师徒制,这样可以保证师徒间知识可以传递下来。而在多数的软件开发团队里,并不存在这样的制度,换句话说在这样的环境成长时,你只能依靠你自己。 > *在一个团队里,当来了一个新人时你们会怎么做?* 如果你是一个新人,你来到这样的一个团队: 1. A 教你如何使用各种快捷键。 2. B 教你使用一些特定语言的技巧。 3. C 教你一些基本的DevOps技能。 4. D 教你怎么追妹子。 5. ...... 你会考虑加入这样的团队吗? ### 结对编程 或出于公司文化,或出于对自己的不明确认知,多数市场主导的公司并不会采用这样的方式来工作。这也导致了人们一直在追逐理想的开发团队时,一直找不到合适的时机。 ![document/2015-09-25/5604dd708a632](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd708a632.png) 这时,也许会有人提醒你,你多了个分号。我曾经在看别人的面试作业时因为多了分号,reject了一个人——因为语言是Python。 而这时候团队的组成,倾向于下图(图是盗的,上面的图也都是盗的 :) ): ![document/2015-09-25/5604dd7ae921c](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/document_2015-09-25_5604dd7ae921c.png) 在这样的团队里,并非每个人的技能都需要是一样的。会出现重叠,一个比一个强,可能有一个的技能点数是最强的。项目在不断开发地过程中,总会有人离职,有新人进来。 然而,在这个结对编程的过程中,知识都在不断地传递。 (ps: 上面只是提到了结对编程会构成理想团队,更多内容请期待下文《ReThink2: 如何照顾团队中的新人》(9月10号))
';