关键词:
一、关于代码规范
1.1
因为软件开发多数是一个团队的事情,所以需要格外注意代码规范。我们的代码日后通常是需要去维护的,是需要去给别人看的。但是,不同的编程语言对代码规范的要求是否相同呢?
因为在工作室学的是前端语言,我对前端的代码规范比较了解。
有一位博主总结的前端代码规范,个人感觉非常好:https://www.cnblogs.com/qinyi173/p/7150644.html
1.2
书中(P63)页提到 ”匈牙利命名法“ ,并说到:
”在这类语言中,前缀就不是很必要,匈牙利命名法并不适用。微软的.NET框架就不主张用这样的命名法则。“
这句话说明不同的语言、不同的框架,所适合的命名法则是不同的。那我们常用的命名法则有哪些呢?
我上网搜索了一下这个问题,找到了一篇博客:https://www.cnblogs.com/Offie/p/5021368.html
这篇博客中提到了3种命名方法:驼峰命名法、帕斯卡命名法、匈牙利命名法。
以下,简单总结一下这3种命名法的特点:
驼峰命名法:函数名中的每一个逻辑断点都由一个大写字母来标记。在许多新的函数库和Microsoft Windows这样的环境中,它使用得当相多。
帕斯卡命名法:与骆驼命名法类似只不过骆驼命名法是首字母小写,而帕斯卡命名法是首字母大写。
匈牙利命名法:通过在变量名前面加上相应的小写字母的符号标识作为前缀,标识出变量的作用域,类型等。顺序是先m_(成员变量), 再指针,再简单数据类型,再其它。
以下是3种命名法的举例:
MyData 就是一个帕斯卡命名的示例
而myData是一个骆驼命名法,它第一个单词的第一个字母小写,后面的单词首字母大写,看起来像一个骆驼
而iMyData是一个匈牙利命名法,它的小写的i说明了它的型态,后面的和帕斯卡命名相同,指示了该变量的用途.
二、关于代码复审
之前我们了解了单元测试,是确保代码质量的一种方法。乍一看代码复审,好像功能与测试差不多,但其实这是两件不一样的事情。
书中(P72)说到:
“要注意避免不必要的繁文缛节,我们做代码复审的目的是为了减少错误的发生,而不是找一个人来对着你的代码点头。一些简单的修改不是非得要一个复审者来走一遍形式。在项目开发的早期斤斤计较于一些细枝末节(例如:帮助文件里的拼写错误,数据文件格式不够最优化等)也是于大局无补的,但是,这些问题并不是不用处理了,我们可以建立一些优先级较低的工作项来跟踪处理。”
我觉得,书中这一段说得很好,代码复审的过程就如同我们解决问题的步骤一样。
做一件事情,我们要不时回过头去查漏补缺一番,在查漏补缺的过程中,我们要给发现的问题确定优先级,从而判断这个问题是否亟待解决。
所以,我想知道,在代码复审的过程中,哪些问题是属于优先级低的问题?
我查了一些相关的博客,主要有以下观点:
1:Code review 不应该承担发现代码错误的职责。
Code Review主要是审核代码的质量,如可读性,可维护性,以及程序的逻辑和对需求和设计的实现。
代码中的bug和错误应该由单元测试,功能测试,性能测试,回归测试来保证的(其中主要是单元测试,因为那是最接近Bug,也是Bug没有扩散的地方)
2:Code review 不应该成为保证代码风格和编码标准的手段。
编码风格和代码规范都属于死的东西,每个程序员在把自己的代码提交团队Review的时候,代码就应该是符合规范的,这是默认值。
属于每个人自己的事情,不应该交由团队来完成,否则只会浪费大家本来就不够的时间。
而代码复审需要注意的问题在书中(P73)的核查表中已有详细说明。
三、关于敏捷开发
书中(P75)提到:
“结对编程随着敏捷思潮的兴起而广为人知,然而这种实践早已有之。”
什么是敏捷思潮?这是怎样的一种开发模式?
我在百度百科上找到了详细的关于敏捷开发的介绍,并仔细地阅读了。
其中,敏捷开发的宣言原则叙述得既有艺术性又简洁明了,故摘录如下:
四、关于牛仔式编程
名词解释:“牛仔式编程”,这个词我们用来描述那种直接在生产环境服务器上修改代码的行为。“戴着粉红色的大檐帽”表示你要严格的检查,谨慎的决定。
书本在第77页提到 “牛仔式编程” ,这是一种不提倡的行为。
五、关于提意见
书中(P81)中提到的4种影响他人的方式,分别是断言、桥梁、说服、吸引。
”没有绝对正确或错误的方法,只有合适或不合适的方法。“
书中讲的是我们要根据不同的情形,选择说服别人的方法,温和的方法有助于彼此的理解,但遇到紧急情况就要态度坚决。
我觉得,这4种方法是否不仅可以根据不同的情形选择使用,还可以根据不同的用户性格选择说服的方式,使用户与开发者的目标达成一致呢?
在 “如何正确地给予反馈” 这一节里,我学习到,你批评别人的不同层次会给别人带去不同程度的影响。
应该要这样做,不论你多么生气,都不要评论别人的本质和固有属性,尤其是对待你的亲人和朋友,永远都别说出最伤人的那句话。
六、关于猪、鸡和鹦鹉
书中大致是这么为3种动物的贡献排序的(如果我没理解错的话):猪 > 鸡 > 鹦鹉。
因为猪是 ”全身心投入“(Committed)、鸡是 “参与”(Involved)、鹦鹉是 “围观”(Bystander)。
但我觉得,这么说是不合理的。这3种动物的特长不一样,他们在团队中都贡献了自己擅长的部分。
比如在一个企业中,鹦鹉好比是市场推广,或者是领导人员,他们虽然不像一线程序员那样埋头苦干,但他们只要是全身心的为这个项目筹划,就是全力以赴的“猪”。
我们不能用做的事情类别去定义一个人的贡献度,企业需要分工,每个人在自己的岗位上全力以赴,才能完成项目,不是吗?
因为常看见软件行业的一些求职鄙视链,我觉得这是不好的。
由这个话题引申,我觉得对于我们本科生,应该尝试着去发现自己擅长的部分,为以后我们的职业定位做一个基础。
七、关于绩效管理
绩效管理确实是提升团队绩效、提升部门乃至企业效率的好方法。我觉得,我们应该学习绩效管理。但这个不适合在我们的组队作业中实行。
首先,绩效管理其实是有淘汰制的,他在企业中是用利益驱动的。但我们的团队成员是我们的同学,我们的目的是互相帮助、互相学习,我们可以在讨论的情况下确定每个人的贡献比,因为这是有目共睹的,而不是采用淘汰制。
其次,取得好成绩是团队共赢的模式,而内部竞争会导致内部损耗。企业由于人数多,每个人之间的联结小,共同利益少,因此需要个人为单位的竞争。但我们的学生团队本就有共同目标,应该 ”一致对外“、一起努力才对。
最后,在百度百科中有关于绩效管理的这句话:
“绩效管理体现着“以人为本”的思想,在绩效管理的各个环节中都需要管理者和员工的共同参与。”
绩效管理一定需要一个管理者,那在我们的团队中如何确定这个管理者呢?不管是对推举形式上,还是管理者的个人素质都有很高的要求吧。
总之,我觉得绩效管理应该用于较多人数的团体,因为这个管理做不好是会带来矛盾的,而小团队的内部崩坏无疑于是灭亡。
八、last but not least:职业道德
这里引用一篇关于软件工程师职业道德规范的博文:https://blog.csdn.net/dipolar/article/details/61413999
我们学习的计算机这门技术,有很大的功用。如果被居心不良的人随意使用,后果会很严重。所以,职业道德是第一位的。
各种职业道德的文件都表明:计算机专业人员应当以公众利益为最高目标。
《构建之法》第四&十七章读书笔记
《构建之法》第四&十七章读书笔记一. 前言 再次阅读《构建之法》,愈发被其中生动有趣的举例吸引。作为一本给予软件工程学生的书籍,其不以枯燥的理论知... 查看详情
《构建之法》读第十七章收获(代码片段)
《构建之法》读第四、十七章收获第四章两人合作读了第四章,我才意识到代码规范的重要性,代码不仅要自己看懂,也要能让别人看懂,代码规范能使团队合作更好的进行。代码规范分为代码风格规范和代码设计规范。其中代... 查看详情
《构建之法》第第十七章读后感(代码片段)
第四章 在这一章最后一页“让独占一样还有一个好处:一眼就能看出是否有多余的代码行,还有些情况下是致命的错误”给出的参考链接http://lpar.ath0.com/2014/02/23/learning-from-apples-goto-fail/,我还是没明白的致命错误在... 查看详情
读《构建之法》第四章第十七章(代码片段)
第四章《两人合作》1.原文:“注释(包括所有源代码)应该只用ASCLL字符,不要使用中文和其他字符,否则会极大影响程序的可植性”疑问:引擎根本不对空行和注释进行解析,直接忽略掉,它们不参与计算代码行数也不参与... 查看详情
关于《构建之法》第四章和第十七章的问题(代码片段)
关于《构建之法》第四章和第十七章的问题第四章:问题一:在关于“缩进”,书中不提倡用tab键。而建议使用四个空格。但是tab键可设置占符数,在实际开发中,tab键是缩进的快捷键,我无法想像每次使用缩进都要敲四次空格... 查看详情
week4-作业1:《构建之法》第四章第十七章阅读笔记与思考
第四章 两人合作 这一章是讲述了两人结对编程的一些东西,包括一些代码的规范,还有结对编程的优点、怎么做、以及一些注意事项。1、“错误处理当程序的主要功能实现后,一些程序员会乐观地估计只需要另外20... 查看详情
读《构建之法》第四章第十七章
第四章 两人合作 通过对于《构建之法》第四章的阅读使我对代码规范、代码复审、以及结对编程有了更加深刻的认识,所谓代码规范可以分为两个部分,代码风格规范和代码设计规范,代码风格规范的原则是:... 查看详情
《构建之法》——第第十七章
第四章,主要内容为讲述两个程序员(从作者大篇幅讲述代码规范等内容来看…应该是把大部分阅读此章的读者看作基础的程序员了)如何合作。这章我在看完之后分了两个板块:“代码交流”与“合作交流”。“代码交流... 查看详情
读书笔记(代码片段)
前言 这个星期我仔细阅读了《构建之法》的第四章与第十七章,感触颇深,学习了很多,在此提出自己的问题和部分看法。 第四章两人合作 P74注释 注释(包括所有源代码)应该只有ASCII字符,不要... 查看详情
读构建之法第十七章有感(作业四)
第四章:问题:看到这里的时候,才注意到代码中的“下划线”这个东西,在之前的敲代码过程中并没有怎么遇到下划线,在经过百度后得到了一些答案: 这只是Python中下划线的一部分应用,在不同的语言中,下划线的用处... 查看详情
阅读《构建之法》第四章第十七章收获
阅读《构建之法》第四章、第十七章阅读这一章的时候,我意识到了很多以前写程序没有注意到的地方,以前写程序就只知道能运行就好,根本不管自己写的程序占多少内存,运行的时间,是否有优化的空间,写代码的时候也不... 查看详情
读《构建之法》第十七章有感
&n 查看详情
构建之法第四章第十七章
一、关于goto函数:滥用goto语句会使程序变得很难理解,而不是所有人能正确的使用goto函数,我的问题是:是不是因为这样所以很多文档规定禁用或少用goto函数?但其实如果可以正确的使用goto语句就不能说程序结构坏了?所以... 查看详情
谈谈我对构建之法第四章与第十七章的理解
第四章:两人合作 问题一: 引用:“对于至关重要的代码,我们要请不止一个人来做代码复审” 理解:我对于这句话有些疑问甚至有些反驳。首先我觉得每一段代码都是应该被重视的,也许对于一个刚... 查看详情
读《构建之法》第四章第十七章有感
书是我们永远的朋友它陪伴我们走过人生的春夏秋冬在我们的生命中生根、发芽、枝繁叶茂书是人类发展的录像机我们可以在其中看到前辈的足迹 书是知识的海洋我愿是一叶轻舟,载着理想之帆在海面上荡漾它蕴含着祖祖辈... 查看详情
读构建之法第四章第十七章有感
第四章 1、原文;“函数最好有单一的出口,为了达到这个目的,可以使用goto.只要有助于程序逻辑的清晰体现,什么方法都可以使用。——P69” 问题:关于goto,我记得老师讲过,这个在编程中是尽力避免的,所以我在之... 查看详情
我读《构建之法》十七章
这几天我都在读《构建之法》第四章和第十七章,看的比较缓慢也比较认真。根据精读的要求和个人看书的习惯,我总共读了三遍,第一遍是大致浏览了一遍内容,第二遍是静下心来圈画、标注疑惑内... 查看详情
《构建之法》第四章第十七章读后感
第四章问题:如果另一个合作者不合作的话,我是应该选择脱离这个团队还是去催他工作? 本章讲了许多关于结对编程的内容,文中写了结对编程的分工问题,结对过程中会出现的问题以及结对合作的不同阶段。 正常来... 查看详情