Geek_and_Team

极客与团队

Posted by kunnan on October 14, 2018

前言

软件开发是集体项目,要在团队里获得成功,你必须以谦虚、尊重和信任的核心原则。

image

  • 好的点子和高超的技术并不是软件成功的充分条件,你的职业生涯能否成功完全要看你能不能与人合作。
  • 告诉别人你的想法,让别人帮你分担劳力,向别人学习,进而打造一支出色的团队

名词

  • 公车因子(名词):一个项目里,需要有多少人被公车撞到才能令其完全瘫痪。——不要依赖个别程序员的维护和开发,而是要保存可维护性。

    • 你的项目里知识的分散程度是多少?
      • 假如只有你一个人理解原型代码是怎么工作的,那么或许对你的职位的安全程度来说是很高,但要是你被车撞了的话,对项目本身来说就是灭顶之灾了。
      • 但如果有一个朋友和你合作的话,公车因子就可以翻倍。
      • 要是有一个小组一起设计制作原型的话就更好了—项目不会因为某位成员的消失而完蛋

    image

天才程序员的传说

  • 确保失败尽早发生,尽快发生,经常发生
  • 单打独斗比合作风险更高。相比担心自己的创意被偷走或是被人笑话,你更应该担心自己是不是在错误的方向上浪费了大量时间

帮我把代码藏起来是不对的,而是要先确定自己在做的事情是对的,方法也是对的,而且不是重复劳动

  • 没人喜欢被批评(人的本性),特别是还没完成的工作: 这种态度透露出软件开发的某种趋势。缺乏安全感其意味着背后可能隐藏着更严重的问题

  • 隐瞒是有害的: 一直都是单打独斗的话,你其实是增加了自己失败的风险,而且浪费了自己成长的可能性

    • 容易在一开始就犯下很基本的错误,你有可能是在重新发明轮子1。还有你完全丧失了合作的好处。

天才的传说(好点子和高超的技术并不是软件成功的充分条件,你的职业生涯能否成功完全要看你能不能与人合作)

  • 比尔·盖茨,尽管他为早期的家用电脑编写了BASIC解释器,但其实他更大的贡献是围绕MS-DOS创办了一家成功的软件公司。可是这些集体荣誉都被算在了他们这些领袖的头上

  • 自由软件基金会的软件都是由斯托曼编写的吗?

    • 他编写了第一版Emacs,而bash、GCC,以及所有其他运行在Linux上的软件都是由几百名程序员负责的
  • UNIX也是由贝尔实验室里的一小群天才写出来的,并不完全是肯·汤姆森和丹尼斯·里奇的功劳

  • 莱纳斯只是写了一个可以工作的类UNIX内核的初级版本,

    • 莱纳斯真正的成就是领导并协调他们的工作,Linux之所以如此耀眼完全是这些人通力合作的结果

I、尽早分享不仅仅可以防止一开始就步入歧途和检验创意,它还可以强化所谓的“公车因子”。

  • 把公车因子纳入项目的考量中,来确保项目的健壮性

II、 通过团队的反馈来发现自己的计划和设计中需要修改的地方,来确保整体进展的速度

  • 网络虽然是观点和信息的大熔炉,但是它是替代不了人与人之间真正的交流的

    • 直接和别人一起工作能潜移默化地提升集体智慧;这就是软件公司里团队通常都是

      坐在一起(或是在一起结对编程)的原因

      • 程序员是最需要不断反馈的:写一个新函数,编译,加了一个测试用例,再编译一下,又重构了一部分代码,再编译一下。这样就能在生成代码的时候尽快地改正笔误和bug
  • 这种快速反馈不仅在代码层面,对整个项目来说也是必不可少的。有抱负的项目都必须快速演化并不断适应环境的变化。项目可能会遇到意料之外的设计瓶颈,或者行政上的阻力,又或者只是发现事与愿违。需求总是在往意想不到的方向变化。

  • 你要如何通过反馈来发现自己的计划和设计中需要修改的地方?: 团队合作

团队才是王道

  • 通过使用系统并研究如何让系统帮你做事,你就学会了调整系统,让它按照你的意愿工作;

    • 快速失败;学习;迭代——-败是可以接受的”:失败是更上一层楼的绝佳机会

      • 没有经历过失败的话,就说明你的创新还不够,或者你承担的风险还太小
      • 真正的事后检讨应该包含有关“学到了什么”以及“怎么改正”等经验教训的详细注解。后来人指路.
    • 放下自负:避免和各种各样的潜规则做斗争。

    • 学会批评和接受批评:代码审查(codeView)

      • 提出建设性批评和人身攻击之间的区别
      • 你和你写的代码是两回事:别把你的自尊和你的代码等同起来
      • 嗨~我有点看不懂这段代码的控制流程。要是用xyzzy代码模式的话会不会更清楚一点?维22第一章护起来也方便?——–他没有错,只是你理解代码有困难而已;提供了一种方法让可怜的你能理解代码
  • 给秘书们讲笑话,和他们搞好关系,讲笑话逗她开心.投之桃李,报之琼瑶

一份出色的事后检讨应该包含以下内容:

  • 简要

  • 事件的时间线,从发现到调查,再到最终结果

  • 事件发生的主因

  • 影响和损失评估

  • 立即修正问题的步骤

  • 防止事件再次发生的步骤

  • 得到的教训

为学习预留时间

偶尔应该跳出自己的舒适区,在更大的舞台上接受各种挑战

学习保持耐心,恪守了HRT的原则

对影响保持开放的态度

See Also

  • newpost
/Users/devzkn/bin//newpost Geek_and_Team 极客与团队 -t ReadaBookEveryDay
#原来""的参数,需要自己加上""

转载请注明: > Geek_and_Team