techlist.io
KR EN

code-review

3 posts

woowahan

We Refactor Culture Just Like (opens in new tab)

The Commerce Web Frontend Development team at Woowa Brothers recently underwent a significant organizational "refactoring" to manage the increasing complexity of their expanding commerce platform. By moving away from rigid, siloed roles and adopting a flexible "boundary-less" part system, the team successfully synchronized disparate services like B Mart and Baemin Store. This cultural shift demonstrates that treating organizational structure with the same iterative mindset as code can eliminate operational bottlenecks and foster a more resilient engineering environment. ### Transitioning to Boundary-less Parts * The team abandoned traditional division methods—such as project-based, funnel-based, or service-vs-backoffice splits—because they created resource imbalances and restricted developers' understanding of the overall service flow. * Traditional project-based splits often led to specific teams being overwhelmed during peak periods while others remained underutilized, creating significant delivery bottlenecks. * To solve these inefficiencies, the team introduced "boundary-less parts," where developers are not strictly tied to a single domain but are encouraged to work across the entire commerce ecosystem. * This structure allows the organization to remain agile, moving resources fluidly to address high-priority business needs without being hindered by departmental "walls." ### From R&R to Responsibility and Expandability (R&E) * The team replaced the traditional R&R (Role & Responsibility) model with "R&E" (Responsibility & Expandability), focusing on the core principle of "owning" a problem until it is fully resolved. * This shift encourages developers to expand their expertise beyond their immediate tasks, fostering a culture where helping colleagues and understanding neighboring domains is the standard. * Work is distributed through a strategic sync between team and part leaders, but team members maintain the flexibility to jump into different domains as project requirements evolve. * Regular "part shuffling" is utilized to ensure that domain knowledge is distributed across the entire 20-person frontend team, preventing the formation of information silos. ### Impact on Technical Integration and Team Resilience * The flexible structure was instrumental in the "ONE COMMERCE" initiative, which required integrating the technical stacks and user experiences of B Mart and Baemin Store. * Because developers had broad domain context, they were able to identify redundant logic across different services and abstract them into shared, common modules, ensuring architectural consistency. * The organization significantly improved its "Bus Factor"—the number of people who can leave before a project stalls—by ensuring multiple engineers understand the context of any given system. * Developers evolved into "domain-wide engineers" who understand the full lifecycle of a transaction, from the customer-facing UI to the backend administrative and logistics data flows. To prevent today's organizational solutions from becoming tomorrow's cultural legacy debt, engineering teams should proactively refactor their workflows. Moving from rigid role definitions to a model based on shared responsibility and cross-domain mobility is essential for maintaining velocity and technical excellence in large-scale platform environments.

code-reviewrefactoringautomationfrontend+3
line

Code Quality Improvement Techniques Part (opens in new tab)

Effective code review communication relies on a "conclusion-first" approach to minimize cognitive load and ensure clarity for the developer. By stating proposed changes or specific requests before providing the underlying rationale, reviewers help authors understand the primary goal of the feedback immediately. This practice improves development productivity by making review comments easier to parse and act upon without repeated reading. ### Optimizing Review Comment Structure * Place the core suggestion or requested code change at the very beginning of the comment to establish immediate context. * Follow the initial request with a structured explanation, utilizing headers or numbered lists to organize multiple supporting arguments. * Clearly distinguish between the "what" (the requested change) and the "why" (the technical justification) to prevent the intended action from being buried in a long technical discussion. * Use visual formatting to help the developer quickly validate the logic behind the suggestion once they understand the proposed change. ### Immutability and Data Class Design * Prefer the use of `val` over `var` in Kotlin `data class` structures to ensure object immutability. * Using immutable properties prevents bugs associated with unintended side effects that occur when mutable objects are shared across different parts of an application. * Instead of reassigning values to a mutable property, utilize the `copy()` function to create a new instance with updated state, which results in more robust and predictable code. * Avoid mixing `var` properties with `data class` features, as this can lead to confusion regarding whether to modify the existing instance or create a copy. ### Property Separation by Lifecycle * Analyze the update frequency of different properties within a class to identify those with different lifecycles. * Decouple frequently updated status fields (such as `onlineStatus` or `statusMessage`) from more stable attributes (such as `userId` or `accountName`) by moving them into separate classes. * Grouping properties by their lifecycle prevents unnecessary updates to stable data and makes the data model easier to maintain as the application scales. To maintain high development velocity, reviewers should prioritize brevity and structure in their feedback. Leading with a clear recommendation and supporting it with organized technical reasoning ensures that code reviews remain a tool for progress rather than a source of confusion.

code-reviewcode-qualitycode-qualitykotlin+2
line

Sharing the workflow of a (opens in new tab)

This blog post outlines a structured nine-step workflow designed to enhance development efficiency and improve the code review experience within a collaborative team environment. By emphasizing pre-implementation simulation, task visualization through Jira, and proactive self-feedback, the author demonstrates how breaking work into manageable, reviewer-friendly units leads to more predictable and reliable software delivery. The core conclusion is that prioritizing "reviewability" through small, logical increments fosters team trust and reduces technical debt. ### Strategic Planning and Simulation * Begin by thoroughly reviewing requirements and simulating the feature’s behavior, focusing specifically on data flow, state management, and edge cases. * Proactively communicate with stakeholders to clarify ambiguities and suggest user experience improvements before any code is written. * Draft high-level diagrams or flowcharts to map out how data points interact and where specific logic should reside, ensuring a solid architectural foundation. ### Task Visualization and Collaborative Alignment * Organize features into Jira Epics and decompose them into granular tickets that include estimated effort and dependencies. * Sync with teammates early—specifically between workflow design and ticket creation—to align on technical direction and prevent significant rework during the final review stage. * Ensure ticket titles are concise and descriptive to allow teammates to understand the project's progress at a glance. ### PoC-Driven Iteration and Self-Feedback * Conduct Proof of Concept (PoC) or prototyping to validate assumptions and identify unforeseen technical challenges before committing to a final implementation. * Perform self-feedback by checking the volume of code changes; the author suggests a 400-line threshold, beyond which a ticket should be split into sub-tasks to maintain clarity. * Use tools like `git diff` or temporary PR branches to review your own work from the perspective of a reviewer, identifying parts of the code that may be difficult to digest. ### Implementation and Documentation for Reviewers * Commit code in small, meaningful increments with clear messages, following a logical sequence such as defining interfaces before their actual implementations. * Draft Pull Requests (PRs) using standardized templates that include the purpose of the change, affected features, and developer test results. * Include visual aids, such as videos or screenshots, for complex UI changes or intricate workflows to reduce the cognitive load on the reviewer. ### Future Process Refinement * Improve the accuracy of project timelines by strictly recording actual time spent on tickets compared to original estimates in Jira. * Analyze the delta between "Estimated" and "Actual" time to better understand personal development velocity and refine future scheduling. Adopting this systematic approach helps developers transition from simply "writing code" to managing a complete technical lifecycle. For teams prioritizing code quality, implementing a line-count threshold for PRs and scheduling early-stage technical alignment sessions can significantly reduce "review fatigue" and streamline the path to production.

code-reviewjirapull-requestworkflow-management+4