github

17 posts

line

ODW #3: Boosting Development Efficiency by Safely Utilizing MCP Servers (opens in new tab)

안녕하세요. LY Corporation의 aikawa입니다. Yahoo! 지도 및 Yahoo! 환승 안내 iOS 앱 개발을 담당하고 있고, iOS 영역의 Developer Relations 역할도 담당하고 있습니다. LY Corporation에서는 AI를 활용해 담당 업무를 개선하려는 움직임이 사내에서 빠르게 확산되면서 많은 임직원이 일선에서 AI를 활용하고 있습니다. 저희는 현장 곳곳에서 창출되는 활용 사례와 지식이 해당 현장에만 머무르지 않고 사내외로 공유돼 다음 도전으로 이어질 수 있도록…

line

Sharing the workflow of a 3rd (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.