编程专业人的良好习惯(练习、时间管理、压力、团队协作)————《The Clean Coder—A Code of Conduct for Professional Programmers》心得

0 背景

此篇为《代码整洁之道——程序员的职业素养》的第五篇读书心得,也是最后一篇心得。主要讲述编程专业人士的练习、时间管理、压力应对、团队和协作。

1 练习

专业人士都需要练习,因为他们关心自己可以做到的最好的结果,他们直到保持自己的技术不能落伍是自己的责任,而不是雇主的责任。练习的时候不赚钱,但是练习后,会获得丰厚的回报。

1 卡塔

  • 1,学习热键、导航操作、测试驱动开发、持续集成之类的方法,(http://katas.softwarecraftsmanship.org )

2 瓦萨

  • 1,两个人对连,一个人写单元测试,另一个人写程序通过单元测试

3 自由练习

  • 1,多人进行的瓦萨

4 开源

  • 1,多去开源设计贡献自己的代码,例如写了很多C++,可以贡献python代码,写了Java,可以为Rails项目做点贡献

5 职业道德

用自己的时间练习,就不必限制与老板规定的语言和平台,选择自己喜欢的语言和技术。

2 时间管理

2.1 会议

2.1.1 是否参加会议

  • 1,只选择能给自己目前工作带来切实且显著的成效的会议;
  • 2,如果会议让人厌烦,就像一个礼貌的版本退出;
  • 3,如果会议是自己已经完成的某些事项或者有职权人的命令时,应该权衡自己的损失和他人的收益,可以和团队中其他同事、主管商量;
  • 4,收到议会邀请时,应弄清楚议程的议题、每个议题花费的时间、要取得什么成果,如果得不到确切的答案,可以礼貌拒绝;
  • 5,如果已经出席议会,发现议会偏移或放弃了原有议程,应该要求列出新的议题和议程,如果没有答案,可以选择合适的时间礼貌离席。

2.1.2 会议的控制

敏捷开发时:
开始时,所有开发者站着,依次回答:

  • 1,我昨天干了什么
  • 2,我今天打算干什么
  • 3,我遇到了什么问题
    每个问题不应当个超过20s,每次会议不超过10分钟。

迭代计划会议:

  • 1,每轮迭代会议所花时间不应当超过5%,如果一周40小时为一个迭代周期,会议时间应该控制在2小时以内;
  • 2,会议召开前,应该完成
    • 评估可选择任务的开发时间
    • 确定这些任务的业务价值
  • 3,验收/组件测试应该在会议召开前完成,或者至少要有概略方案
  • 4,简明扼要的讨论各个候选任务,然后决定是否选择还是放弃,每个任务所花费的时间应限制在5——10min;
  • 5,如果需要详细讨论,则应当另选时间,挑选出团队的一部分人专门进行;
  • 6,在会议末尾,团队成员讨论本轮迭代什么做的对,什么做的不对,展示最新成功的demo,最好在最后一天下班前45min召开,花20min回顾,花25min演示。

注意:

  • 1,凡是不能在5分钟内解决的真论,都不能靠辩论解决。
  • 2,强力无法解决争论,要用数据说话。
  • 3,不要别人这么办,自己就觉得这么办,如果自己同一的话,必须要拿出行动来。

2.2 注意力点数

人的精力和注意是有限,会随着时间流失或者忧虑的事情而减少,而编程是需要持续投入精力和注意力的;

2.2.1 提升注意力的方法

  • 1,保持良好的睡眠;
  • 2,适量使用咖啡;
  • 3,注意里不集中时,做一点其他事情,如沉思、反省、小睡、听播客等来回复注意力;
  • 4,定期进行锻炼;
  • 5,创造的输入知识,如广泛阅读;
  • 6,番茄工作法。

2.2.2 避免行为

  • 1,优先级错乱
    • 定义:逃避真正的工作
    • 专业人士都会排除个人喜好和需要,按照真丝的紧急程序来执行任务;
  • 2,死胡同
    • 定义:选择走不通的技术道路,对这个决定越坚定,浪费的时间越多;
    • 谨慎的态度和积累的经验可以帮助避免某些死胡同;
    • 走入死胡同时,要有足够的勇气走回头路(坑法则:掉进坑,别挖)
  • 3,泥潭
    • 定义:面对简单问题,给出解决方案并保持代码的整洁,之后问题不断扩展,越来越复杂,扩展代码库并尽可能的保持整洁,但是有一天你发现在需求的变化方向上,程序跟不上节奏
    • 专业人士会运用各种努力尽早尽快脱身
    • 如果发现自己深处泥潭还固执前行,是最严重的优先级错乱,继续前进无异于欺骗自己、团队、公司、客户,一边走向煎熬所有人的炼狱,一边告诉大家所有问题都会解决的。

3 压力

尽可能的避免压力,无法避免就勇敢直面。可以通过谨慎承诺、遵守纪律原则、保持整洁来回避压力,直面压力时,保持冷静、与人多沟通、坚守自己的纪律原则并寻求他人的帮助。

3.1 避免方法

  • 1,承诺
    • 做奉献定量化并将它们成熟给业务方,让他们做好想要的准备;
    • 如果业务人员没有实现咨询开发人员就像客户做出承诺,专业人士不一定要节后说业务方代为做出的承诺,但是专业人士会千方百计的找到达成目标的方法
  • 2,保持整洁
    • 一般是“脏而慢”;
    • 保持代码和设计尽可能的整洁;
  • 3,保持纪律
    • 选择自己在危机中依然会遵守的纪律原则,并且在素有工作中都遵守这些纪律;
    • 遵守这些纪律是避免陷入危机的最好途径。

3.2 应对压力

  • 1,不要惊慌失措
    • 鲁莽只会带入更深的深渊;
    • 放松下来,对问题深思熟虑,努力寻找可以带来最好结果的路径
  • 2,沟通
    • 和团队、主管沟通,请求他们的支援和指引;
  • 3,纪律原则
    • 坚信自己的纪律原则
  • 4,寻求帮助
  • 找一个结对编程的伙伴

4 团队协作

4.1 协作

  • 1,程序员与雇主
    • 深刻理解业务目标
      • 理解手上正在编写的代码的业务价值是什么,了解自己的企业如何从自己的工作中获得回报;
      • 理解自己的职责是让业务免于陷入困顿,让公司长久发展下去
  • 2,程序员和程序员
    • 代码共有
      • 如果代码个人所有,那么可能会造成大量重复的代码、模块间的接口完全杂乱混淆而非蒸饺。
    • 应当结对编程
    • 可以相互协作、复查代码
  • 3,单独工作
    • 当需要畅叙努力思考一个问题或者任务琐碎且无足轻重时
  • 4 程序员和人
    • 善于和别人共事合作,享受其中的挑战

4.2 团队

  • 1 团队成员彼此互补,
  • 2,组成:
  • 3——20人
    • 2(程序员):1(测试人员和分析师)
    • 12人组成的最理想的团队(7名程序员,2名测试人员、2名分析师、1名项目精力)
    • 分析开发师/测试人员:编写自动化验收测试;分析师:关注业务价值;测试人员关心可能出错的地方(失败场景和边界测试)
    • 项目精力跟踪团队进度,确保成员理解项目时间表和优先级
  • 3,花时间来培养凝聚力(6——1年)
  • 4,管理团队
    • 使用每周点数(复杂度)来衡量团队的速速(每周完成的工作量);
    • 管理团队为项目设置目标值;
    • 有凝聚力的团队可以快速应对重新分配的优先级
  • 5 项目和团队
    • 如果项目比团队的更重要,就应该快速重新分配资源;
    • 否则,就应该不轻易解散团队,

4.3 辅导(原则、实践、技能)

软件工程师应该像医生一样,先经过一段时间的实习培训,然后再正式上岗工作。

4.3.1 学位教育

很多在大学只是混得了一纸文凭,但实际编程都根本不懂。很多符合编程要求的毕业生都是很早之前就自学编程,并在大学里保持着自学的习惯。

4.3.2 工程师的各个时期

  • 1,学徒/实习生
    • 没有“自治权”,需要在熟练工的辅导下工作;
    • 了解设计原则、设计模式、各种纪律和固定操作环节;
    • 熟练工向他们传授TDD、重构、估算等各种技艺,为学徒安排阅读、练习和实践任务;
    • 学徒期应该至少持续一年
  • 2,熟练工
    • 学习在团队中卓越工作和成为团队的领导者;
    • 对当前系统十分了解,但是对其他系统缺乏经验;
    • 只了解一种语言、系统、平台;
    • 平均经验在5年左右。
  • 3,大师
    • 领导过很多重要的软件项目;
    • 已拥有10年以上的经验;
    • 曾经在多个不同版本的系统、语言和操作环境上工作;
    • 懂得如何领导和协调多个团队;
    • 熟练的设计师和架构师,可以游刃有余的编程

但实际情况是几乎没有技术层面的督导,全靠程序员自己表现。

5 预估

开发方认为是猜想,业务方认为是承诺。

5.1 承诺

  • 1,承诺是必须做到的;
  • 2,专业人士不随意承诺,除非他们确切知道可以完成;
  • 3,不能兑现的承诺是一种欺骗,会对自己的名誉造成损失。

5.2 预估

  • 1,计划评审技术(PERT)【为支持海军潜艇极地航行计划】
    • 乐观估计:一切都异常顺利;标准预估:概率最大的数字;悲观估计:考虑各种意外
  • 乐 观 估 计 : O ; 标 准 估 计 : N ; 悲 观 估 计 : P ; 乐观估计:O;标准估计:N;悲观估计:P; O;NP
  • μ : 任 务 期 望 完 成 时 间 ; σ : 任 务 的 标 准 差 ( 用 于 评 估 任 务 的 不 确 定 性 ) μ s e q u e n c e : 总 的 任 务 时 间 μ:任务期望完成时间;σ:任务的标准差(用于评估任务的不确定性)μ_{sequence}:总的任务时间 μσμsequence:
  • μ = ( O + 4 N + P ) / 6 μ = (O + 4N + P)/6 μ=(O+4N+P)/6
  • σ = ( P − O ) / 6 σ = (P - O)/6 σ=(PO)/6
  • μ s e q u e n c e = s u m i n μ i / σ i μ_{sequence} = sum_{i}^nμ_{i}/σ_{i} μsequence=suminμi/σi
  • 2,德尔菲法(讨论预估,直到意见统一)
  • 亮手指(预估的单位在会议开始就必须确定)
  • 扑克规划
  • 关联预估
    • 把所有任务写在卡片上,任务按时间长短排序(左短右长),每个人都可以把卡片重新排序,所有人排序完后,讨论被移动次数超过n次卡片
  • 3,大数定律
    • 因为预估很容易出错,所以需要使用大数定律来控制错误
    • 把大任务分成许多的小人物,分开预估再加总

6 技艺

“工匠”一词包括的是心智、技能和质量的意味。有着经验丰富、堪当重任的印象,技术熟练、从容淡定,能够合情合理的估算并遵守承诺,知道何时说“不”,但更懂得如何承诺。

技艺是工匠持有的精神状态,煲剧哦价值观、原则、技术、态度和正见。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 岁月 设计师:pinMode 返回首页