精华内容
下载资源
问答
  • 1、任何函数只能做一件事这是迄今为止软件...2、函数名应该描述他们所做的事情3、删除重复的代码尽你最大的努力来避免重复的代码。重复代码不好,因为它意味着如果你修改一些逻辑,那就有不止一处地方要同步修改了。...

    1、任何函数只能做一件事

    这是迄今为止软件工程里最重要的一个规则。当函数做超过一件事的时候,他们就难于实现、测试和理解。当你隔离函数只剩一个功能时,他们就容易被重构,然后你的代码读起来就更清晰。如果你光遵循这条规则,你就领先于大多数开发者了。


    2、函数名应该描述他们所做的事情


    3、删除重复的代码

    尽你最大的努力来避免重复的代码。重复代码不好,因为它意味着如果你修改一些逻辑,那就有不止一处地方要同步修改了。

    经常你容忍重复代码,因为你有两个或更多有共同部分但是少许差异的东西强制你用两个或更多独立的函数来做相同的事。移除重复代码意味着创造一个处理这组不同事物的一个抽象,只需要一个函数/模块/类。

    抽象正确非常重要,这也是为什么你应当遵循SOLID原则(奠定Class基础的原则)。坏的抽象可能比重复代码还要糟,因为要小心。在这个前提下,如果你可以抽象好,那就开始做把!不要重复你自己,否则任何你想改变一件事的时候你都发现在即在更新维护多处。


    4、不要用标志作为函数的参数,标志告诉你的用户函数做很多事了。函数应当只做一件事。 根据布尔值区别的路径来拆分你的复杂函数。

    5、避免副作用

    如果一个函数不是获取一个输入的值并返回其它值,它就有可能产生副作用。这些副作用可能是写入文件、修改一些全局变量,或者意外地把你所有钱转给一个陌生人。

    现在你确实需要在程序中有副作用。像前面提到的那样,你可能需要写入文件。现在你需要做的事情是搞清楚在哪里集中完成这件事情。不要使用几个函数或类来完成写入某个特定文件的工作。采用一个,就一个服务来完成。

    关键点是避免觉的陷阱,比如在没有结构的对象间共享状态,使用可以被任意修改的易变的数据类型,没有集中处理发生的副作用等。如果你能做到,你就能比其他大多数程序员

    更愉快。

    比如:错误的代码

    $name = 'Ryan McDermott';
    
    function splitIntoFirstAndLastName() 
    
    {  $name = preg_split('/ /', $name);}
    
    splitIntoFirstAndLastName();
    
    var_dump($name); // ['Ryan', 'McDermott'];

    正确的代码

    function splitIntoFirstAndLastName($name) 
    
    {  return preg_split('/ /', $name);}
    
    $name = 'Ryan McDermott';
    
    $newName = splitIntoFirstAndLastName(name);

    6、不要写全局变量

    在大多数语言中污染全局变量是一个坏的实践,因为你可能和其他类库冲突并且你api的用户不明白为什么直到他们获得产品的一个异常。让我们看一个例子:如果你想配置一个数组,你可能会写一个全局函数像config(),但是可能和试着做同样事的其他类库冲突。这就是为什么单例设计模式和简单配置会更好的原因


    比如:不好的程序

    function config() {
      return  [
        'foo': 'bar',
      ]
    };

    好的程序

    class Configuration {
      private static $instance;
      private function __construct($configuration) {/* */}
      public static function getInstance() {
         if(self::$instance === null) {
             self::$instance = new Configuration();
         }
         return self::$instance;
     }
     public function get($key) {/* */}
     public function getAll() {/* */}
    }
    
    $singleton = Configuration::getInstance();


    7、封装条件语句

    例如:不好的程序

    if ($fsm->state === 'fetching' && is_empty($listNode)) {
      // ...
    }

    好的程序

    function shouldShowSpinner($fsm, $listNode) {
      return $fsm->state === 'fetching' && is_empty(listNode);
    }
    
    if (shouldShowSpinner($fsmInstance, $listNodeInstance)) {
      // ...
    }


    8、避免消极条件

    不好的程序

    function isDOMNodeNotPresent($node) {
      // ...
    }
    
    if (!isDOMNodeNotPresent($node)) {
      // ...
    }

    好的程序

    function isDOMNodePresent($node) {
      // ...
    }
    
    if (isDOMNodePresent($node)) {
      // ...
    }

    9、避免条件声明

    这看起来像一个不可能任务。当人们第一次听到这句话是都会这么说。 "没有一个if声明" 答案是你可以使用多态来达到许多case语句里的任务。第二个问题很常见, “那么为什么我要那么做?” 答案是前面我们学过的一个整洁代码原则:一个函数应当只做一件事。当你有类和函数有很多if声明,你自己知道你的函数做了不止一件事。记住,只做一件事。

    坏的程序:
    class Airplane {
      // ...
      public function getCruisingAltitude() {
        switch (this.type) {
          case '777':
            return $this->getMaxAltitude() - $this->getPassengerCount();
          case 'Air Force One':
            return $this->getMaxAltitude();
          case 'Cessna':
            return $this->getMaxAltitude() - $this->getFuelExpenditure();
        }
      }
    }

    好的程序

    class Airplane {
      // ...
    }
    
    class Boeing777 extends Airplane {
      // ...
      public function getCruisingAltitude() {
        return $this->getMaxAltitude() - $this->getPassengerCount();
      }
    }
    
    class AirForceOne extends Airplane {
      // ...
      public function getCruisingAltitude() {
        return $this->getMaxAltitude();
      }
    }
    
    class Cessna extends Airplane {
      // ...
      public function getCruisingAltitude() {
        return $this->getMaxAltitude() - $this->getFuelExpenditure();
      }
    }

    10、避免类型检查

    PHP是弱类型的,这意味着你的函数可以接收任何类型的参数。 有时候你为这自由所痛苦并且在你的函数渐渐尝试类型检查。有很多方法去避免这么做。第一种是考虑API的一致性。

    坏的程序

    function travelToTexas($vehicle) {
      if ($vehicle instanceof Bicycle) {
        $vehicle->peddle($this->currentLocation, new Location('texas'));
      } else if ($vehicle instanceof Car) {
        $vehicle->drive($this->currentLocation, new Location('texas'));
      }
    }

    好的程序

    function travelToTexas($vehicle) {
      $vehicle->move($this->currentLocation, new Location('texas'));
    }
    

    11、避免类型检查

    如果你正使用基本原始值比如字符串、整形和数组,你不能用多态,你仍然感觉需要类型检测,你应当考虑类型声明或者严格模式。 这给你了基于标准PHP语法的静态类型。 手动检查类型的问题是做好了需要好多的废话,好像为了安全就可以不顾损失可读性。保持你的PHP 整洁,写好测试,做好代码回顾。做不到就用PHP严格类型声明和严格模式来确保安全。


    坏的程序:

    function combine($val1, $val2) {
      if (is_numeric($val1) && is_numeric(val2)) {
        return val1 + val2;
      }
    
      throw new \Exception('Must be of type Number');
    }

    好的程序

    function combine(int $val1, int $val2) {
      return $val1 + $val2;
    }

    12、移除僵尸代码

    僵尸代码和重复代码一样坏。没有理由保留在你的代码库中。如果从来被调用过,见鬼去!在你的版本库里是如果你仍然需要他的话,因此这么做很安全。

    13、使用有意义可拼写的变量名

    坏的程序

    $ymdstr = $moment->format('y-m-d');

    好的程序

    $currentDate = $moment->format('y-m-d');

    14、同种类型的变量,使用相同的词汇

    坏的程序

    getUserInfo();
    getClientData();
    getCustomerRecord();

    好的程序

    getUser();

    15、使用易检索的名称

    我们会读比写要多的代码。通过是命名易搜索,让我们写出可读性和易搜索代码很重要。

    16、使用解释型变量

    17、避免心理映射

    明确比隐性好。


    18、不要添加不必要上下文

    如果你的class/object 名能告诉你什么,不要把它重复在你变量名里。

    19、使用参数默认值代替短路或条件语句。

    坏的程序

    function createMicrobrewery($name = null) {
      $breweryName = $name ?: 'Hipster Brew Co.';
      // ...
    }

    好的程序

    function createMicrobrewery($breweryName = 'Hipster Brew Co.') {
      // ...
    }

    20、函数参数最好少于2个

    限制函数参数个数极其重要因为它是你函数测试容易点。有超过3个可选参数参数导致一个爆炸式组合增长,你会有成吨独立参数情形要测试。

    无参数是理想情况。1个或2个都可以,最好避免3个。再多旧需要加固了。通常如果你的函数有超过两个参数,说明他多做了一些事。 在参数少的情况里,大多数时候一个高级别对象(数组)作为参数就足够应付。







    展开全文
  • 代码整洁之道

    2020-10-23 10:18:32
    代码整洁之道有感

    最近读了代码整洁之道这本书,还是挺有感触的。。。

    有意义的命名

    • 命名的时候应该已经答复了所有的大问题,正确的命名应该让看代码的人知道,为什么存在,做什么事情,应该怎么用。
    • 好的命名是不需要注释来进行补充的。 写代码的人应该避免留下掩藏代码本意的错误的信息,不应该使用和本意相违背的词语。
      在同一作用范围内命名的时候要做出有意义的区分,不可进行随意的区分。
    • 要使用读得出来的词语进行命名,否则在进行解释命名的时候就会显得异常的愚蠢。
    • 要使用可搜索到的词语进行命名,名称的长短应该与其作用域的大小相对应。 不要使用自己的固定思维去进行命名,要进行慎重的选择。
    • class 的命名应该是名词或者名词短语,不应该是动词。 方法名应该是动词或者动词短语。 别用你自己所认为的幽默来进行命名,懂得你幽默的人其实并不多。
      同一个团队中要约定好每个概念对应的是哪个词,这样就不会产生歧义,不会造成代码的混乱。
    • 命名的时候要避免将同一个单词用于不同的目的,这样的双关语容易造成语义不对,要找到能够区分的词语重新命名。
    • 可以使用计算机科学术语、算法名、模式名、数学术语进行命名,只有程序员才会看你的代码,所以他们是能够读懂的。
    • 要添加有意义的语境来进行命名,这样比单独的一个单词更有说服力,在某些特定的情境下,合适的前缀可以让读者明白这是结构中的哪一个部分。
    • 别害怕重新命名的工作,名称变得更好之后,代码也就向着整洁代码更近一步。

    函数

    • 函数应该是短小的,函数不应该大到足以容纳嵌套结构,函数的缩进层级不应该多于一层或者两层,这样的函数才是利于阅读和理解的。
    • 函数只应该做一件事,把一件事做好,而且只由这个函数来做这一件事。
    • 函数中不要混杂不同的抽象层级,不同的抽象层级步骤应该封装在不同的函数里面,每个函数的后面都应该跟着位于下一抽象层级的函数。
    • 利用多态来代替 switch 语句。
    • 要使用描述性的名称来给函数命名,别害怕长名称,长而具有描述性的名称,要比短而令人费解的名称好。
      函数最理想的状态是没有参数,然后是一和二,应尽量避免超过三个参数,除非有足够特殊的理由。
    • 应该避免将参数作为输出,这样会造成阅读上的困惑,还会导致函数的副作用,函数的副作用就是函数会偷偷的做了预料之外的事情。
      函数应该修改某对象的状态或者返回该对象的有关信息,两者都干的时候会导致混乱。
    • 使用异常代替返回错误码,错误处理本身就是一件事,而函数只应该做好一件事情,若 try 出现在函数中,它就应该是函数中的第一个单词。
    • 不要重复自己的代码。
    • 函数中只该有一个 return 语句,循环中不能有 break 和 continue 语句,不能有任何的 goto 语句。
    • 一开始写不出最佳的函数很正常,重要的是好的代码需要不断的打磨,分解函数、修改名称、消除重复,第一遍就能写出最佳代码的人大概是不存在的。
    • 好的程序员是把系统当做故事来讲的,而不是当做程序来写;当你编写的函数可以干净利落的拼装到一起,形成了一种精确而清晰的语言的时候,它就可以帮助你更好的讲诉你的故事了。

    • 类应该从一组变量列表开始,如果有公共静态常量,应该先出现,然后是私有静态变量,以及私有实体变量,很少会有公共变量;公共函数应该跟在变量列表的后面,把某个公共函数调用的私有工具函数紧随在改公共函数后面。
    • 类应该是短小的,系统应该由许多短小的类而不是少量巨大的类组成,每个小类封装一个权责,只有一个修改的原因,并与少数其他类一起协同达成期望的系统行为。
    • 类应该只有少量实体变量,类中的每个方法都应该操作一个或者多个这种变量,方法操作的变量越多,就越黏聚到类上。
    • 将大函数拆分为许多小函数,往往也是将类拆分为多个小类的时机,程序会更加的有组织,也会拥有更加透明的结构。
    • 整洁的类,可以让修改的代码的人更容易的看懂结构,在修改的时候也不会顾虑太多,某种意义上也是节约了在修改上时间的成本。
      部件之间的解耦代表着系统中的元素互相隔离的很好,隔离也让系统每个元素的理解变得更加容易。
    展开全文
  • 代码整洁之道 读后感

    2019-04-06 21:22:57
    看完这本书的感受是,这本书和标题的 “代码整洁之道” 没有什么关系。倒是与 A code of Conduct for Professional Programmers 这个副标题很贴切。 这本书开篇说到了一个面试必问的面试问题,来强调 ...

    代码整洁之道 读后感

    The Clean Coder —— A code of Conduct for Professional Programmers 读后感

    看完这本书的感受是,这本书和标题的 “代码整洁之道” 没有什么关系。倒是与 A code of Conduct for Professional Programmers 这个副标题很贴切。

    这本书开篇说到了一个面试必问的面试问题,来强调 专业开发人员的职业素养。
    在你过去的工作中,遭遇过哪些印象深刻的困难,最后是怎么解决的?
    为什么这个问题是面试必问的?
    书中强调:简历写的再漂亮的人,如果回答不好这个问题,大都可以直接忽略。因为我们需要招聘的不是“经验丰富”的人,而是“有职业素养”的人。我们看重的并不是问题的难易程度,而是解决问题的方式、步骤以及反思程度。

    那么如何成为专业人员,专业人员该怎么做?整本书主要阐述了专业软件开发者应该具备的素养和专业精神

    • 什么是软件专业人士?
    • 软件专业人士应该如何做事?
    • 工作中的时间管理
    • 软件专业人数如何和管理人员打交道?
    • 软件专业人士如何应对压力?

    1、什么是软件专业人士?

    • 对自己不完美的代码负责
    • 不要把QA当做啄木鸟
    • 遵循软件项目的根本原则:软件要易于修改
    • 职业发展:每天充电 3 小时
    • 坚持学习
    • 了解自己领域的相关技术
    • 了解自己的业务

    1.1、对自己不完美的代码负责

    没有人能写出完美的软件,但这并不代表不用对不完美的代码负责。专业人士就是对自己犯下的错误负责的人,哪怕一些错误实际上在所难免。

    如果不小心犯了一个错误,专业人员该怎么做呢?
    如果不小心放过了某个模块里的一个小bug,以致公司损失了1万元,专业人士需要为这一万元买单。

    专业人士的失误率应该越来越少,甚至趋近于零
    另外,职业发展多年后,专业人士的失误率应该越来越少,甚至趋近于零。失误率永远不可能等于零,但专业人士有责任让它无限接近零

    1.2、不把QA当做啄木鸟

    • 不要向测试发送有缺陷的代码。什么样的代码是有缺陷的呢?那些你没有把握的代码都是!
    • 提测前要确信代码可以正常运行。如何知道代码可以正常运行呢?一遍一遍的自测,翻来覆去、颠来倒去的测,使出浑身解数的自测

    1.3、软件要易于修改

    如何保证自己的软件结构易于修改?如果希望自己的软件灵活可变,那就应该时常修改它!

    • 不要为了加快项目进度、或者急于发布新功能,让代码结构变得糟糕。结构良好的代码更加灵活,易于修改。为赶工期,以牺牲结构为代价,得不偿失,将来必将追悔莫及。
    • 阅读某个模块代码时,如果发现某些代码没有预想的那样简单。那么你就应该做一些修改,改进设计,使后续修改变得简单
    • 有一种策略叫做 “无情重构” :对每个模块,每检入一次代码,就要让它比上次检出时变得更为简洁。每次读代码,都别忘了进行点击的改善。(我觉得,这种方式有些过了,我的境界遵循第一条就够了)

    最好的软件开发人员都知道一个秘密:美的东西比丑的东西创建起来更廉价,也更快捷。构建、维护一个美得软件系统所花费的时间、金钱都要少于丑的系统
    美的系统是灵活、易于理解的,构建、维护它们就是一种快乐。

    1.4 每天充电 3 小时

    职业发展是你自己的事。将自己的职业发展寄希望于雇主的软件开发人员将会很惨。

    • 雇主出了钱,你必须付出时间和经历。以一周工作40小时作为标准,这40小时应该用来解决雇主的问题,而不是你自己的问题。
    • 你应该每周工作60小时,前40小时给雇主,后20小时留给自己。这留给自己的20小时里,差不多每天 3 个小时,这 3 个小时,你应该看书、练习 或 做一些其他提升职业能力的事情

    1.5 坚持学习

    这一条和上一条貌似重复了,其实我只是想多提醒一下自己,坚持学习的重要性

    病人不会找已经不堪医学期刊的医生看病;发生纠纷时,人们不会聘用不了解最新律法和判例的律师。

    同样:不再写代码的架构师必然被时代淘汰;不学习新语言的程序员,只能眼睁睁看着行业一路向前发展,而自己被抛在后边

    1.6 了解自己领域的相关技术

    了解自己从事行业的 各种观点、实践、技术、工具与术语

    1.7 了解自己的业务

    很简单,不了解自己的业务,雇主发现后会很不满…

    2、专业人士应该如何做事?

    • 既然承诺了,那就必须兑现
    • 发现无法兑现承诺,那么最重要的就是尽早向你的承诺对象发出预警,越快越好,越早越好
    • 制造出很多bug的软件开发人员也会被人认为不专业
    • 软件开发是一场马拉松,需要维持稳定节奏来取胜
    • 被中断时,礼貌的表现出乐于助人的态度才是专业开发人员应具备的态度
    • 保持自己不落伍的一种方式是为开源项目贡献代码
    • 如果焦虑正在不断削弱工作效率,那么最好还是花上一个小时让他们先安静下来
    • 疲劳的时候,千万不要写代码

    2.1、既然承诺了,那就必须兑现

    承诺是必须做到的。如果你承诺在某天完成某件事情,就必须按时完成。即便它意味着你必须每天工作12小时,放弃周末的休假,也不得不如此。既然承诺了,那就必须兑现

    2.2、如果发现无法兑现承诺

    如果发现无法兑现承诺,那么最重要的就是尽早向你的承诺对象发出预警,越快越好,越早越好

    你越早向各利益相关方发出预警信号,整个团队就越有可能抓住机会,中止并重新评估当前的活动,并决定是否采取些措施或做出改变(比如调整优先级等)。这么一来,任然有可能达成之前的承诺,或者,用另一个承诺来代替先前的承诺。

    2.3、将Bug 降到最低

    医生不喜欢重新打开病人的胸腔去修复此前犯下的错误;律师不喜欢重新接手此前搞砸的案子。
    经常重新返工的医生或律师会被认为不专业。

    同样,制造出很多bug的软件开发人员也会被人认为不专业。

    衡量是不是一名专业人士的一个重要方面,便是看是否能将调试时间尽量降到最低。
    绝对的零调试时间是一个理想化的目标,无法达到,但要将之作为努力的方向。

    2.4、软件开发是一场马拉松,需要维持稳定节奏来取胜

    软件开发是一场马拉松,而不是短跑冲刺。你无法全程一直以最快的速度冲刺来赢得比赛,只是通过保存体力和维持稳定节奏来取胜。

    当碰到困难或者受到阻碍时,当你感到疲倦时,离开一会。。。

    2.5、被中断时 注意自己的态度

    中断无法避免,总有干扰会打断你、消耗你的时间。发生这种情况时要记住一点,也许下一次你会轮到你去打断别人,去请求别人的帮助。因此,礼貌的表现出乐于助人的态度才是专业开发人员应具备的态度

    2.6、向开源工程贡献代码

    保持自己不落伍的一种方式是为开源项目贡献代码,就像律师和医生参加公益活动一样。
    开源项目有很多,为其他人真正关心的开源项目做一点贡献,应该可以算是提升技能的最好方法了。

    2.7、焦虑时 不要写代码

    如果发现自己虽然人坐在办公室里,但内心的焦虑正在不断削弱工作效率,那么最好还是花上一个小时让他们先安静下来,这要好过硬逼着自己去写代码。这样憋出来的代码,以后也将不得不抛弃。

    2.8、疲劳的时候不要写代码

    疲劳的时候,千万不要写代码。奉献精神和职业素养,更多意义上是指的要遵循纪律原则而非成为长时间工作的工作狂。要确保自己已经将睡、健康和生活方式调整到最佳,这样才能做到每天的8小时工作内容全力以赴。

    2.9、如果你有看玄幻小说、言情小说的癖好 包容他们

    “创造性的输出” 依赖于 “创造性的输入”
    广泛阅读 天文、政治、历史、物理、化学、甚至科幻小说都有可能激发开发者的创造力。
    因此,如果你有看玄幻小说、言情小说的癖好,不要再试图压制他们,去包容他们
    也许这正是你舒缓疲劳神经、又创造力的一个良好来源。

    3、工作中的时间管理

    • 自动化测试金字塔
    • 站立会
    • 凡是不能在5分钟解决的争论,都不能靠辩论解决(最终还是要拿出数据)
    • 坑法则。如果你掉进了坑里,别挖
    • 程序泥潭:回头绝对是最简单的方法,如果继续前进,系统可能深陷泥潭,永无法翻身
    • 如果你用光了自己的注意力,必须花费一个小时或者更多的时间去来补充它
    • 锻炼身体,保持充沛精力

    3.1、自动化测试金字塔

    在这里插入图片描述

    3.2、站立会

    • 所有与会者必须站着
    • 到场的人依次回答:我昨天做了什么?今天打算做什么?遇见了什么问题?
    • 每个问题的时长不超过20秒,每个人的发言不超过一分钟;
      这样即使10个人开站立会,总时长也就10分钟

    3.3、争论

    凡是不能在5分钟解决的争论,都不能靠辩论解决(最终还是要拿出数据)

    如果争论必须解决,就应当要求争论各方在5分钟内向大家摆明问题,然后大家投票。这样整个会议也不要超过15分钟。

    如果你是表决失败的一方,拿出行动,认真实行与会决定

    3.4、走入了死胡同

    慎重的态度和积累的经验可以避免走入某些死胡同若无法避免的走入了死胡同,真正需要的是在走入死胡同时可以迅速意识到,并有足够的勇气走回头路

    这就是所谓的:坑法则。如果你掉进了坑里,别挖

    3.5、程序泥潭

    在泥潭中前进的危害是不易察觉的。

    • 面对简单问题,你给出解决方案,并且保持代码的简单、整洁;
    • 之后问题不断扩展,需求越来越复杂。你的代码也随之不断扩展,尽可能保持简洁;
    • 某一天之后,你突然发现,自己从一开始就做了某一项错误的选择,在需求不断变化的方向上,程序已跟不上节奏。

    这就是转折点 !

    这一刻回头修正设计,那还可以继续走下去。走回头路的代价很高,因为这要把已有代码推翻重来,但回头绝对是最简单的方法。如果继续前进,系统可能深陷泥潭,永无法翻身

    ###3.6、 如果你用光了自己的注意力,必须花费一个小时或者更多的时间去来补充它

    编程是需要持续投入精力和注意力的智力活动。
    注意力是稀缺资源,它类似魔力点数,如果你用光了自己的注意力点数,必须花费一个小时或者更多的时间去修复,来补充它

    • 好好睡一会儿
    • 楼下漫步半小时,或者与朋友聊会天
    • 翻翻杂志等

    3.7、锻炼身体,保持充沛精力

    定期跑跑步,不但可以提升心智注意力,还可以锻炼身体,保持充沛精力

    比如

    • 每周1、3、5 , 跑步半小时;做两组仰卧起坐,每组三十;做两组臂力锻炼的器材。大约1小时的时间。
    • 骑行1~2小时

    4、与管理人员打交道

    • 如何预估工期?预估工期的几种方式
    • 能就是能,不能就是不能,不要说“试试看”
    • 如果你的老板无法向你清楚的说明加班方案失败的后备预案,那么你就不该同意加班

    4.1、如何预估工期?

    • 使用三个考虑到多种因素的预估期限:乐观预估 标称预估 悲观预估 。尽量严守这三个时间点。
    • 规划扑克
      团队成员根据自己的预估选出一张牌,背面朝上,保证其他人看不到牌的点数。然后主持人依次让每个人亮牌。
    • 把大任务分成许多小任务,分开评估,再加总。
      这样做的好处是,小任务的评估误差较小,最终大任务评估的结果就较为精确。

    4.2 学会说“不”

    能就是能,不能就是不能,不要说“试试看”

    专业开发人员需要抵制一些不专业的需求(比如一些无关紧要但成本巨大的需求),抵制一些不专业行为(为赶工期而降低对程序质量的要求)

    我愿意尝试“浮空术”,愿意尝试“点金术”,或者愿意尝试横渡大西洋,但是你觉得可以成功吗?

    4.3、如果老板要求通过加班来完成某项紧急需求

    加班应满足以下三个条件,否则加班很大程度失败

    • 你个人能能挤出这些时间
    • 短期加班,最多加班两周
    • 你的老板有后备预案,以防万一加班失败

    所以 如果你的老板无法向你清楚的说明加班方案失败的后备预案,那么你就不该同意加班

    5、压力

    想象一下灵魂出窍后的体验:
    看到自己躺在一张手术台上,一位外科医生在做开胸手术。医生竭力挽救性命,但时间有限,此时,他的一举一动都与病人生死攸关。此时的自己,肯定希望医生可以沉着冷静,发挥出应有水平。
    同样,面对压力时,专业的开发人员更需要沉着泠静。

    规避会导致压力的处境,如果无法规避,则直面压力。

    如何应对压力?

    • 面对压力时,沉着泠静。
    • 对导致压力的问题深思熟虑,努力寻找可以带来最好结果的路径,然后沿着那条路径以合理稳定的节奏前进
    • 让你的团队和主管知道你正在深处困境中。告诉他们你所制定的走出困境的最佳计划,请求他们的支援与指引。
    展开全文
  • 欢迎阅读本栏目的读者,如果你想成为更加优秀的coder,请跟随笔者的观点去解析《代码整洁之道》这本书,相信你会收获颇丰。 软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关。这一点,无论是敏捷开发流派...

    概述

    欢迎阅读本栏目的读者,如果你想成为更加优秀的coder,请跟随笔者的观点去解析《代码整洁之道》这本书,相信你会收获颇丰。

    软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关。这一点,无论是敏捷开发流派还是传统开发流派,都不得不承认。
    本书提出一种观念:代码质量与其整洁度成正比。

    干净的代码,既在质量上较为可靠也为后期维护、升级奠定了良好基础。作为编程领域的佼佼者,本书作者给出了一系列行之有效的整洁代码操作实践。这些实践在本书中体现为一条条规则(或称“启示”),并辅以来自现实项目的正、反两面的范例。只要遵循这些规则,就能编写出干净的代码,从而有效提升代码质量

    我们都曾经瞟一眼自己亲手写下的混乱代码,决定弃之不顾,走向新一天。
    我们都曾经看到自己的烂程序居然能运行,然后断言能运行的烂程序总比什么都没有强。
    我们都曾经说过有朝一日再回头清理。

    当然,在那些日子里,我们都没听过勒布朗(LeBlanc)法则:稍后等于永不(Later equals never).

    什么是整洁代码?

    在这里插入图片描述
    出自《c++程序设计语言》作者说到:

    我喜欢优雅和高效的代码。代码逻辑应当直截了当,叫缺陷难以隐藏;尽量减少依赖关系,使之便于维护;依据某种分层战
    略完善错误处理代码;性能调至最优,省得引诱别人做没规矩的优化,搞出一堆混乱来。整洁的代码只做妤一件事

    读这种代码,就像见到手工精美的音乐盒或者设计精良的汽车一般,让你会心一笑。
    代码应该讲述事实,不引人猜测。它只包含必必需之物。读者应当感受到我们的果断绝色决绝。

    在这里插入图片描述
    OTI公司创始人,Eclipse 战略教父,Dave Thomas说到:

    整洁的代码应可由作者之外的开发者阅读和增补。它应
    通过所有单元测试和验收测试。它使用有意义的命名。它只提供一种非多种做一件事的途径。它只有尽量少的依赖关系、明确地定义和提供清晰、尽量少的AP,代码应通过其字面表达含义,因为不同的语言导致并非所有必需信息均可通过代码自身清晰表达。

    一言以蔽之:在意。这就是这本书的题旨所在。或许该加个副标题:如何在意代码

    简单代码规则:

    1. 能通过所有测试
    2. 没有重复代码
    3. 体现系统中的全部设计理念
    4. 包括尽量少的实体,比如类、方法、函数等

    开始走向整洁代码

    本栏目的后续将详细分点讲述如何写整洁的代码

    这里用前人概述:

    不要重复代码,只做一件事,表达力,小规模抽象。

    看起来很简单的几个点确包含了太多的编码细节。

    其实你会发现平时写代码的过程中,不管是别人的项目还是自己的项目,我们总是“读”的时间更多,“写”的时间反而很少,统计比例甚至超过10:1 。写新代码时,我们一直在读旧代码

    既然比例如此之高,我们就想让读的过程变得轻松,即便那会使得编写过程更难。没可能光写不读,所以使之易读实际也使之易写。

    这事概无例外。不读周边代码的话就没法写代码。编写代码的难度,取决于读周边代码的难度。要想干得快,要想早点做完,要想轻松写代码,先让代码易读吧!

    在这里插入图片描述

    展开全文
  • Java代码整洁之道

    千次阅读 2020-06-10 20:35:29
    Java代码整洁之道,介绍了什么是好代码,从命名规范、包整洁、类整洁、函数征集、异常征集、注释征集等几个方面介绍了怎么写好Java代码。
  • 代码整洁之道
  • 代码整洁之道 - 读感

    2017-08-11 10:51:56
    阅读《代码整洁之道》需要你做些什么呢?你将阅读代码——大量代码。《代码整洁之道》促使你思考代码中何谓正确,何谓错误。更重要的是,《代码整洁之道》将促使你重新评估自己的专业价值观,以及对自己技艺的承诺。...
  • 一直想深入看看《CleanCode 代码整洁之道》,增强代码整洁性。看到此文,略有启发,转载以敬。 作者:JobsandCzj 来源:CSDN 原文:https://blog.csdn.net/jobsandczj/article/details/81369970 版权声明:本文为...
  • 代码整洁之道(重构)

    2020-10-17 20:15:00
    主要介绍了代码整洁之道(重构),不管对于何种语言,重构都是软件开发过程中不可或缺的一部分,具有一定的参考价值,感兴趣的小伙伴们可以参考一下
  • 代码整洁之道》读书笔记

    万次阅读 多人点赞 2015-04-10 15:52:23
    代码整洁之道》是Bob大叔神一样的作品,这本书从引言到附录都无比精彩,书中的插图也非常好,代码是用Java语言书写的,程序员尤其是Java程序员赶紧去阅读吧!
  • 代码整洁之道》阅读分享

    千次阅读 多人点赞 2019-03-28 13:58:51
    代码整洁之道》是世界级软件开发大师Martin Folwer的著作,软件开发行业不朽的经典。养成保持代码整洁的好习惯,才能走得更远。
  • 什么要保持代码整洁? 高大上: 软件质量,不但依赖于架构及项目管理,而且与代码质量紧密相关;而代码质量与其整洁度成正比。 软件质量 <=> 代码质量 <=> 整洁度。 如果将软件比作一座宏大的建筑的...
  • 代码整洁之道 总结

    千次阅读 2019-05-19 17:31:15
    1.什么样的代码才是整洁的 从字面意思上理解,整洁的代码,对于程序员来说非常的一目了然,简单、整洁,结构清晰,逻辑清楚。代码其实是一种语言,传递的...首先便是要有保持代码整洁的意识,书中反复提到的提到的...
  • 代码整洁之道——读后感

    千次阅读 2019-03-13 22:43:46
    时隔三年,这是第二次阅读《代码整洁之道》,并以第三者的角度来看代码质量的问题,感慨良多。最主要的是我们要去写具有表达力、张力的代码;在修改时,每次签出都要比来时更整洁,千里之行始于足下。 写代码,...
  • C++ 代码整洁之道

    千次阅读 2021-03-11 13:00:10
    整洁的代码在团队中无疑是很受欢迎的,可以高效的被其它成员理解和维护,本文参考《C++代码整洁之道》和《Google C++编码规范》,结合自己的一些想法整理如下: C++本身作为面向对象语言,首先介绍下面向对象一般...
  • 代码整洁之道

    2018-03-01 12:01:04
    “相对于任何宏伟景愿,对细节的关注甚至是更为关键的专业性基础。首先,开发者通过小型实践获得可用于大型实践...相对于记住那些如何写出整洁代码的那些法则,养成保持代码整洁、提高代码质量的习惯和思维更为重要...
  • 代码整洁之道--读书笔记代码整洁之道这本书首先给出了代码整洁的重要性。同时在工作中,我们也深有体会,整洁的代码能够提高我们阅读代码和改动需求的效率。在这本书中也加深了我对整洁代码认识,我对整洁的代码的...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 8,859
精华内容 3,543
关键字:

代码整洁之道是什么语言