91 lines
No EOL
3.7 KiB
JSON
91 lines
No EOL
3.7 KiB
JSON
{
|
|
"uuid": [
|
|
{
|
|
"value": "8e31643d-a697-4068-8692-cdc472b96e90"
|
|
}
|
|
],
|
|
"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:07+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": "Find bugs sooner"
|
|
}
|
|
],
|
|
"created": [
|
|
{
|
|
"value": "2024-09-07T00:00:00+00:00"
|
|
}
|
|
],
|
|
"changed": [
|
|
{
|
|
"value": "2025-05-11T09:00:07+00:00"
|
|
}
|
|
],
|
|
"promote": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"sticky": [
|
|
{
|
|
"value": false
|
|
}
|
|
],
|
|
"default_langcode": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"revision_translation_affected": [
|
|
{
|
|
"value": true
|
|
}
|
|
],
|
|
"path": [
|
|
{
|
|
"alias": "\/daily\/2024\/09\/07\/find-bugs-sooner",
|
|
"langcode": "en"
|
|
}
|
|
],
|
|
"body": [
|
|
{
|
|
"value": "\n <p>Whilst speaking with Dave Liddament last week, I remembered a slide I've seen in some of his previous presentations, such as <a href=\"https:\/\/www.daveliddament.co.uk\/talks\/effective-code-review\">Effective Code Review<\/a>.<\/p>\n\n<p>On the slide is a graph that shows the amount of time needed to fix a bug at different stages of the development lifecycle.<\/p>\n\n<p>Fixing a bug is the quickest and simplest when writing code.<\/p>\n\n<p>It's harder when being code reviewed or QA or client tested, more so when it's being released, and the most difficult and expensive once it's in the maintenance phase.<\/p>\n\n<p>Once it's live in the production environment, there's additional cleanup work to do which adds to the time and cost, and potentially damages your reputation.<\/p>\n\n<p>The sooner you can find a bug, the better.<\/p>\n\n<p>This is where tools such as automated testing, static analysis and CI pipelines shine and make it easier for you to find and fix potential bugs sooner.<\/p>\n\n ",
|
|
"format": "full_html",
|
|
"processed": "\n <p>Whilst speaking with Dave Liddament last week, I remembered a slide I've seen in some of his previous presentations, such as <a href=\"https:\/\/www.daveliddament.co.uk\/talks\/effective-code-review\">Effective Code Review<\/a>.<\/p>\n\n<p>On the slide is a graph that shows the amount of time needed to fix a bug at different stages of the development lifecycle.<\/p>\n\n<p>Fixing a bug is the quickest and simplest when writing code.<\/p>\n\n<p>It's harder when being code reviewed or QA or client tested, more so when it's being released, and the most difficult and expensive once it's in the maintenance phase.<\/p>\n\n<p>Once it's live in the production environment, there's additional cleanup work to do which adds to the time and cost, and potentially damages your reputation.<\/p>\n\n<p>The sooner you can find a bug, the better.<\/p>\n\n<p>This is where tools such as automated testing, static analysis and CI pipelines shine and make it easier for you to find and fix potential bugs sooner.<\/p>\n\n ",
|
|
"summary": null
|
|
}
|
|
]
|
|
} |