Seonglae Cho- Analyze codebase using Ranked Recursive Summarization
- Identify weak points and group related code segments (High Cohesion)
- Distribute refactoring tasks among team members with clear interface (Low Coupling)
- Begin by addressing dependencies, data models, and configuration
- Implement code generation to meet regulatory requirements
It is unwise to introduce new technology where there are no problems
- Expose problems explicitly
- Don't negate the previous system
- Ask for opinions and thoughts
Big leaps require high capability; most people can’t execute abrupt, large-scale change. The magnitude of change depends on capability. Most people usually cannot change drastically in one step; they either change slowly or fail to change at all.
Refactoring Tools
Refactoring Notion
Rewrite total things are dangerous
You can't stop the business, or why rewrites fail | Swizec Teller
Rewriting code isn't a magic fix-all. Consider the opportunity cost, complexity of the old system, and estimation challenges. Instead of stopping all to rewrite or building new while maintaining the old, try incremental improvements and new code adoption.
https://swizec.com/blog/you-can-t-stop-the-business-or-why-rewrites-fail/
[2020-11-11] 5년차 개발자
나에게 5년차라는 개발 연차는 조금 특별하다. 첫 회사에서 내가 속한 조직에는 시니어 개발자가 없었다. 내가 입사했을 때 1년 정도 차이가 나는 선배개발자가 한분 있었고, 입사한 후 6개월 텀으로 1~2명 정도의 신입 개발자들만 채워졌다. 당시에 동료들과 나는 5년차 개발자에 관해 이야기를 많이 했다. 회사에 5년차 정도의 개발자 한분만 오셨으면 좋겠다고 매일 이야기했다.
![[2020-11-11] 5년차 개발자](https://t1.daumcdn.net/tistory_admin/static/top/favicon_0630.ico)
https://blog.kingbbode.com/51
![[2020-11-11] 5년차 개발자](https://img1.daumcdn.net/thumb/R800x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FK997p%2FbtqM9PyDRsj%2FPMNZckfkz9AkgI0BdRZbi0%2Fimg.png)
Generally, it's preferred to create a new system instead of trying to copy another one. If you're just trying to replicate, you end up following their lead and lose control over ayour own project.
The Alternative Implementation Problem
In this post, I want to talk about a dynamic that I’ve seen play itself over and over again in the software world. In fact, I would venture a guess that this kind of situation probably happen…
https://pointersgonewild.com/2024/04/20/the-alternative-implementation-problem/
Software Security
Rewriting large-scale systems in trendy languages (like Rust) is very risky, and changing without clear business benefits is irresponsible. Rewrites are prone to bugs, security flaws, and missing features. Using the Cloudflare outage as an example, it's described as if Rust's
unwrap() causing a panic was the root cause. The rebuttal is that the real issue is not the language, but design, error handling, and architecture. It's not a Rust vs C++ problem, but rather the danger of big-bang rewrites and lack of guardrails and validation. Rust's goal is memory/concurrency safety, not preventing logic errors. unwrap() is an anti-pattern in production.Why rewriting systems in Rust is risky | Herik Lima posted on the topic | LinkedIn
𝗕𝗲𝘄𝗮𝗿𝗲 𝗼𝗳 𝘁𝗵𝗲 "𝗧𝗿𝗲𝗻𝗱𝘆 𝗟𝗮𝗻𝗴𝘂𝗮𝗴𝗲": 𝗪𝗵𝘆 𝗥𝗲𝘄𝗿𝗶𝘁𝗶𝗻𝗴 𝗦𝘆𝘀𝘁𝗲𝗺𝘀 𝗶𝘀 𝗥𝗶𝘀𝗸𝘆 Who would have imagined that swapping a language with over 40 years of development, evolution, and maturity like 𝗖++ for the adventure of rewriting an entire application in 𝗥𝘂𝘀𝘁 could end in disaster? It’s like leaving a decades-long marriage — with a spouse who helped build a stable life, a family, and prosperity — for a 20-year-old reckless lover, chosen only for being “younger” and “prettier.” Six months later, she demands a divorce, he loses almost everything, and ends up on the brink of bankruptcy and in poverty. This has been the reality for many companies chasing the “trend” of rewriting entire systems. Rewriting systems without a solid reason is, in my view, completely irresponsible. Technology is a means, not an end. Migrating to a new language or technology must be well justified, bringing real business benefits — something that would not be possible or feasible with the current technology. Changing just for the sake of change is a huge risk. When rewriting systems, you inevitably introduce bugs, security flaws, and may overlook existing features or corner cases, causing financial losses and reputational damage that can be irreparable. If the change does not bring tangible benefits — increased profit, cost reduction, or a better customer experience — it’s simply not worth it. 𝗥𝗲𝗰𝗲𝗻𝘁 𝗲𝘅𝗮𝗺𝗽𝗹𝗲: Cloudflare suffered a major outage affecting numerous online services, including X and ChatGPT. The issue started because a configuration file grew larger than expected. In 𝗥𝘂𝘀𝘁, 𝘂𝗻𝘄𝗿𝗮𝗽() caused a panic, crashing the process. In languages like C++ or even in Java, this could have been handled with 𝗲𝘅𝗰𝗲𝗽𝘁𝗶𝗼𝗻𝘀 (𝘁𝗿𝘆-𝗰𝗮𝘁𝗰𝗵), preventing the service from going down. 𝗠𝗼𝗿𝗮𝗹 𝗼𝗳 𝘁𝗵𝗲 𝘀𝘁𝗼𝗿𝘆: don’t blindly follow the “trendy language” — carefully evaluate real risks and benefits before rewriting your system. Fabio Galuppo Leidson Campos A. Ferreira Eduardo Bezerra José Augusto N. G. Manzano Jurriaan Schreuder Michel Tonetti Márcio Ubiratan Rosa Frank Alcantara, Me. Calebe de Paula Bianchini C++ MasterClass #C++ #Rust #SoftwareEngineering #TechRisks #SystemRewrite #Programming #TechLeadership #CyberSecurity #SoftwareDevelopment #TechAdvice | 95 comments on LinkedIn
https://www.linkedin.com/posts/heriklima_c-rust-softwareengineering-activity-7397055048595279872-xwNt/
Cloudflare outage on December 5, 2025
Cloudflare experienced a significant traffic outage on December 5, 2025, starting approximately at 8:47 UTC. The incident lasted approximately 25 minutes before resolution. We are sorry for the impact that it caused to our customers and the Internet. The incident was not caused by an attack and was due to configuration changes being applied to attempt to mitigate a recent industry-wide vulnerability impacting React Server Components.
https://blog.cloudflare.com/5-december-2025-outage/
