<tfoot id='62c3h9hc'></tfoot>
  1. <i id='238g0hzk'><tr id='1tryn7nr'><dt id='zv56fg0d'><q id='rwktwe9e'><span id='b76zfj4d'><b id='1xsryprd'><form id='jh49ko1m'><ins id='iy9xbvyi'></ins><ul id='jof6nyqo'></ul><sub id='3n72vndp'></sub></form><legend id='exjr5xsk'></legend><bdo id='fyocum8p'><pre id='gdebci3w'><center id='6lkh74zs'></center></pre></bdo></b><th id='jtlkgbl4'></th></span></q></dt></tr></i><div id='0xw0enox'><tfoot id='20dk1rwv'></tfoot><dl id='kwmi00sj'><fieldset id='rvcffzd0'></fieldset></dl></div>
      <tbody id='5stegxhc'></tbody>

    <small id='yvj078nk'></small><noframes id='hxtuxr5i'>

      <legend id='r86iugf2'><style id='n9lakcyh'><dir id='k7dscrbf'><q id='p3pqm8r8'></q></dir></style></legend>
    • 网站建设公司当前位置 : 网站建设公司 > 知识普及

      如何做好软件的思考

      发布时间:2021-09-14 14:03   浏览次数:次   
      如何做好软件这个问题太大,全面讨论可能需要很长时间。个人如何做好软件和公司如何做好软件,在难度上和方法上可能完全不同,本着思考胜于执行的原则,我近期对如何做好软件做了一些思考和总结,本篇侧重于讨论公司而非个人如何做好软件。
       
      # 什么是好软件
       
      彼得大师说:“没有度量,便没有管理”。在讨论如何做好软件之前,我们不妨先谈谈什么是好的软件?或者更聚焦一点,什么是好的代码?
       
      坦白说,软件质量度量是一个业界难题,质量度量相关的学术文章超过1000篇,度量项高达200+,比较著名的有McCabe的圈复杂度,但时至今日,依然没有公认的软件质量评估的好方法。
       
      ## 基于形式的黑盒化度量
       
      我们当然可以通过代码扫描,通过设置门禁,去看护质量,去统计数据,这是一种显式的度量,这些很有必要也很有效,但是它只是机械行事,捕捉破坏规则的代码。
       
      基于形式的度量,虽有自动化成本低等优点,但过于死板,可能代码完全符合规范,但质量依然很差。所以,相比统计指标的评估,我们更需要基于内容的评估,因为软件的灵魂是设计,是内容而非形式。
       
      ## 基于内容的白盒化评估
       
      Robert C.Martin提出一个评估质量的公式:WTF/min,他认为这是衡量代码质量的唯一有效标准。直白翻译过来就是Review代码的时候每分钟说握草的次数,配上那张Good Code/Bad Code的趣图,画面感十足。
       
      WTF/min自然有点玩笑话的意味,但它其实提出了一个观点,即只有白盒化评估才能真正反映软件质量,这也就是我们经常讲的软件质量要讲良心。
       
      基于内容的白盒化评估需要肉眼评审,很难自动化,效率低、操作难,但它的效果很好,实操中,建议采用黑盒+白盒的组合方式,避免质量评估僵化教条,流于形式。
       
      # 影响软件质量的因素
       
      我们假定整洁、高效、可读、可靠、可扩展、可维护的软件为好软件,基于此,讨论影响软件质量的因素。
       
      按哲学理论,事物都分内因和外因。软件质量的内因被研究得比较多,比如设计、开发、测试等;软件质量的外因,比如文化,氛围,管理等却往往被忽视,其实这些才是影响公司软件质量的主因。
       
      ## 好软件关键靠人
       
      首先,软件实施的关键要素是人。对于公司而言,首先要考虑的是,如何把软件高手吸引进来?
       
      ### 招聘,是提升软件质量至关重要的一环
       
      吸引人的,无非钱和事,待遇好+事情有价值,这两点,大公司都能满足。
       
      但顶尖软件人才不仅看钱和事,他们对文化氛围等软环境比较挑剔,公司不能因为对方挑剔就主动放弃金字塔尖的宝贵人才,而是应该千方百计把他们吸引过来,为他们创造条件,让他们以最佳姿势工作,发挥最大价值潜能。
       
      ### 坚持选拔制
       
      显然,我们不能把想进公司的人都招进来,公司创业初期,受限于客观条件,招的人并非都是高手,寄希望于平凡人做非凡事,这能够理解。
       
      但如果公司发展壮大,要引领潮流,需要提高门槛,加大对软件能力的考核力度,把真正优秀的开发人员甄别出来,选拔进来,并委以重任。
       
      入职后再培养的成本太高了,培养人不是公司的主要职责。把一个不适合搞程序的人培养成软件高手,太难了,公司费力,员工别扭,效果不好,不值当。
       
      所以,选拔比培养重要、有效,要坚持选拔制,许多公司面试环节很多轮考试做题,但如果面试环节松,招进来之后考证,这样其实成本很高。我主张考试认证前置,而非放到入职后,根本原因是考试跟实践有Gap,考试更适合筛选而非工作。
       
      招聘环节更严,会有一个伤害,那就是会影响招聘进度或数量,但它同时有一个好处,那就是提高招聘质量,进而提高软件质量。
       
      软件领域有一个八倍定律,即1个高手的战斗力相当于8个菜鸟,这丝毫不是什么夸张。
       
      而且,如果一个人过五关斩六将面七轮进来之后,他会特别珍惜进入公司的工作机会,不容易流失。
       
      ## 营造基于信任的工程师文化
       
      我们通常讲零信任设计和面向失败编程,但在技术文化上,这样可能并不一定合适。
       
      我更赞同:信任并核查。
       
      即经评估给员工一个初始信任值(比如100),犯错扣分,做对加分,分数越高自由越大,分数越低越约束越多,而不是假设每个人都是傻子,用最傻的那个人的标准要求所有人,这会让正常人觉得智商受到了某种程度的侮辱。
       
      这样的处理方式甚至可以泛化,比如有公司把信任积分制用在报销管理,效果挺不错。
       
      有时候某员工的一个代码错误,被泛化,被放大,然后被拿来限制根本不可能犯这种错误的软件老手,任性的增加各种条条框框,这样既不科学,也不人道,除了换来一点点心理安慰,并不起什么作用,但副作用却不容小觑。
       
      我们要警惕这种情况。
       
      可能很多人会觉得基于防范更好,似乎它更安全,但我觉得更多可能是惯性所致,全面转向可能不现实,但局部改变或许是值得尝试的,退一万步讲,讨论一下终究是有必要的。
       
      ## 重新审视安全与效率
       
      人们常说:安全是红线,安全是木桶的底板,安全是0前面的1,我们听到太多安全生产重要性的言论,以至于,在我们脑海里安全成了一个谁碰谁死的确定问题,在这个问题上,我们甚至失去了独立思考的能力。
       
      开车的安全性肯定低于走路,但为什么国家不禁止机动车?
       
      安全跟效率,是一个此消彼长的关系,需要找平衡点,但实际情况是,我们经常过于强调安全而忽视对开发效率的影响,因为拿安全说事有点政治正确的味道,总容易碰触人敏感的神经,但仔细想来,好像并不是那么回事。
       
      我曾经就安全与效率的问题请教过微信的技术主管,他经常因为故障被通报批评,但微信在安全与效率之间,宁愿牺牲一点安全性换取效率,尤其警惕借安全之名行损伤效率之实,不光微信这样,整个腾讯都如此,因为他们算过账,认为敏捷带来的好处要远大于故障带来的损伤。
       
      阿里是另一个极端,对安全的强调无以复加,对故障的处罚令人窒息,以淘宝为例,每年6.18,双11,双12,春节,妇女节,两会等都要封版,可以提交新特征的时间窗口很小,迭代很慢,出了错,从上撸到下,领导如履薄冰,员工噤若寒蝉,大家都不敢动,这样到底好不好?相比微信的做法谁更好?说实话,我觉悟不够,我不知道。
       
      不同行业对质量和效率的要求不一样,同处互联网行业的腾讯和阿里也有截然不同的做法。
       
      ### 分级,不搞一刀切
       
      其实软件的很多方面,都可以考虑分级制度,不要搞一刀切。
       
      不同业务有不同要求,所以最好的方法,就是分级,一切从实际出发,具体情况具体分析,不搞一刀切,一刀切是粗暴管理,是权力任性。
       
      我们知道,多线程编程,数据竞争,要加锁,加大锁很爽很容易,但大锁往往影响效率,我们要合理设计锁的粒度,管理同此理,需要精细化。
       
      这意味着,我们需要回归初心,回到问题的本质。软件所处的行业不同,对故障的容忍度不同。所以,应该为不同业务或者产品线制定不同的安全编码规范,而不是一上来就对语言做阉割(比如我们禁C++用异常,禁很多系统调用),少干些束人手脚的事情。
       
      ### 容许犯错、非责罚性复盘
       
      容许犯错绝不是纵容放错,先撇清这个关系。
       
      要容许犯错,提倡非责罚性复盘。
       
      软件开发是精细生产,很难杜绝犯错,我们已经有很多制度规范去避免犯错,以及容错机制去纠正错误和控制故障影响,所以,我们讨论的是在严防死守下对待出错的政策。
       
      很多公司都有复盘机制,复盘的出发点和归依应该总结经验教训,似乎为了之后把事情做得更好,但如果对错误责罚过度,很容易出现大家都不敢动的情况,不动固然能减少出错,但也影响迭代,相比故障带来的损伤,往往迭代迟缓更可怕,因为业务速度降下来,往往是致命的。
       
      ## 拥抱开源
       
      优秀的开源项目是技术的宝库,汇集了软件领域的顶级认知和智慧,研究它、学习它对开阔技术视野和提升软件能力大有助益。
       
      开源意味着项目有更多人参与,意味着更大范围博采众长,汇聚更多的奇思妙想,这样才能产生更强大的结果,因为开源代码接受社区全面彻底的检视,所以往往能获得更高的可靠性和安全性。
       
      资浅的程序员容易被带偏,为什么会被带偏?本质上是资浅员工缺乏辨识力。为什么缺乏辨识力?可能是因为他没有见过更好的项目实践。
       
      因为信息传递过程中必然会存在部分失真,假如老员工的代码是80分,如果新员工只是跟着老员工的写法依葫芦画瓢,写出来的代码可能就只有60分,再传承一两代,可能就不及格了。
       
      只学习项目中老员工的写法,天花板就是老员工的技术水平,而参考借鉴优秀开源项目,天花板就是业界顶尖实践,天花板不一样,结果自然也不一样,所以,应尽可能把天花板拔高,这也是显而易见的道理。
       
      但当前政治和商业环境下,大部分开源社区或基金会都或多或少受美国控制,在这样的情况下,大家借鉴或者使用开源技术需要充分评估。
       
      ## 兼容并包
       
      要鼓励员工提出问题,我们经常会说提问题简单,重要的是解决问题,这话没毛病,但也不完全对,因为解决问题需要资源,提出问题的不一定有资源。提出问题有时候也很重要,比如数学上提出那些XX猜想的比证明的往往更重要。
       
      我们不能苛求提出的问题完美无缺,只要讨论自由,哪怕说的不对,大家有思辨力,影响也不会太大,如果讨论不自由,再正确的真理,也会歪曲。
       
      软件开发工作是一种纯脑力劳动,开发者的思想至关重要。每个人的想法都会不同,所以软件开发是很个性化的工作。有时候我们容易陷入“集团军作战”的诱惑,觉得只要堆人上去,事情就能干成。但是在软件开发领域,这不是绝对的。常见那种一个**灵魂人物独挑大梁**,质量数量都很优秀。
       
      如果有这样的优秀人员出现,就应该吸纳他的优点,不要求他与别人保持一致。发挥他的长处,鼓励并尊重他的劳动,而不是磨灭他的热情。
       
      如果没有这样的人员,组织内的员工更喜欢团队协作,那也没有任何问题,大家一起分工合作,彼此支援,鼓励互相支撑互相学习,也能很好地完成软件的开发。
       
      组织应该有足够的灵活性和弹性,来容许各种性格和习惯的开发人员(当然道德败坏或者违反公司规定就不在此列了),兼容并包,海纳百川,有容乃大,才是组织应该追求的目标。
       
      ## 技术管理
       
      软件开发过程最重要的因素是人,但软件开发过程也是一种生产过程,软件开发的结果必然是软件产品的交付,不然就没有意义了。所以对软件开发的管理,意味着将对人的管理,对软件质量的管理,和对开发过程管理进行调和,获取高质量的软件交付,可持续的软件生命,以及软件开发人员的成长和可持续性。
       
      对开发人员的管理和评价,很自然就会用交付的代码来衡量这个开发人员的好坏。这是大方向,但是,是不是一个人写的代码特别多,加班时间特别长,他就是个很好的程序员呢?其实,在软件领域,如果同样的功能,能把代码写得更简洁更清晰,代码量更少,同时交付更快捷有效的程序员,才是更好的。抛弃以代码量和加班时间来衡量程序员,而是以做事的效率和成品的质量来衡量,才是软件企业对开发人员管理的基础。
       
      对软件质量的衡量,也不应该仅限于转测后问题单的多少。鼓励开发人员进行自测,尤其是可重复可追溯的自动化测试,能有效地加深开发人员自身对需求和功能实现的深刻理解。如果交付周期过短,开发人员无法兼顾实现和测试case的编码,在没有测试或者极少测试的情况下仓促上线,那么就会积累这些质量债务,时间一久,代码的质量会越来越陷入恶性循环。
       
      对软件开发过程的管理,公司有很多流程,很多要求要遵守。有时候一些流程非常繁琐,对项目带来的好处也有限,那么项目的管理者,应该有权限或者途经,对流程进行探讨,定制一个符合自己项目的流程,满足公司定义的标准,也不会伤害自己的开发效率。
       
      <i id='7ja60yid'><tr id='eb45s0zk'><dt id='e0mfysp1'><q id='hx303l1f'><span id='xi60cw0k'><b id='5v6gstem'><form id='6bfjh9jj'><ins id='i5gu5prh'></ins><ul id='xva6wex5'></ul><sub id='g8sgv8l3'></sub></form><legend id='6t7bc131'></legend><bdo id='3k3r7f49'><pre id='cnl32tol'><center id='8woxu9jg'></center></pre></bdo></b><th id='a5kczu17'></th></span></q></dt></tr></i><div id='yh3ofsnc'><tfoot id='br812yot'></tfoot><dl id='wl1nee7t'><fieldset id='austla1h'></fieldset></dl></div>

        <legend id='0fs1r83b'><style id='xn2g80qc'><dir id='oofnfvrx'><q id='lu0e0ifv'></q></dir></style></legend>
        1. <tfoot id='lt3by0r2'></tfoot>

          • <small id='nl60n89y'></small><noframes id='o2a67l78'>

              <tbody id='ufvxm2ol'></tbody>

            本文来源于网络,若有侵权请联系3449817223#qq.com,将在第一时间删除。

            下一篇公众号开发下一篇:对软件技术的思考

            <legend id='u25966zt'><style id='u3gannf8'><dir id='mthxrxkv'><q id='xxhk5xjv'></q></dir></style></legend>
              <tbody id='xf7rma40'></tbody>

            <small id='vpip4q8m'></small><noframes id='dqvjfxc2'>

            • <tfoot id='6cagtw5q'></tfoot>
            • <i id='8ce96njn'><tr id='b7xeawep'><dt id='qu3jszo0'><q id='7qfcb4xb'><span id='1w701tef'><b id='terok5hd'><form id='vbn7t0bb'><ins id='3wawhtdu'></ins><ul id='dcz7o1if'></ul><sub id='9ji03vax'></sub></form><legend id='otvu33c3'></legend><bdo id='n72g5enz'><pre id='jbdv3tuu'><center id='1u777ynn'></center></pre></bdo></b><th id='d40kxii9'></th></span></q></dt></tr></i><div id='qpchp0k7'><tfoot id='xsbmd3vo'></tfoot><dl id='89zor7xd'><fieldset id='zau9slkr'></fieldset></dl></div>