84 lines
3.5 KiB
YAML
84 lines
3.5 KiB
YAML
uuid:
|
|
- value: 681c802d-45a6-409e-8dd1-3499184f7616
|
|
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:00+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: 'Smaller modules are more reusable'
|
|
created:
|
|
- value: '2025-02-27T00:00:00+00:00'
|
|
changed:
|
|
- value: '2025-05-11T09:00:00+00:00'
|
|
promote:
|
|
- value: false
|
|
sticky:
|
|
- value: false
|
|
default_langcode:
|
|
- value: true
|
|
revision_translation_affected:
|
|
- value: true
|
|
path:
|
|
- alias: /daily/2025/02/27/reusability
|
|
langcode: en
|
|
body:
|
|
- value: |
|
|
<p>When you're writing open source code, such as a PHP library or a Drupal module, the larger it is, the harder it can be to reuse.</p>
|
|
|
|
<p>Each implementation will have its own requirements and specifics, so why have code that tries to do everything?</p>
|
|
|
|
<p>The smaller the code, the more reusable it is.</p>
|
|
|
|
<p>The most reusable code I've written have been in smaller modules, like the <a href="https://www.drupal.org/project/system_user">System User</a> and <a href="https://www.drupal.org/project/null_user">Null User</a> Drupal modules.</p>
|
|
|
|
<p>Both are very small and solve a specific problem.</p>
|
|
|
|
<p>The Null User module is used by the System User module to provide a default if no system user is defined.</p>
|
|
|
|
<p>It could have been part of the System User module, but extracting it into a separate module makes it more reusable.</p>
|
|
|
|
<p>It also makes System User leaner, less bloated and more focused on its use case and its own functionality.</p>
|
|
|
|
<p>This approach is based on the UNIX philosophy of a program doing one thing well, and chaining programs together when needed to solve a larger problem.</p>
|
|
|
|
<p>Then, if you need, you can extend the code in a custom module or add features <a href="/daily/2025/02/24/patch">by applying patches</a>.</p>
|
|
|
|
|
|
format: full_html
|
|
processed: |
|
|
<p>When you're writing open source code, such as a PHP library or a Drupal module, the larger it is, the harder it can be to reuse.</p>
|
|
|
|
<p>Each implementation will have its own requirements and specifics, so why have code that tries to do everything?</p>
|
|
|
|
<p>The smaller the code, the more reusable it is.</p>
|
|
|
|
<p>The most reusable code I've written have been in smaller modules, like the <a href="https://www.drupal.org/project/system_user">System User</a> and <a href="https://www.drupal.org/project/null_user">Null User</a> Drupal modules.</p>
|
|
|
|
<p>Both are very small and solve a specific problem.</p>
|
|
|
|
<p>The Null User module is used by the System User module to provide a default if no system user is defined.</p>
|
|
|
|
<p>It could have been part of the System User module, but extracting it into a separate module makes it more reusable.</p>
|
|
|
|
<p>It also makes System User leaner, less bloated and more focused on its use case and its own functionality.</p>
|
|
|
|
<p>This approach is based on the UNIX philosophy of a program doing one thing well, and chaining programs together when needed to solve a larger problem.</p>
|
|
|
|
<p>Then, if you need, you can extend the code in a custom module or add features <a href="http://default/daily/2025/02/24/patch">by applying patches</a>.</p>
|
|
|
|
|
|
summary: null
|
|
field_daily_email_cta: { }
|