Bad Code: Causes, Symptoms, and Refactoring Challenges (Part 1)

The author, a senior engineer at Weibo, shares personal reflections on why many developers end up writing "bad code" and how it affects teams and projects.

1. Writing bad code is easy – Modern languages and frameworks abstract away low‑level details, leading newcomers to treat coding as a mere translation of requirements without understanding design, performance, or architecture.

2. Bad code remains bad – When the original author leaves, maintainers encounter incomprehensible logic, hidden bugs, and endless overtime. The article lists several typical anti‑patterns:

2.1 Unclear purpose – Code that does not convey its intent. Example:

public void save() {
    for (int i = 0; i < 100; i++) {
        //防止保存失败，重试100次
        document.save();
    }
}

2.2 Not human‑readable – Simple logic that is hard for others to understand. Example:

public boolean getUrl(Long id) {
    UserProfile up = us.getUser(ms.get());
    if (up == null) {
        return false;
    }
    if (up.type == 4 || (up.id >> 2) & 1 == 1) {
        return false;
    }
    if (Util.getUrl(up.description)) {
        return true;
    } else {
        return false;
    }
}

2.3 Improper organization – Large monolithic files, duplicated code, and deep call chains that make changes risky and error‑prone.

2.4 Missing abstraction and hard‑coded assumptions – Functions evolve to handle more scenarios without proper refactoring, leading to code like:

public String loadString(String name) {
    File file = new File(name);
    // read something
}

public String loadStringUtf8(String name) {
    File file = new File(name);
    // read something
}

public String loadStringFromNet(String url) {
    HttpClient... // omitted
}

These patterns cause code that was once "good enough" to become unmaintainable as requirements change.

3. Refactoring is not a magic cure – While refactoring can improve quality, it is often more complex and risky than writing new code, especially when the existing code lacks tests, has tight coupling, or is poorly understood.

4. Writing good code is hard – It requires clear requirements, understanding of runtime behavior, sensible abstraction, proper organization, realistic effort estimation, and continuous practice.

The article concludes with two simple takeaways: never expect others to write high‑quality code, and never assume your own code is high quality. The author promises a second part with concrete improvement suggestions.