606
社区成员




原文地址:https://bbs.csdn.net/topics/613651782
【来源】
4.5 结对编程
在结对编程中,任何一段代码都至少被两双眼睛看过,两个脑袋思考过。代码被不断地复审,这样可以避免牛仔式的编程。
【疑问与自身看法】
在结对编程部分,书中提出结对编程可以通过代码的不断复审避免牛仔式编程。对这部分我产生了两层次的疑问。
首先,什么是牛仔式编程?通过查阅资料,我找到了两种定义,一种说牛仔式编程是指非常规编程,例如一些牛人写出的取巧但有效的程序代码;另一种则说牛仔式编程用来描述那种直接在生产环境服务器上修改代码的行为,例如为了敏捷实现修改需求而直接跨过流程修改代码。不过具体是哪个定义我没有找到来源。
其次,为什么要避免牛仔式编程?无论是哪个定义,我们可以看出牛仔式编程的核心特点是灵活、直接、独特。这其实与我在中学时学习数学竞赛时所追求的一种好的解法类似,在做一些数学题时,我们往往希望找到一种独特的巧妙的解法,不过过往的经验也告诉我此类解法往往有更大的错误的几率。在软件工程项目中不同之处在于稳定与合作,我们需要尽可能减少bug出现的几率,同时也要增强合作性,而可读性就是很重要的一部分。这也许是工程编程与竞赛题目不同的地方,也是要一定程度上避免牛仔式编程的原因。
在第一次作业的提问中,我提出疑问:“为什么要避免牛仔式编程?无论是哪个定义,我们可以看出牛仔式编程的核心特点是灵活、直接、独特。”这个在我的前端合作实践过程中有了深刻的体会。
在给前端页面添加样式的时候,其实是有很多方式的,比较突出的方式有使用现有的组件为主、以及自己书写类并修改css属性为主。第一种方式简约、受局限,并且相对规范。第二种方式则可以根据自己的想法进行很多细微的调整。在我书写的时候,更多的时候偏向于第二种方式。
但是在团队合作过程中,其实很难保证一个页面的样式就固定是由一个人来全程调整的。我们在开发完页面架构与功能时,经常出现由一个人或多个人统一修改样式的情况。这时,这个人就要去修改别人书写的代码,而前端代码可读性往往不好,尤其是CSS样式部分。而我使用第二种方式的习惯就让style部分变得可读性很差,也为修改样式的同学带来了困难。
通过这一次时间经历,我明白虽然牛仔式可能更灵活更独特,但是更多时候是有使用条件的,他更适用于个人秀。我在提问时也提到:“在做一些数学题时,我们往往希望找到一种独特的巧妙的解法”,灵活的解法适合于少数人的灵光一现,其实并不适合更具普遍性的团队合作。