Oleksandr Marchenko

🔑 𝗠𝗮𝘀𝘁𝗲𝗿𝗶𝗻𝗴 𝗦𝗢𝗟𝗜𝗗 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗶𝗻 𝗦𝗼𝗳𝘁𝘄𝗮𝗿𝗲 𝗗𝗲𝘀𝗶𝗴𝗻 Writing clean, maintainable, and scalable code isn’t just about syntaxit’s about design. That’s where SOLID Principles come in. These five timeless guidelines help developers build robust applications that are easier to extend, test, and maintain. Let’s break them down with practical detail: 1️⃣ 𝗦𝗶𝗻𝗴𝗹𝗲 𝗥𝗲𝘀𝗽𝗼𝗻𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝘆 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗦𝗥𝗣) 👉 𝗗𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻: A class should have only one responsibility or reason to change. 📌 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀: - Classes that do too much quickly become fragile and hard to - maintain. Changing one responsibility might accidentally break another. 🔑 𝗕𝗲𝗻𝗲𝗳𝗶𝘁: Focused classes are easier to understand, test, and reuse. 2️⃣ 𝗢𝗽𝗲𝗻-𝗖𝗹𝗼𝘀𝗲𝗱 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗢𝗖𝗣) 👉 𝗗𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻: Classes should be open for extension, closed for modification. 📌 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀: - Keeps existing code stable while allowing new features to be added. - Prevents bugs from creeping in when requirements change. 🔑 𝗕𝗲𝗻𝗲𝗳𝗶𝘁: Future-proof code that supports growth without breaking existing features. 3️⃣ 𝗟𝗶𝘀𝗸𝗼𝘃 𝗦𝘂𝗯𝘀𝘁𝗶𝘁𝘂𝘁𝗶𝗼𝗻 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗟𝗦𝗣) 👉 𝗗𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻: Subclasses should replace their base classes without breaking the application. 📌 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀: Violations lead to unexpected behavior and broken inheritance chains. Ensures your abstractions actually behave as promised. 🔑 𝗕𝗲𝗻𝗲𝗳𝗶𝘁: Reliable and consistent code with true polymorphism. 4️⃣ 𝗜𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲 𝗦𝗲𝗴𝗿𝗲𝗴𝗮𝘁𝗶𝗼𝗻 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗜𝗦𝗣) 👉 𝗗𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻: No client should be forced to depend on methods it does not use. 📌 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀: - Large interfaces become “fat” and force implementing classes to provide dummy methods. - Leads to unnecessary coupling. 🔑 𝗕𝗲𝗻𝗲𝗳𝗶𝘁: Flexible contracts that encourage clean, modular design. 5️⃣ 𝗗𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗜𝗻𝘃𝗲𝗿𝘀𝗶𝗼𝗻 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲 (𝗗𝗜𝗣) 👉 𝗗𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻: Depend on abstractions, not concrete implementations. 📌 𝗪𝗵𝘆 𝗶𝘁 𝗺𝗮𝘁𝘁𝗲𝗿𝘀: - High-level modules shouldn’t be tied to low-level implementation details. - Makes code easier to test, mock, and extend. 🔑 𝗕𝗲𝗻𝗲𝗳𝗶𝘁: Enhances testability, reduces coupling, and increases flexibility. 💡 Next time you write a class, ask yourself: Am I following SOLID? 👉 Follow me Kanaiya Katarmal, and hit the 🔔 on my profile so you don’t miss upcoming .NET tips and deep dives. 𝗧𝗵𝗮𝗻𝗸𝘀 𝗳𝗼𝗿 𝗿𝗲𝗮𝗱𝗶𝗻𝗴 𝗹𝗲𝘁’𝘀 𝗰𝗼𝗻𝘁𝗶𝗻𝘂𝗲 𝗴𝗿𝗼𝘄𝗶𝗻𝗴 𝗮𝗻𝗱 𝗹𝗲𝗮𝗿𝗻𝗶𝗻𝗴 .𝗡𝗘𝗧 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿! 👉 𝗦𝘂𝗯𝘀𝗰𝗿𝗶𝗯𝗲 𝘁𝗼 𝗺𝘆 𝗻𝗲𝘄𝘀𝗹𝗲𝘁𝘁𝗲𝗿: https://lnkd.in/dp7tz_3V #SoftwareEngineering #SOLIDPrinciples #CleanCode #DesignPatterns #Programming #CodeQuality #Developers #SoftwareDesign #OOP

418

31 коментар

JetBrains just announced they're moving to a single, unified IntelliJ distribution starting with version 2025.3. No more choosing between Community and Ultimate - it's one IDE with features unlocked by subscription. Why does this matter? • Some previously paid features (Spring support, database tools) are becoming FREE • The open-source commitment remains, but with a twist • This signals bigger changes in how dev tools compete in the AI era I spent time analyzing the announcement and its implications. This isn't just about IntelliJ - it's about the future of IDEs in a world where AI assistants are changing how we write code. Full analysis here → https://lnkd.in/gBpSNWUu Curious: How many of you are using IntelliJ Community Edition today? What's your take on this change?

162

4 коментарі

I’ve been thinking a lot about where multiplatform development is heading. With tools like Kotlin Multiplatform becoming truly practical, the expectation to share more logic across platforms is growing fast. Lately I started exploring Rust as a multiplatform option. Rust is usually aimed at C++ developers and systems programmers, but I keep coming back to this question: What if Rust were approachable for mobile developers too? One of the big reasons Rust interests me is its mix of performance and safety. You get native speed without garbage collection or ARC, strong guarantees around memory safety, and the ability to ship the same core module to iOS, Android, desktop, backend, or even WebAssembly without rewriting it per platform. That makes it another compelling option for shared business logic or core components across platforms. Some apps already use Rust as a strong core layer. I'm exploring to see how viable it is for mobile devs to try out, even if it's for a small module rather than replacing a full-blown business layer across multiple apps. I want to see how we can make it less intimidating and more accessible for everyday app developers. I’m exploring this and will share more as I go. If there is enough interest, I’ll go deeper. I'll share my findings on https://lnkd.in/emVy_hFv

96

15 коментарів

You know that one senior dev on your team; let's call her Sarah. She makes everything look effortless: - Debugs issues in minutes while you're still stuck after hours - Writes clean code that just works - Explains complex concepts so clearly even non-tech people get it - Stays calm when production breaks You watch Sarah and think:  “I want to code like her.” So you try copying what you see; her debugging approach, coding style, PR structure. But it doesn't work the same for you. Here's why:  You're copying her methods, not her system. What you see: - Sarah writes clean code on first try - Quick, methodical debugging  - Clear technical communication What you DON'T see: - 2 years building her debugging framework - Her collection of refined code snippets - Daily 15-min learning ritual - Mistake log she updates after every bug - Weekly reflection sessions analyzing what worked/didn't Sarah's invisible debugging system: 1. Always reproduce the bug first 2. Check the same 5 places every time 3. Set 20-min timer, if stuck, ask for help 4. Update her "common issues" doc after each fix Her calm confidence?  It comes from having systems she trusts. When production breaks, she's not stressed, she has a proven process. You get stressed because you're improvising every time. Start building YOUR system: Week 1: Start a debug log Week 2: Create a 15-min daily learning ritual  Week 3: Build your first checklist/template Don't copy Sarah's methods. Build the system that will create YOUR methods. The senior dev others want to emulate?  That's who you become when you stop copying outputs and start building systems. What system are you building this week? 👇

91

41 коментар

Waiting half an hour for your tests to finish? That’s not feedback - that’s punishment 🧪 You might have been there: Every new integration test adds another minute to your overall build time. Twenty minutes turn to thirty. CI times explode. Developers stop writing integration tests and become unhappy. Flaky tests appear. Bugs slip through. Releases slow down. But what if you could slash that time, without deleting a single test? With Spring Test, that's possible. It's a hidden gem called Spring TestContext Context Caching 🏆 So, how do you know how many contexts are spinning up? More importantly, how do you figure out why they aren’t being reused? That’s why I built Spring Test Profiler ⏱️ Meet Spring Test Profiler - the free, open-source x-ray for your test suite. Integration is as simple as this three-step process: 1. Add the dependency (Maven/Gradle snippets appear on screen). 2. Run your tests. 3. Open the report at: target/spring-test-profiler/report.html. Within the report, you’ll see: • How many contexts started, and why. • Which tests are sharing configs versus starting their own. • Exact diffs: profiles, properties, or annotations blocking cache reuse. The overall goal is to help identify cache misses and align your tests to reuse contexts for faster feedback 🚤 Spring Test Profiler: Profile. Optimize. Deliver. Try it yourself: https://lnkd.in/djXVJiNE Below is a demo of a section in the report to analyze and compare two contexts 🆚

49

5 коментарів

🚨 More than 70% of frontend devs struggles with this follow-up question in interview about PWAs? When asked: “How does offline access work in a PWA?” Most confidently say: “Because of Service Workers!” ✅ Correct… but do you know 👇 💡 “What’s the difference between Service Workers and Web Workers?” This is where many candidates struggle but not anymore Here’s the breakdown you should never forget: ⚡ Web Workers 1️⃣ Run JS in a separate thread → avoid blocking the UI. 2️⃣ Die when the page closes. 3️⃣ Best for CPU-heavy tasks (e.g. image processing, data crunching). 🌐 Service Workers 1️⃣ Act as a proxy between your app & the network. 2️⃣ Can intercept requests, cache responses, & serve content offline. 3️⃣ Live beyond page lifecycle → even when the app is closed. 4️⃣ Backbone of offline PWAs, push notifications, & background sync. 🚀 Key takeaway: Web Workers = Performance Service Workers = Offline + Background capabilities 📌 Have you ever faced this question in your system design interview? #Frontend #Interview #frontendinterview #PWA #SystemDesign #WebWorkers #ServiceWorkers #javascript #reactjs #frontendgeek

40

6 коментарів

Flaky tests feel random. They’re not. The patterns are clear: * Timing issues (async workflows, race conditions) * Shared state (bad test isolation, order dependencies) * Environment drift (things that work locally but fail in CI) By definition, though, they’re not obvious to spot. A missing await, an unseeded random number, a fragile assertion. These problems tend to show up after the developer who wrote them has moved on to the next thing, reducing the likelihood that anyone will take time to fix them. AI is going to multiply these issues. It’s *also* going to help us catch them faster. The challenge for leaders: don’t accept flaky tests as inevitable. They’re just tech debt we’ve been too slow to pay down.

43

PSA: if you want to make your software 100x easier to debug, design it with deterministic randomness. Almost every system you build has some form of randomness baked in: • random IDs and UUIDs • shuffling lists of results • load balancing requests That is all fine. But the problem is that it’s hard to get the same "random" behavior to happen again when you spot a bug. The solution is to build your stack with deterministic randomness. Haven’t heard of it? It’s what it sounds like. Most random generators are not fully random, but pseudo-random. Pseudo-random generators (like java.util.Random) are driven off an internal state: • when you ask for a random value, it looks at its internal state • it uses that state to compute the next value and returns it • it advances its internal state • repeat    So when you ask Java's Random object for values and it gives you unpredictable results, it's because Random's *initial state* has been randomly set for you already.      💡 If you want deterministic randomness, just set its initial state yourself. This is called setting the seed. Nothing explains this better than code, so just look at the screenshot and you'll see what I mean. (But if you do this, take care to use deterministic randomness everywhere! Missing it in just one place will break determinism. In my product, I have an entire "random API" that proxies into a deterministic set of functions so I won't mess it up.)

336

58 коментарів

From Developer to CEO Part 03: 5 to 10 years of experience Congratulations, you’re now a senior developer. But you’re not a senior just because you’ve reached 5 years of experience. You’re a senior because you’ve seen more problems— and you know how to prevent them. At this stage, you should be able to build software from A to Z. But your main focus must now shift to business impact. Not just how to code, but how to solve real business problems. Code shouldn’t be your challenge. Code should be your tool—to deliver value. For that, start asking the right questions: • What’s the real problem the customer is trying to solve? • Why does the client need this feature? • What’s the expected benefit for their business? • Is there a better solution? You’re not just a developer anymore. You should become a technical partner to your clients, not just someone who takes orders. Your new mindset: 👉 How can I maximize my customer’s success? If you follow these tips, you’ll level up faster. ⸻ After 20+ years in web development, I’m sharing what I wish I had known when I was younger. This post is a follow-up to Julien Rajerison’s post. Tomorrow, we’ll talk about developers with 10+ years of experience. ⸻ You’ve got this. I’m Toky RABESON. I’m a seasoned web developer.

94

4 коментарі

Heads up, Android devs! 👋 So I just finished diving deep into Android 15's new 16KB page size requirement, and honestly? It's bigger than most people realize. Starting November 1st 2025, if your app targets API 35+ and uses ANY native libraries (your own .so files or ones from SDKs), you're going to need to rebuild them. No exceptions. I'll be real with you - when I first heard about this, I thought great, another compliance hoop to jump through. But after testing it out, I'm actually excited about the performance improvements. We're talking: - Apps launching 30% faster - Camera opens 4-6% quicker - Way less CPU strain - Better battery life The tricky part? Figuring out if you're even affected. Pure Kotlin/Java apps are mostly fine, but if you're using any third-party SDKs, there's a good chance they bundle native code you don't even know about. I spent the last few weeks testing this migration and put together a complete walkthrough - everything from updating your build tools to testing on actual devices. The deadline feels far away, but trust me on this one: don't leave it until October. I've seen too many last-minute scrambles with Android updates. Full guide is in the comments if you want to get ahead of this 📝 Anyone else already started preparing for this? Would love to hear what challenges you're running into. #AndroidDev #Android15 #MobileDevelopment #android

340

21 коментар

QA isn’t just testing anymore: It’s strategy. It’s risk planning. It’s the last gate before code meets the world. In 2025 the question shifts from “Does it break?” to “What happens if it works?” 𝗪𝗶𝘁𝗵 𝗔𝗜 𝗶𝗻 𝗲𝘃𝗲𝗿𝘆 𝗽𝗿𝗼𝗱𝘂𝗰𝘁, 𝗤𝗔 𝗶𝘀 𝗻𝗼𝘁 𝗯𝘂𝗴-𝗹𝗼𝗴𝗴𝗶𝗻𝗴. It’s asking: - Are we testing fairness? - Are we free from bias? - Does the prompt goal match the business goal? Gartner says AI will cut manual QA by 50 %. The job moves upstream ... toward smart guardrails. The winners won’t be top bug hunters. They’ll be risk storytellers: people who stop the wrong success. 3-𝗦𝘁𝗲𝗽 𝗔𝗜-𝗤𝗔 𝗨𝗽𝗴𝗿𝗮𝗱𝗲 (15 𝗺𝗶𝗻) 1. Fairness test an edge prompt. 2. Check AI goal vs KPI. 3. Write a three-line “too good” risk story. Comment QA2025 and I’ll DM the 1-page AI-QA checklist. #DhandheKaFunda: Your QA career won’t die. It evolves if you do.

45

8 коментарів