uuid:
  - value: 7f8987ed-6ec1-4d81-a968-ec918f017b4b
langcode:
  - value: en
type:
  - target_id: daily_email
    target_type: node_type
    target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
revision_timestamp:
  - value: '2025-06-15T08:11:24+00:00'
revision_uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
revision_log: {  }
status:
  - value: true
uid:
  - target_type: user
    target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849
title:
  - value: 'Refactorings should be small'
created:
  - value: '2025-06-13T08:01:48+00:00'
changed:
  - value: '2025-06-15T08:11:24+00:00'
promote:
  - value: false
sticky:
  - value: false
default_langcode:
  - value: true
revision_translation_affected:
  - value: true
path:
  - alias: /daily/2025/06/13/refactorings-should-be-small
    langcode: en
body:
  - value: |-
      When refactoring code, try and make each change as small as possible.

      Just renaming a variable to something easier to understand is a valid refactor.

      So is extracting a small method or moving logic to another class.

      I recently make [some refactoring commits](https://code.oliverdavies.uk/opdavies/oliverdavies.uk/commits/branch/main/search?q=Refactor) to my website and, rather than squashing them, I pushed them to show how simple refactoring can be.

      It's easier to see and review each refactor separately in its own commit instead of in one large squashed commit.

      It's also easier to keep the code in a working state if the refactors are smaller.

      If you break the code whilst refactoring, get back to a working state as soon as possible - even if it means resetting back to the last working commit.

      Don't keep making changes - it will be harder to get back to a working state.
    format: markdown
    processed: |
      <p>When refactoring code, try and make each change as small as possible.</p>
      <p>Just renaming a variable to something easier to understand is a valid refactor.</p>
      <p>So is extracting a small method or moving logic to another class.</p>
      <p>I recently make <a href="https://code.oliverdavies.uk/opdavies/oliverdavies.uk/commits/branch/main/search?q=Refactor">some refactoring commits</a> to my website and, rather than squashing them, I pushed them to show how simple refactoring can be.</p>
      <p>It's easier to see and review each refactor separately in its own commit instead of in one large squashed commit.</p>
      <p>It's also easier to keep the code in a working state if the refactors are smaller.</p>
      <p>If you break the code whilst refactoring, get back to a working state as soon as possible - even if it means resetting back to the last working commit.</p>
      <p>Don't keep making changes - it will be harder to get back to a working state.</p>
    summary: ''
field_daily_email_cta:
  - target_type: node
    target_uuid: 3074e1e9-c691-4f73-a71c-cfe5920f884e