zoukankan      html  css  js  c++  java
  • 《高效程序员的45个习惯》-末篇

    请您在阅读本文之前,先了解《高效程序员的45个习惯》-之三

    每一期都会涉及15个话题,用3期来列出这45个习惯,每次不贪多,贪精,大家如果有空,一定要细细品味这15个习惯。

    注意:每一个好的习惯,开头都会相应有一个唱反调的句子哦。

    31 告知,不要询问

    “不要相信其他的对象。从别人那里去拿你需要的信息,然后自己处理,自己决策。不要放弃控制别人的机会”。

    告知=命令,询问=查询
    命令和查询相分离模式,就是要将功能和方法分为命令和查询两类,并在源码中记录下来,以做到将命令代码都放在一起,并将所有查询代码都放在一起。
    绝对不能允许一个看起来无辜的“查询”去修改对象的状态。

    32 根据契约进行替换

    “深层次的集成是很棒的。如果你需要其他类的函数,直接继承它们就好了!”

    保持系统灵活性的关键方式,是当新代码取代原有代码之后,其他已有的代码不会意识到任何差别。
    如果你不确定一个接口做出了什么样的承诺,或者有什么样的需求,那就很难提供一个对其有意义的实现了。

    33 记录问题解决日志

    “在开发过程中是不是经常遇到似曾相识的问题?这没关系,以前解决过的问题,现在还是可以解决掉的。”

    面对问题是开发人员的一种生活方式。当问题发生时,我们会希望记起第一次是如何解决的,而且希望下次能够更快地把它搞定。但是,有时我们又记不清上次是如何修复的了。
    不要在同一处跌倒两次。
    要想得到更好的效果,不妨维护一个保存曾遇到的问题以及对应解决方案的日志,我们称之为每日日志(daylog)。
    可以选择符合需求的任何格式,下面的内容可能用得上:

    • 问题发生日期
    • 问题简述
    • 解决方案详细描述
    • 引用文章或网址,以提供更多细节或相关信息

    任何代码片段、设置或对话框的截屏,只要它们是解决方案的一部分,或者可以帮助更深入地理解相关细节。
    务必要将上述信息变为计算机可搜索的格式。

    34 警告就是错误

    “编译器的警告信息只不过是给过分小心和过于书呆子气的人看的。它们只是警告而已。”

    有些警告是过于挑剔的编译器的良性副产品,但有些则不是。例如,一个关于未被使用的变量的警告,可能不会产生什么恶劣影响,但却有可能是暗示某些变量被错误使用了。
    签入带有警告的代码,就跟签入有错误或者没有通过测试的代码一样,都是极差的做法。

    35 对问题各个击破

    “要调试一个明显的错误,只要去查看整个系统的代码,而且是要全部过一遍。毕竟你不知道问题可能发生在什么地方,这样做是找到它的唯一方式。”

    单元测试带来的积极效应是它会强迫形成代码的分层。要保证代码可测试,就必须把它从周边代码中解脱出来。
    认识复杂问题的第一步,是将它们分离出来。
    很多应用的代码在编写时没有注意到这一点,使得分离变得特别困难。应用的各个构件部分之间会彼此纠结:想把这个部分单独拿出来,其他的会紧随而至。在这些状况下,最好花一些时间把关注的代码提取出来,而且创建一个可让其工作的测试环境。

    36 报告所有的异常

    “不要让程序的调试者看到那些奇怪的异常。处理它们是你的责任。把你调用的一切都包起来,然后发送自己定义的异常。”

    作者曾经使用一个非常流行的开源程序库时倍受打击。作者调用的一个方法本来应该创建一个对象,可得到的却是null,调查很久都没有头绪。幸好这个库是开源的,所以他下载了源代码,并找到了出问题的那个调用方法。那个方法认为她的系统中缺少了某些必要的组件。这个底层方法抛出了带有相关信息的异常。但是,上层方法却偷偷地用没有异常处理代码的空catch代码块,把异常给忽略掉了,然后抛出了一个null。后来,作者安装了相应的组件,问题解决了。

    37 提供有用的错误信息

    “不要吓着用户,吓程序员也不行,要提供给他们干净整洁的错误信息。”

    在设计一个登陆页面时,当用户输错密码时,我们提示哪个信息更好呢:“Unable to perform operation”、“Couldn’t login…”、还是“Error validating password”
    错误信息有助于问题的解决。当问题发生时,可以详细研究问题的细节描述和发生上下文。

    38 定期安排会面时间

    “会议安排得越多越好。实际上,我们要安排更多的会议。”

    立会 (站着开的会议,Scrum最早引入并被极限编程所强调的一个实践)是将团队召集在一起,并让每个人了解当下进展状况的好办法。顾名思义,参与者们不允许在立会中就坐,这可以保证会议快速进行。一个人坐下来之后,会由于感到舒适而让会议持续更长的时间。
    要保证立会议题不发散,每个人只能回答下述三个问题:

    • 昨天的收获是什么
    • 今天计划要做哪些工作
    • 面临着哪些障碍

    大家都期盼着立会,希望彼此了解各自的进度和手上的工作,而且不怕把各自遇到的问题拿出来公开讨论。

    39 架构师必须写代码

    “我们的专家级架构师会提供设计好的架构,供你编写代码。他经验丰富,拿的薪水很高,所以不要用一些愚蠢的问题或者实现上的难点来浪费他的时间。”

    这些架构师通常在项目开始时介入,绘制各种各样的设计图,然后在重要的代码实现开始之前离开。有太多这种“Powerpoint架构师”。由于得不到反馈,而且设计会随着时间而演进,所以他们的架构设计工作也不会有很好的收效。
    新系统的设计者必须要亲自投入到实现中去。

    40 实行代码集体所有制

    “不用担心那些烦人的bug,Joe下周假期结束回来后会把它解决掉的。在此之前先想个权宜之计应付一下吧。”

    不应像国家宣称对领土的所有权一样,声明个人对代码的所有权。任何一位团队成员,重要理解某段代码的来龙去脉,就应该可以对其进行处理。如果某一段代码只有一位开发人员能够处理,项目的风险无形中也就增加了。
    相比找出谁的主意最好、谁的代码实现最烂而言,解决问题,并让应用满足用户的期望更为重要。
    在大型项目中,如果每个人都可以随意改变任何代码,一定会把项目弄得一团糟。代码集体所有制并不意味着可以随心所欲、到处破坏。

    41 成为指导者

    “你花费了大量的时间和精力,才达到目前的水平。对别人要有所保留,这样让你看起来更有水平。让队友对你超群的技能感到恐惧吧。”

    教学相长。通过详细解释自己知道的东西,可以使自己的理解更深入。当别人提出问题时,也可以发现不同的角度。
    成为指导者,意味着要分享,而不是固守自己的经验、知识和体会。

    42 允许大家自己想办法

    “你这么聪明,直接把干净利落的解决方案告诉团队其他人就好了。不要浪费时间告诉他们为什么这么做。”

    作为指导者,应该鼓励、引领大家思考如何解决问题。
    用问题来回答问题,可以引导提问的人走上正确的道路 。

    43 准备好后再共享代码

    “别管是不是达到代码签入的要求,要尽可能频繁的提交代码,特别是要下班的时候。”

    向代码库中提交仍在开发的代码,会带来很多风险。当其他开发者获取最新版本的代码时,也会受到这些代码的影响。
    绝不要提交尚未完成的代码。故意签入编译未通过或是没有通过单元测试的代码,对项目来说,应被视作玩忽职守的犯罪行为。

    44 做代码复查

    “用户是最好的测试人员。别担心–如果哪里出错了,他们会告诉你们的。”

    代码刚刚完成时,是寻找问题的最佳时机。如果放任不管,它也不会变得更好。
    管理层担心进行代码复查所耗费的时间。他们不希望团队停止编码,而去参加长时间的代码复查会议。开发人员对代码复查也感到担心,允许别人看他们的代码,会让他们有受威胁的感觉。这影响了他们的自尊心。
    要寻找深藏不露的代码bug,正式地进行代码检查,其效果是任何已知形式测试的两倍,而且是移除80%缺陷的唯一已知方法。
    在极限编程中,不存在一个人独立进行编码的情况。编程总是成对进行的 :一个人在键盘旁边(担任司机的角色),另一个人坐在后面担任导航员。他们会不时变换角色。有第二双眼睛在旁边盯着,就像是在进行持续的代码复查活动,也就不必安排单独的特定复查时间了。
    你也可以考虑使用诸如Similarity Analyzer或Jester这样的代码分析工具。
    不进行思考、类似于橡皮图章一样的代码复查没有任何价值。

    45 及时通报进展和问题

    “管理层、项目团队以及业务所有方,都仰仗你来完成任务。如果他们想知道进展状况,会主动找你要的。还是埋头继续做事吧。”

    如果等到截止时间才发布坏消息,那么经理或技术主管就会担心你再次让他们失望,并开始每天多次检查你的工作进度。
    及时通报进展和问题,有情况发生时,就不会让别人感到突然,而且他们也很愿意了解目前的进展和状况。他们会知道何时应提供帮助,而且你也获得了他们的信任 。

    结束语

    《高效程序员的45个习惯》,

    每一个习惯都值得程序员同学去仔细体会和吸收。

    文章转载自:http://roclinux.cn/

  • 相关阅读:
    Smart Client Architecture and Design Guide
    Duwamish密码分析篇, Part 3
    庆贺发文100篇
    .Net Distributed Application Design Guide
    New Introduction to ASP.NET 2.0 Web Parts Framework
    SPS toplevel Site Collection Administrators and Owners
    来自Ingo Rammer先生的Email关于《Advanced .Net Remoting》
    The newsletter published by Ingo Rammer
    深度探索.Net Remoting基础架构
    信道、接收器、接收链和信道接受提供程序
  • 原文地址:https://www.cnblogs.com/ACshasow/p/3261868.html
Copyright © 2011-2022 走看看