RUG — малоизвестный, но фундаментальный принцип Clean Code

Многие разработчики при обсуждении основ Clean Code называют одни и те же принципы — чаще всего упоминаются DRY , KISS и YAGNI . Эти концепции прочно закрепились в профессиональном сообществе и воспринимаются как обязательная часть хорошего кода. Принцип RUG упоминается значительно реже. Чаще всего о нём узнают с опытом, а многие применяют его интуитивно, даже не подозревая, что для этого подхода существует отдельное название и формулировка. Сегодня я хочу поговорить о принципе RUG и о том, какие рекомендации он даёт по написанию программного обеспечения. RUG ( Repeat Until Good ) — это принцип, который говорит: можно повторять один и тот же код, пока это разумно. На ранних этапах разработки важнее просто реализовать логику, исходя из текущих требований, чем пытаться сразу создать «идеальную» абстракцию. В этот момент задача — как можно быстрее получить рабочее решение, которое отражает текущие знания о системе. Но со временем, когда одна и та же логика начинает встречаться всё чаще, становится очевидно, что её удобнее и правильнее выделить в отдельную, чётко оформленную абстракцию, чтобы избежать дублирования и упростить дальнейшую поддержку. Мы используем этот принцип каждый раз, когда пишем код. Ведь практически любую логику можно сделать более абстрактной и масштабируемой — вопрос лишь в том, когда наступает подходящий момент для этого. Я буду использовать TypeScript , так как этот язык знаком большинству разработчиков.

https://habr.com/ru/articles/934986/

Kennst du das? Du musst Code pflegen, den du nie selbst geschrieben hast – und der längst „tot“ oder vergessen ist?

Dead-, Legacy- oder sogar Zombie-Code machen das Leben schwer. Wie erkennst du, was noch lebt? Und wie wirst du die „Leichen“ los?

@hansolo_ spricht auf der #BaselOne25 genau darüber und zeigt Tools gegen Code-Müll: We hate code – The !joy of maintaining dead code am 16. Oktober.

Tickets & Programm: https://baselone.org/#programm

New post:

Segregating a test builder applying the curiously recurring template pattern
https://codesai.com/posts/2025/07/segregating-test-builder

#CleanCode is a lot like #TheBible.

Everyone claims to have read it.

Only a few actually have.

Many misuse its teachings.

New chapter added to the Guile Hacker Handbook

This is a book to learn Guile in a #TestDrivenLearning style

Check it out
https://jeko.frama.io

The app tutorial got a new use-case implemented.

With the rising popularity of FastAPI and Pydantic, it's becoming increasingly important to protect a clean domain, free from third-party tools. I wrote an article to help you with that.

https://coderik.nl/posts/keep-pydantic-out-of-your-domain-layer/

New dev managers: help your team master the foundations.

Dependency Injection
Observer
Repository

Lead by example. Set the standard.

"The best error message is the one that never shows up." – Thomas Fuchs
#ErrorHandling #CleanCode

‘Future-proofing' often leads to unnecessary complexity. Learn how to work confidently with incomplete knowledge in our hands-on workshop on code simplification. Join us for group exercises, discussions, and practical insights that will transform your approach to software design: https://ddd.academy/keeping-it-simple/ #CleanCode #SoftwareArchitecture

Exercise your unit test suite, frequently. It’s your first line of defense against regression, drift, and data decay. Treat it like an immune system — not an ornament.

Time is not absolute. Your code breaks when you treat it that way. https://hackernoon.com/code-smell-307-naive-time-assumptions-and-how-to-fix-it #cleancode

Nice kettlebell flow this morning. Movement patterns in exercise mirror clean code patterns - efficient, purposeful, no wasted motion.

From UML to Inheritance! At #PSConfEU 2025, @stephanevg.bsky.social took us on an OOP journey with #PowerShell classes: Constructors & static members Debugging tips Method overloading made fun PSConfEU 2026 tix live → psconf.eu #CleanCode #PSConfEU2025

- YouTube

️ AI can shave off hours writing boilerplate, but is your delivery really faster? Low‑quality code takes 2.24× longer to maintain.

You ship quickly today but spend twice the time fixing and refactoring tomorrow. That backlog grows fast.

Balance speed with checks: integrate AI suggestions into your CI pipeline so you catch regressions early. Keep your velocity without sacrificing stability.

https://newsletter.optimistengineer.com/p/why-clean-code-matters-5-lessons?r=nw9bj&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false

working on a new very short #presentation about #technicalDept, #cleanCode and #metrics.
whole thing is done in #inkscape, clones and the spray tool are very helpful to create visual slides

REST in #Vaadin? Viele packen es direkt ins UI und wundern sich später über Chaos. @svenruppert liefert einen Bauplan: HttpClient, Adapter, Records & klar getrennte Schichten. So bleibt dein Code testbar!

Lese: https://javapro.io/de/mit-vaadin-flow-rest-endpoints-in-core-java-konsumieren/

#CleanCode #CoreJava #DevSecOps @Vaadin

Just started using an AI coding assistant? Amazing! But beware: even AI-generated code can carry hidden “debt.”

Studies show low‑quality code has 15× more bugs. If you blindly accept AI suggestions, you could be building future headaches.

Action tip: Always run an automated quality scan (SonarQube, CodeScene) on AI‑authored code. Catch issues before they slow you down!

https://newsletter.optimistengineer.com/p/why-clean-code-matters-5-lessons?r=nw9bj&utm_campaign=post&utm_medium=web&showWelcomeOnShare=false

There's an art to writing code comments. Too many and nobody reads them. Too few and future developers curse your name. Find the sweet spot.

Most testing advice sounds great until you try it on a real project.

That’s why I use 4 axioms of testing that hold up in real-world codebases:

1. You can’t test everything
2. You can’t prove it’s bug-free
3. Start early
4. Bias is real

Ask this before writing a test:
**“What’s the purpose of this test in this context?”**

If it doesn’t verify, protect, or document behavior/specs why write it?