schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.

This server runs the snac software and there is no automatic sign-up process.

Search results for tag #refactoring

#refactoring boosted

[?]JAVAPRO » 🌐
@javapro@mastodon.social

Your project has 2,000 tests—and nobody knows which are . Jean Donato explains how @OpenRewrite and Dependency Analyzer help you migrate safely, step by step.

Stay sane during test refactors: javapro.io/2025/09/10/masterin

    Ted M. Young boosted

    [?]jpoesen | 🇪🇺 | 🏳️‍🌈 » 🌐
    @jpoesen@drupal.community

    There's a lot of in the future of this 8 project I'm slowly moving to D11.

    Can anyone point to interesting reading on approaches / architecture / design patterns specifically aimed to help separate business/domain logic from application logic, specifically in the context of ?

    Elements from look relevant, and solutions may have interesting approaches as well.

    To the research lair!

      #refactoring boosted

      [?]Foojay.io » 🌐
      @foojay@foojay.social

      How many shortcuts can you remember? Three? Five? More? I try to learn as many as I can and still forget some of them… What if you could unlock IntelliJ IDEA features, without having to remember shortcuts? You can still use shortcuts if you want. But you don’t have to. Command completion (..) is a…...

      foojay.io/today/command-comple

        #refactoring boosted

        [?]Programmer Life » 🌐
        @programmerlife1.wordpress.com@programmerlife1.wordpress.com

        மாற்றங்களே வினா, மாற்றங்களே விடை!

        நீங்கள் ஒரு நாள் சரியாக இல்லாத (messy) code-ஐ கண்டிப்பாக நிச்சயமாக ஏதோ ஒரு வழியில் பெறுவீர்கள்.அதை எழுதிய developer-ஐ கேலி செய்ய வேண்டாம். சில சமயங்களில் அது நீங்கள் எழுதியதாக கூட இருக்கலாம். பல developers […] [SENSITIVE CONTENT]

        நீங்கள் ஒரு நாள் சரியாக இல்லாத (messy) code-ஐ கண்டிப்பாக நிச்சயமாக ஏதோ ஒரு வழியில் பெறுவீர்கள்.
        அதை எழுதிய developer-ஐ கேலி செய்ய வேண்டாம். சில சமயங்களில் அது நீங்கள் எழுதியதாக கூட இருக்கலாம்.

        பல developers ஒரு file-ஐத் திறந்தவுடன்,
        “இந்த குப்பையை யார் எழுதியது ? எல்லாத்தையும் rewrite பண்ணிடலாம்” என்று சொல்வதை நான் பார்த்திருக்கிறேன்.

        ஆனால் Context மிகவும் முக்கியம்.

        அந்த நிர:

        • 2 மணி நேரத்தில் delivery செய்ய வேண்டிய சூழலில் எழுதப்பட்டிருக்கலாம்.
        • அந்த காலத்தில் hooks, modern tools எதுவுமே இல்லாமல் இருக்கலாம்.
        • ஒரே developer, மூன்று பேருடைய வேலையையும் தனியாகச் செய்து கொண்டிருக்கலாம்.

        அதனால் code-ஐ மட்டும் பார்த்து தீர்ப்பு சொல்லக் கூடாது.

        இதற்கு ஒரு நல்ல விதி இருக்கிறது — Boy Scout Rule.

        “நீ கண்ட code-ஐ விட,
        அதை கொஞ்சமாவது சுத்தமாக்கி விட்டு போ.”

        Day 1-லேயே உலகத்தையே மறு உருவாக்கம்(rewrite) செய்ய வேண்டிய அவசியம் இல்லை.

        பல சமயங்களில் அது தேவையில்லாமல் கூட இருக்கலாம்.
        வேலை செய்யும் இடங்களில்,
        சின்ன சின்ன refactor-களை செய்து,
        code-ஐ மெதுவாக நல்ல நிலையில் கொண்டு வருவது தான் புத்திசாலித்தனம் அதுதான் எளிமையாக செய்யக்கூடியதும் கூட.

        இன்னொரு முக்கியமான கருத்து — Chesterton’s Fence.

        “ஒரு வேலி ஏன் போடப்பட்டது என்று தெரியாமல்,
        அதை இடிக்கக் கூடாது.”

        அந்த logic, அந்த hack, அந்த workaround —
        அது ஏதோ ஒரு காரணத்துக்காக அங்கே இருக்கலாம்.

        சில சமயங்களில் காரணங்கள் கூட குறிப்பிடப்பட்டிருக்காது.
        அந்த காரணத்தை புரிந்து கொள்ளாமல் மாற்றினால்,
        புதிய பிரச்சனைகள் உருவாகும்.

        இறுதியாக ஒரு சிந்தனை:

        நீங்கள் எதைக் அதிகம் ரசிக்கிறீர்கள்?
        இருக்கும் code-ஐ புரிந்து, மெதுவாக மேம்படுத்துவதையா?
        அல்லது
        புதிதாக, greenfield project-ஐ ஆரம்பிப்பதையா?

        இரண்டும் developer வாழ்க்கையின் ஒரு பகுதி தான்.
        ஆனால் நல்ல developer என்பவர்,
        கெட்ட code-ஐ பார்த்து கோபப்படாமல்,
        அதன் பின்னணி கதையை புரிந்து கொண்டு,
        அதை நாளுக்கு நாள் சிறப்பாக்குபவரே.

        மாற்றங்களே வினா மாற்றங்களே விடை!

        ஆகவே சற்று சிந்தித்து செயலாற்றுங்கள்!

        #refactoring boosted

        [?]Windy city » 🌐
        @pheonix@hachyderm.io

        Just a random evening thought I wanted to share.

        One specific peculiarity of the software engineering discipline is the slow realization that "clever" code is sometimes a liability. I divided my rationalization in three stages.

        Stage 1: You want to use every design pattern, abstraction and fancy trending framework you read about on Hacker News.
        Stage 2: You realize you're the one who has to debug that mess at 3am six months from now.
        Stage 3: You start optimizing for a fictional person. That person is a junior who hasn't had their first coffee yet and you want readability of code more than anything lol

        Which is why I never quite believed in LOC as an impressive metric. For me, a good PR is as much about reducing 500 lines of legacy technical debt while keeping the system stable as it is about adding a new shiny feature. Anyone else feel this way?

          #refactoring boosted

          [?]Windy city » 🌐
          @pheonix@hachyderm.io

          Just a random evening thought I wanted to share.

          One specific peculiarity of the software engineering discipline is the slow realization that "clever" code is sometimes a liability. I divided my rationalization in three stages.

          Stage 1: You want to use every design pattern, abstraction and fancy trending framework you read about on Hacker News.
          Stage 2: You realize you're the one who has to debug that mess at 3am six months from now.
          Stage 3: You start optimizing for a fictional person. That person is a junior who hasn't had their first coffee yet and you want readability of code more than anything lol

          Which is why I never quite believed in LOC as an impressive metric. For me, a good PR is as much about reducing 500 lines of legacy technical debt while keeping the system stable as it is about adding a new shiny feature. Anyone else feel this way?

            #refactoring boosted

            [?]netrom :emacs: » 🌐
            @netrom@infosec.exchange

            Great refactoring quote: "First make the change easy, then make the easy change." - Kent Beck.

              #refactoring boosted

              [?]Habr » 🤖 🌐
              @habr@zhub.link

              [Перевод] Гексагональная архитектура в Rust: отвязываем бизнес-логику от Solana

              Представьте: вы строите сервис выдачи дипломов на Solana. Всё отлично, пока дело не доходит до тестов. Внезапно оказывается, что для проверки бизнес-логики нужно поднимать валидатор, искать тестовые токены и молиться на стабильность сети. Знакомая боль? В этой статье я покажу, как мы решили проблему, используя async-trait и dyn Trait. Мы превратили интеграционные тесты длиной в минуты в юнит-тесты, которые проходят за миллисекунды. Узнать решение

              habr.com/ru/articles/983874/

                #refactoring boosted

                [?]Habr » 🤖 🌐
                @habr@zhub.link

                Январский рефакторинг: 7 дней, чтобы почистить Python веб‑проект

                Январь - самое удобное время разобрать завалы в проекте. Пол‑команды ещё в отпусках, pull‑реквестов меньше, product owner'ы только вспоминают, что планировали делать в этом году - можно спокойно пройтись по коду и навести порядок. В этой статье пойдёт речь о нескольких косметических действиях, которые, с одной стороны, почти не затрагивают логику программы и не вызывают ненависти у тестировщиков, а с другой - делают код чуть приятнее и дают темы для обсуждения на бэкенд‑созвонах. Мы разложим импорты, перенесём логику из роутов в контроллеры, а из контроллеров - в репозитории и сервисы, избавимся от requirements.txt в пользу нормального менеджера зависимостей и включим mypy.

                habr.com/ru/articles/983172/

                  #refactoring boosted

                  [?]DevTo VN Bot » 🤖 💔 🌐
                  @devto_vn_bot@mastodon.maobui.com

                  Khi AI hỗ trợ refactoring đổi tên hàm, nó tạo ra bất đồng trong mã nguồn: "calculateTotal" và "compute_total" cùng tồn tại trong các file khác nhau. Lý do:
                  - AI chỉ nhìn từng file riêng lẻ
                  - Ngữ cảnh hạn chế + quy tắc đặt tên không thống nhất
                  - Kiểm thử đơn vị không bắt được lỗi

                  Hậu quả: Lỗi runtime trong tích hợp CI. Giải pháp: Kiểm tra tổng thể, grep repo và CI phát hiện xung đột tên.


                  #refactoring boosted

                  [?]Leanpub » 🌐
                  @leanpub@mastodon.social

                  Leanpub book LAUNCH 🚀 The Other Half of Coding: What they Didn't Teach You by Max Guernsey, III

                  Watch here: youtu.be/lDwuiSwaCf4

                    #refactoring boosted

                    [?]DevTo VN Bot » 🤖 💔 🌐
                    @devto_vn_bot@mastodon.maobui.com

                    Tin tức: AI giúp tái cấu trúc mã nguồn hiệu quả! 🤖 LLM phát hiện "code smells" (như hàm dài, lớp cồng kềnh) và gợi ý cải tiến như "Extract Method" với độ chính xác ~80%. Tuy nhiên, quyết định kiến trúc lớn vẫn cần con người đánh giá. ⚠️ Lưu ý: KIỂM THỬ TỰ ĐỘNG là yếu tố sống còn để đảm bảo an toàn khi tái cấu trúc.

                    dev.to/vinicius3w/refatoracao-

                    #refactoring boosted

                    [?]DevTo VN Bot » 🤖 💔 🌐
                    @devto_vn_bot@mastodon.maobui.com

                    Khi AI refactor đổi tên sai trên nhiều file:
                    - Tạo các biến không nhất quán (userProfile → user_profile/profileUser) dù patch trông "hợp lý"
                    - Gây lỗi runtime (500 Server Error), CI không phát hiện
                    - Nguyên nhân: AI không hiểu ngữ nghĩa mã, chỉ đoán văn bản & thiếu quản lý symbol tập trung
                    - Bài học: Ưu tiên công cụ refactor dựa AST/IDE, test tích hợp đầy đủ, xử lý AI-output như bản nháp

                    #refactoring boosted

                    [?]DevTo VN Bot » 🤖 💔 🌐
                    @devto_vn_bot@mastodon.maobui.com

                    Bài viết chia sẻ kinh nghiệm tái cấu trúc kiến trúc Android: Giảm boilerplate code, tách module cơ bản & tính năng riêng biệt. Lợi ích: Chuẩn hóa code, dễ bảo trì, onboarding nhanh. Khó khăn: Xử lý dependency, tài nguyên phân tán & vấn đề Gradle. Nhấn mạnh việc duy trì tài liệu và cải tiến liên tục!

                    dev.to/dss99911/simple-android

                      #refactoring boosted

                      [?]DevTo VN Bot » 🤖 💔 🌐
                      @devto_vn_bot@mastodon.maobui.com

                      "Hãy ngừng tối ưu code không bao giờ thay đổi! 😓 Ưu tiên refactoring "điểm nóng" - mã xấu NHƯNG thường xuyên chỉnh sửa, không phải code ổn định. Ví dụ: Đừng tốn tuần chỉnh module LegacyAuthenticator (0 thay đổi sau 3 năm), hãy sửa PaymentProcessor (47 lần/tháng) đang cực phức tạp!

                      Dùng git log để xác định hotspot, tập trung nơi chất lượng thấp + tần suất sửa cao. Mã ổn định dù xấu, hãy để ngủ yên.

                        #refactoring boosted

                        [?]DevTo VN Bot » 🤖 💔 🌐
                        @devto_vn_bot@mastodon.maobui.com


                        Giới thiệu "Parameter Object" - giải pháp tái cấu trúc giảm phức tạp tham số! 💡

                        Thay vì khai báo hàng loạt tham số rời rạc:
                        `createInvoice($customerId, $currency, $netAmount...)`
                        👉 Gộp thành đối tượng có ngữ cảnh như `TaxContext` hay `PricingContext`.

                        Lợi ích:
                        • Giảm lỗi thứ tự tham số
                        • Đóng gói logic liên quan
                        • Dễ mở rộng khi yêu cầu thay đổi
                        • Code dễ đọc & bảo trì hơn

                        Mẹo: Bắt đầu từ phương thức nhỏ, thêm

                        #refactoring boosted

                        [?]Leanpub » 🌐
                        @leanpub@mastodon.social

                        Leanpub book LAUNCH 🚀 The Other Half of Coding: What they Didn't Teach You by Max Guernsey, III

                        Watch here: youtu.be/lDwuiSwaCf4

                          #refactoring boosted

                          [?]Habr » 🤖 🌐
                          @habr@zhub.link

                          MDUI: как отдать UI backend-разработчикам

                          Как сократить Time-to-Market в 7 раз и научить бэкенд-разработчиков собирать страницы за 15 минут? В этой статье я делюсь опытом внедрения Meta-Driven UI в ERP-системе. Расскажу, как я «душила» легаси с помощью Strangler Fig Pattern, внедрила FSD-архитектуру на Vue 3 и почему Render-функции оказались эффективнее обычных шаблонов.

                          habr.com/ru/articles/980684/

                            #refactoring boosted

                            [?]DevTo VN Bot » 🤖 💔 🌐
                            @devto_vn_bot@mastodon.maobui.com

                            Bài viết hướng dẫn refactoring class OrderManager违反 Single Responsibility Principle (SRP) bằng Clprolf. Ban đầu dùng `indef_obj` để linh hoạt, sau đó tách biệt responsibilities: `agent` (OrderProcessor) cho nghiệp vụ và `worker_agent` (OrderRepository, OrderNotifier) cho kỹ thuật.

                            dev.to/charles_koffler_bcabc58

                              #refactoring boosted

                              [?]DevTo VN Bot » 🤖 💔 🌐
                              @devto_vn_bot@mastodon.maobui.com

                              Hệ thống PHP "monolith" của chúng tôi vẫn hoạt động tốt — vậy tại sao lại thay đổi? Không có khủng hoảng, nhưng sự phụ thuộc chặt chẽ gây cản trở phát triển. Thay vì rewrite, chúng tôi chuyển đổi từ từ: giữ nguyên lõi hoạt động, tách dần giao diện, tăng tính linh hoạt. Thay đổi sớm khi hệ thống còn khỏe giúp tránh rủi ro sau này.

                              dev.to/rizts/our-php-monolith-

                              #refactoring boosted

                              [?]Leanpub » 🌐
                              @leanpub@mastodon.social

                              #refactoring boosted

                              [?]Leanpub » 🌐
                              @leanpub@mastodon.social

                              Leanpub book LAUNCH 🚀 The Other Half of Coding: What they Didn't Teach You by Max Guernsey, III

                              Watch here: youtu.be/lDwuiSwaCf4

                                7 ★ 2 ↺

                                [?]Amitai Schleier » 🌐
                                @schmonz@schmonz.com

                                It’s hard to fix something because it’s easy to break something else?

                                That’s your clue: refactor first.

                                (Special case of the general KFB wisdom “First make the change easy, then make the easy change.”)


                                  #refactoring boosted

                                  [?]HackerNews VN bot » 🤖 💔 🌐
                                  @hackernews_bot_vn@mastodon.maobui.com

                                  🔧 Phương pháp Mikado giúp thực hiện thay đổi an toàn trong codebase phức tạp: chia nhỏ các công việc, giải quyết phụ thuộc từng bước, giảm rủi ro và tăng khả năng bảo trì.

                                  understandlegacycode.com/blog/

                                  #refactoring boosted

                                  [?]DevTo VN Bot » 🤖 💔 🌐
                                  @devto_vn_bot@mastodon.maobui.com

                                  🛠️ Refactor phương thức private → lớp riêng để test dễ dàng, tránh reflection/metaprogramming yếu. Tách logic “stripStrangeCharacters” thành `CharacterStripper`, viết unit test trực tiếp, rõ ràng, giảm phụ thuộc ẩn và cải thiện thiết kế miền. Áp dụng khi logic phức tạp, không cho các getter/setter đơn giản.

                                  dev.to/mcsee/refactoring-037-t

                                  #refactoring boosted

                                  [?]JAVAPRO » 🌐
                                  @javapro@mastodon.social

                                  Even if you’ve read the JEPs—have you used to refactor old-school branching logic? @manojnp shows how to turn bloated instanceof trees into readable, idiomatic code with just records.

                                  👉 javapro.io/2025/01/15/record-p

                                    #refactoring boosted

                                    [?]Habr » 🤖 🌐
                                    @habr@zhub.link

                                    Технический долг в голове: Почему сеньоры выгорают на задачах для джунов, а пет-проекты умирают в бэклоге

                                    В прошлой статье я рассказывал, как настроил личный iptables и перешел в режим Default Deny , чтобы отбиться от внешних DDoS-атак (коллег, пустых встреч и спама). Периметр я защитил, входящий трафик почистил. Uptime вырос. Казалось бы — живи и радуйся. Но я заметил странную вещь: снаружи тихо, а сервер все равно греется. Я заглянул внутрь контейнера и понял: проблема не во входящих пакетах. Проблема в архитектуре самого приложения . Парадокс: я могу спроектировать архитектуру, которая выдержит падение дата-центра. Я могу дебажить race condition в многопоточном приложении. Но когда мне нужно позвонить в страховую или выбрать отель для отпуска, я впадаю в ступор. Мой личный бэклог забит задачами типа «разобраться с налогами» и «начать бегать», которые висят там с 2019 года. Я переношу их из спринта в спринт, испытывая фоновое чувство вины. В какой-то момент я понял: это не лень. И это не «отсутствие мотивации». Это классический Technical Debt (Технический долг) , только не в репозитории, а в нейросети. И проценты по этому долгу я плачу самым дорогим ресурсом — своей когнитивной емкостью.

                                    habr.com/ru/articles/973796/

                                    #refactoring boosted

                                    [?]Sébastien Roccaserra 🐿️ » 🌐
                                    @sroccaserra@mastodon.social

                                    J'ai apprécié cet article de @jbrains. Quand on simplifie du code, paradoxalement il y a un risque de le rendre moins familier (ce n'est plus comme avant, ce n'est plus comme on a toujours fait). Ça peut être une raison d'accepter de ne pas simplifier. Mais si on ne prend jamais ce risque, on passe à côté d'opportunités de simplifications. Compromis... Je trouve intéressant d'avoir ça en tête collectivement.

                                    => blog.jbrains.ca/permalink/a-ce

                                      Back to top - More...