Julio Biason
1 year ago
1 changed files with 77 additions and 0 deletions
@ -0,0 +1,77 @@
|
||||
+++ |
||||
title = "Everything Everywhere At Once In Software Development" |
||||
date = 2023-06-30 |
||||
draft = true |
||||
|
||||
[taxonomies] |
||||
tags = ["software development"] |
||||
+++ |
||||
|
||||
A lot of stuff we learn (and some things we don't learn, specially at Uni) is |
||||
told in a vaccuum, in which only it exists. But there is a lot of things that |
||||
are connected (or, at least, they should). |
||||
|
||||
<!-- more --> |
||||
|
||||
Let's start with... |
||||
|
||||
## TDD |
||||
|
||||
Test-Driven Development, or just TDD for short, is the idea of building the |
||||
tests before you build the code. Sure, that means the test fails, then you add |
||||
the code, and the test finally passes. This flow is described as |
||||
"red-refactor-green" in the TDD lingo. |
||||
|
||||
But what you need to test? Well, if you follow the language used in TDD, you |
||||
write the test **and then** refactor. This means you need to find out what the |
||||
code needs to do, write a test that replicates the behavior you want and then |
||||
write the code. |
||||
|
||||
{% note() %} |
||||
**The internet hates me**: One general description of TDD you may find in the |
||||
internet is that you should write a test for every function/class in your |
||||
project. I've told those that you shouldn't make it an one-to-one when writing |
||||
tests like this, and I've been laughed at for that. |
||||
|
||||
Just a warning that you may find other explanations for what TDD is and it |
||||
won't say exactly like that. |
||||
{% end %} |
||||
|
||||
But where those behaviors come from? That's when we have to talk about... |
||||
|
||||
## Agile |
||||
|
||||
Agile is a set of project management methodologies in which you start with |
||||
small pieces, deliver them, and then gather more information. This process |
||||
assures that you're moving in the right way, letting the ideas settle instead |
||||
of having just concepts and hoping they are right the project reaches its end |
||||
and it is delivered. |
||||
|
||||
{% note() %} |
||||
**The internet hates me**: If you look for agile on the internet, you may find |
||||
a series of posts saying that "agile sucks" or something like that. So far, all |
||||
the things I've read seem to follow the agile book line-by-line instead of |
||||
understanding *why* things are that way. |
||||
|
||||
Also, the behavior descriptions can come from other project management |
||||
methologies, like Cascade, in which you have the whole project specified and |
||||
described way before any piece of code is written -- which have its own issues. |
||||
{% end %} |
||||
|
||||
Besides gathering information at each step, there is a discussion about the |
||||
"Definition Of Done", on when a feature is complted: Is it when the developer |
||||
finishes writing the code? Is it when the testers say it is ok? Or is it when |
||||
the client says it fits their needs, 'cause the issue could be the information |
||||
gathering way before it reached the developer? |
||||
|
||||
The point of "was it right before reaching the developer" have a definition |
||||
that is mostly forgotten: It should pass the "Definition Of Ready", which, as |
||||
with Definition of Done, tries to describe when something is good to be |
||||
developed, like "Do we have the proper definition?", "Does it have an example |
||||
of what is the expected behavior?", "Do we have the error |
||||
conditions/constrains?" and so on. |
||||
|
||||
If a task passes the "Definition of Ready", then the developer have the |
||||
expected behavior from the system, which brings us back to... |
||||
|
||||
## TDD |
Loading…
Reference in new issue