feat: draft be
parent
034f94daff
commit
1c9f2403ec
|
@ -100,7 +100,7 @@
|
|||
</li>
|
||||
</ul>
|
||||
<p>
|
||||
In ZaloPay, each team has its own responsibilites/domains, aka many
|
||||
In ZaloPay, each team has its own responsibilities/domains, aka many
|
||||
different services.
|
||||
</p>
|
||||
<p>
|
||||
|
@ -292,6 +292,16 @@
|
|||
knowing when to use and when to not.
|
||||
</p>
|
||||
<p>All of these above are industry standard.</p>
|
||||
<h3>
|
||||
<a
|
||||
id="user-content-write-code-to-delete"
|
||||
class="anchor"
|
||||
aria-hidden="true"
|
||||
tabindex="-1"
|
||||
href="#write-code-to-delete"
|
||||
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
||||
>Write code to delete
|
||||
</h3>
|
||||
<p>
|
||||
The way business moving is fast, so a feature is maybe implemented today,
|
||||
but gets thrown out of window tomorrow (Like A/B testing, one of them is
|
||||
|
@ -326,7 +336,7 @@
|
|||
can be deleted without breaking the other.
|
||||
</p>
|
||||
<p>
|
||||
For example, we can send noti to users using SMS, Zalo, or Noti in app (3
|
||||
For example, we can send noti to users using SMS, Zalo, or noti-in-app (3
|
||||
providers). They are all independently feature which serves same purpose:
|
||||
alert user about something. What happen if we add providers or remove
|
||||
some? Existing providers keep working as usual, new providers should
|
||||
|
@ -341,6 +351,35 @@
|
|||
And when we do not need send noti anymore, we can delete whole of it which
|
||||
includes all providers and still not affecting main flow.
|
||||
</p>
|
||||
<h3>
|
||||
<a
|
||||
id="user-content-write-code-to-test"
|
||||
class="anchor"
|
||||
aria-hidden="true"
|
||||
tabindex="-1"
|
||||
href="#write-code-to-test"
|
||||
><span aria-hidden="true" class="octicon octicon-link"></span></a
|
||||
>Write code to test
|
||||
</h3>
|
||||
<p>
|
||||
Test is not a way to find bug, test is a way for us to make sure what we
|
||||
code is actually what we think.
|
||||
</p>
|
||||
<p>
|
||||
Best case scenerio is test with real dependencies (real servives, real
|
||||
Redis, real MySQL, real Kafka, ...). But it's not easy way to setup
|
||||
yourself.
|
||||
</p>
|
||||
<p>
|
||||
The easier way is to use mocks. Mock all dependencies to test all possible
|
||||
edge cases you can think of.
|
||||
</p>
|
||||
<p>TODO: Show example</p>
|
||||
<p>
|
||||
Same solution is to keep our code loosely coupled as much as possible.
|
||||
</p>
|
||||
<p>Each function/ should be contained.</p>
|
||||
<p>Not all</p>
|
||||
<h3>
|
||||
<a
|
||||
id="user-content-references-1"
|
||||
|
@ -366,6 +405,13 @@
|
|||
>Imaginary Problems Are the Root of Bad Software</a
|
||||
>
|
||||
</li>
|
||||
<li>
|
||||
<a
|
||||
href="https://haunt98.github.io/posts-go/2022-12-25-go-test-asap.html"
|
||||
rel="nofollow"
|
||||
>Speed up writing Go test ASAP</a
|
||||
>
|
||||
</li>
|
||||
</ul>
|
||||
<h2>
|
||||
<a
|
||||
|
|
|
@ -24,7 +24,7 @@ After successfully do all of that, next step is:
|
|||
- Metrics
|
||||
- Tracing
|
||||
|
||||
In ZaloPay, each team has its own responsibilites/domains, aka many different
|
||||
In ZaloPay, each team has its own responsibilities/domains, aka many different
|
||||
services.
|
||||
|
||||
Ideally each team can choose custom backend techstack if they want, but mostly
|
||||
|
@ -129,6 +129,8 @@ and when to not.
|
|||
|
||||
All of these above are industry standard.
|
||||
|
||||
### Write code to delete
|
||||
|
||||
The way business moving is fast, so a feature is maybe implemented today, but
|
||||
gets thrown out of window tomorrow (Like A/B testing, one of them is chosen, the
|
||||
other says bye). So how do we adapt? The problem is to detect, which
|
||||
|
@ -154,7 +156,7 @@ My answer is, as Message Broker introduce concept decoupling, loosely coupled
|
|||
coding. Which means, 2 functions which do not share same business can be deleted
|
||||
without breaking the other.
|
||||
|
||||
For example, we can send noti to users using SMS, Zalo, or Noti in app (3
|
||||
For example, we can send noti to users using SMS, Zalo, or noti-in-app (3
|
||||
providers). They are all independently feature which serves same purpose: alert
|
||||
user about something. What happen if we add providers or remove some? Existing
|
||||
providers keep working as usual, new providers should behave properly too.
|
||||
|
@ -165,10 +167,30 @@ like a module (think like lego) which can be plug and play right away.
|
|||
And when we do not need send noti anymore, we can delete whole of it which
|
||||
includes all providers and still not affecting main flow.
|
||||
|
||||
### Write code to test
|
||||
|
||||
Test is not a way to find bug, test is a way for us to make sure what we code is
|
||||
actually what we think.
|
||||
|
||||
Best case scenerio is test with real dependencies (real servives, real Redis,
|
||||
real MySQL, real Kafka, ...). But it's not easy way to setup yourself.
|
||||
|
||||
The easier way is to use mocks. Mock all dependencies to test all possible edge
|
||||
cases you can think of.
|
||||
|
||||
TODO: Show example
|
||||
|
||||
Same solution is to keep our code loosely coupled as much as possible.
|
||||
|
||||
Each function/ should be contained.
|
||||
|
||||
Not all
|
||||
|
||||
### References
|
||||
|
||||
- [Write code that is easy to delete, not easy to extend.](https://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to)
|
||||
- [Imaginary Problems Are the Root of Bad Software](https://cerebralab.com/Imaginary_Problems_Are_the_Root_of_Bad_Software)
|
||||
- [Speed up writing Go test ASAP](https://haunt98.github.io/posts-go/2022-12-25-go-test-asap.html)
|
||||
|
||||
## Known concept
|
||||
|
||||
|
|
Loading…
Reference in New Issue