improvements of server-side developer team. › We focused on internal development processes, especially repository management and review. Because we believe that quick feedback and the continuous small improvements is the basis of improving throughput. › As a result, we saved 89% of time until PR is merged, and many qualitative surveys showed an increase in development speed.
process. = A.k.a. BPR (Business Process Re-engineering) Code Refactoring Rewrite your code without functional change. For maintainability, runtime optimization etc.
/ modules. › For explicit R&R of module and developer. › After: Single (Monolithic) repository for all team member with directories for each micro-services. › Why?
for single feature. › Dependency version, coding styles, CI tools not aligned. › All of those is a result of “Micro- repository (Anti) Pattern”. Domain Internal API manager.line.biz PR PR PR
› I think we should split modules for new feature. › But time and individual efforts needed. › After: Mono-repository mind. › Just create directory. Moving files. Done. With history. › Module test coverage ++.
to development. › Applied in our team. (13Dev, 3 Units › Ref: › Big IT company also uses mono-repo. ※ ※ Rachel Potvin and Josh Levenberg, “Why Google stores billions of lines of code in a single repository,” Communications of the ACM, 59 No. 7 (2016): 78-87.
working. Can someone please check it?” › Problem: Even many developers coding on this repo. But no one noticed test environment is broken. › Because: No one respect (coding on) development branch.
small repository. › But not for large repository. Mainline (A.K.A master) / Developers on it Development (A.K.A. Beta) QA, Planner, other teams on it New features No problem for small team. But uncontrollable when service scaled.
too difficult for human. › Especially team management. › Anti-Pattern: THEIR(Team’s) latest is not MY latest. › Solution: Define single truth of mainline. › Starting point of development = reviewed = internal beta = next release candidate.
Bottleneck = Upper limit of your team throughput. › Improvements or cost cutting not related to the bottleneck does not increase throughput. › Bottleneck but no one prioritize it.
Do you finish code reviews before starting write your code? › Do you subscribe notification when code review requested? › Do you check PR list regularly like checking slack?
finally releases. My interruption cost is higher than benefit of fast feedback for peers. Isn’t it? › NO! › Pending PR is stock. › Stock is not assets. It’s liabilities. › Of course, you need a “zone”. Please remind reviewing when you interrupted.
Process refactoring. › ≒ BPR (Business Process Re-engineering). › Code refactoring. (Design patterns etc.) › Both important. But fast code refactoring depends on process refactoring.
Making repository simple. › Use directory instead multi-micro-repository. › Making branch strategy simple. › Only one special mainline branch (main / master / mainline).
› Checklist › Do you finish code reviews before starting write your code? › Do you subscribe notification when code review requested? › Do you check PR list regularly like checking slack? › Most important thing is the culture and trust that submitting review is one of the fastest way to got feedback and improve your ideas.
review. That makes schedule clear. › Conflict reduced. Many merge operation is not needed. › Context switching between coding and reviewing is not needed.
review. That makes schedule clear. › Conflict reduced. Many merge operation is not needed. › Context switching between coding and reviewing is not needed. › Cons › Need to protect unreleased feature by feature flag. › But better than managed by branch.
line_devday2020
ham0215
takakiyo
nakamuuu
.JPG){kind=avatar}
koh_naga
heleeen
trycycle
lycorptech_jp
yuhta28
yamahiro
sansantech
__allllllllez__
kongmingstrap
sachag
addyosmani
panda_program
chriscoyier
shlominoach
bryan
jponch
brad_frost
colly
zakiyama
ddemaree
