72 lines
2.9 KiB
YAML
72 lines
2.9 KiB
YAML
uuid:
|
|
- value: 4aec9154-e02d-48cd-84e3-26de40c4d4f3
|
|
langcode:
|
|
- value: en
|
|
type:
|
|
- target_id: daily_email
|
|
target_type: node_type
|
|
target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7
|
|
revision_timestamp:
|
|
- value: '2025-05-11T09:00:01+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: 'Good software is easy to change'
|
|
created:
|
|
- value: '2025-02-04T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:01+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/02/04/changeable
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>As well as being easy to test, good software is easy to change.</p>
|
|
|
|
<p>If requirements change or a bug is found, it should be easy to change the code.</p>
|
|
|
|
<p>Simple code is easier to read and fix, and code split into smaller functions and classes - particularly when using design patterns - make it easier to change the existing code or its behaviour by writing new code.</p>
|
|
|
|
<p>For example, if you need to change your payment gateway provider, ideally your software has been written so that each payment gateway has its own implementation and then can be swapped without needing to change the original code.</p>
|
|
|
|
<p>If you need to change the behaviour of a class, you could use a Decorator to wrap and extend it.</p>
|
|
|
|
<p>Having tests also makes the code easier to change as you can validate and verify the behaviour before and after the change.</p>
|
|
|
|
<p>Changing code that doesn't have tests is risky, so if there aren't any, write some before changing the code.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>As well as being easy to test, good software is easy to change.</p>
|
|
|
|
<p>If requirements change or a bug is found, it should be easy to change the code.</p>
|
|
|
|
<p>Simple code is easier to read and fix, and code split into smaller functions and classes - particularly when using design patterns - make it easier to change the existing code or its behaviour by writing new code.</p>
|
|
|
|
<p>For example, if you need to change your payment gateway provider, ideally your software has been written so that each payment gateway has its own implementation and then can be swapped without needing to change the original code.</p>
|
|
|
|
<p>If you need to change the behaviour of a class, you could use a Decorator to wrap and extend it.</p>
|
|
|
|
<p>Having tests also makes the code easier to change as you can validate and verify the behaviour before and after the change.</p>
|
|
|
|
<p>Changing code that doesn't have tests is risky, so if there aren't any, write some before changing the code.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|