DEV Community: Michał Cichoń

Effective Code Reviews: Habits That Make Teams Stronger

Michał Cichoń — Mon, 15 Dec 2025 09:43:35 +0000

A healthy code review culture can transform a team. It improves code quality, spreads knowledge, and helps developers grow. But good code reviews don’t just happen. They come from habits, collaboration, and curiosity. Today I would like to share a few practical guidelines that can make your team’s review process smoother, more meaningful, and far more effective.

Don’t Be Afraid to Ask Questions

One of the biggest misconceptions about code review is that you’re expected to know everything. In reality, questions are often the most valuable part of a review. Ask questions whenever something isn’t clear. If a piece of logic seems surprising or if you’re not sure why a particular pattern was chosen, it's always better to ask a question then simply move on silently.

Questions help you understand the change, push the author to clarify, and sometimes reveal areas where the code or documentation could be improved. Curiosity strengthens the team more than silent approval ever could.

Prioritize Code Reviews Over Your Own Tasks

We all want to get things done. That's why it’s always tempting to rather focus on your own work than your peer's. In reality, tasks waiting for code review are closer to being finished than the tasks you’re just starting and they usually should have higher priority.

By prioritizing code reviews, you help keep the development pipeline flowing. Your peer can merge their work, move forward, and unblock other parts of the system. It’s a small shift in priority that dramatically increases team throughput.

I think it's really important to keep in mind. When we stop reviewing our peers code, we simply end up with a high pile or pull requests waiting for being merged. It usually leads to more merge conflicts, more stress just before the release, and more headaches.

Use a Checklist to Stay Consistent

Even experienced developers miss things. That's why a checklist can help ensure consistency and reduces mental load. A good review checklist might include things like:

Are there unit tests for the new or changed functionality?
Does the code follow the project’s style guide?
Are there potential race conditions or concurrency issues?
Is caching used correctly, or could it cause stale data or memory bloat?
Are there strong reference cycles?
Are all new strings localized properly? Maybe some strings are still missing? Did we make sure someone from Product/Marketing will take care of it?
Maybe we have more external dependencies in our team we should keep in mind before we go live with the new changes?
Are accessibility identifiers added where needed?

A checklist makes the review process thorough without being overwhelming. Usually it makes sense to share a short checklist with the team and adopt it as a regular step in your development process. But nothing stops you from having your own, more detailed list if you like so.

Keep Pull Requests Small

Huge pull requests are stressful. Both to write and to review. They slow everything down and make it hard to spot issues. Reviewing bigger pull request takes more time, and it's way more challenging from the start.

Whenever possible, work iteratively. Break larger tasks into smaller PRs: setup, core logic, UI layer, tests, cleanup, etc. Small PRs are easier to understand, faster to review, and far less likely to introduce bugs.

When we work on feature branches, and we see the feature we're working on is simply too big for a single pull request, it might make sense to open a base branch where we point our iterations. Then when the whole feature is done under the base feature branch (so we merged Part 1 and Part 2), we can create a new combined pull request pointing develop.

develop
   |
   +--- XYZ-123-My-New-Feature-Base
         |
         +--- XYZ-123-My-New-Feature-Part-1
         |
         +--- XYZ-123-My-New-Feature-Part-2

Avoid “LGTM” Without Any Comments

Sometimes a PR really does look perfect. But adding only a “Looks Good To Me” comment can feel impersonal and unhelpful.

Instead, highlight something you genuinely liked: a clean abstraction, a thoughtful test, a well-documented function.

Positive feedback matters. It reinforces good patterns, encourages craftsmanship, and makes code reviews feel like collaboration rather than gatekeeping.

Be Curious

If you’re not sure where to start with a review, that’s okay. Use your checklist. Ask the author to walk you through the changes. Start with the high-level overview, and then go deeper.

Curiosity creates learning opportunities. Code review is one of the best ways to grow your skills because it exposes you to patterns, ideas, and solutions you wouldn’t encounter on your own. Being curious is not a weakness but actually it’s one of the strongest habits you can develop as an engineer.

Final Thoughts

Code review isn’t just about finding bugs. It’s about building a culture of clarity, collaboration, and continuous improvement.

By asking questions, keeping PRs small, using a checklist, giving meaningful feedback, and supporting one another your team can turn the review process into a powerful engine for quality and growth.

Strong code reviews make strong teams. And strong teams ship better software.

This article was originally published on my blog: https://michalcichon.github.io/software-development/2025/12/12/effective-code-reviews-habits-that-make-teams-stronger.html

If you enjoyed this post, check out my other articles on software development, teamwork, and best practices for building better code.

Dependency injection patterns in Swift

Michał Cichoń — Wed, 26 Nov 2025 10:52:00 +0000

One of the most useful patterns in software development — and one that is available in many languages, not just Swift — is dependency injection. When I first learned about it over a decade ago, I started using it everywhere possible. It’s a simple idea with a surprisingly big impact. Here’s why it’s worth mastering.

Why is it so useful?

One of the biggest advantages of using dependency injection is that it makes our code immediately more testable. Even in projects full of singletons, we can break apart large chunks of tightly coupled code into smaller, more loosely coupled components. Our implementations rely more on protocols (interfaces) rather than concrete classes, making it easier to swap or replace them.

By depending on abstractions rather than concrete implementations, each component can focus solely on its own responsibilities, without knowing the details of how other parts of the system are managed. This makes it easier to reuse components across different parts of an app. We can easily replace services with mocks during testing or switch implementations when requirements change.

A basic example of how to use initializer-based dependency injection

Imagine that we use in our ViewModel, a couple of services which are singletons. Instead of referencing them directly in the method definition like this:

func makeUserHappy() {
    let currentUser = UserService.shared.currentUser
    PremiumService.shared.grantSuperPowers(to: currentUser)
    AdService.shared.removeAds()
}

We can move references outside of the method:

class ExampleViewModel {
    private let userService = UserService.shared
    private let premiumService = PremiumService.shared
    private let adService = AdService.shared

    func makeUserHappy() {
        let currentUser = userService.currentUser
        premiumService.grantSuperPowers(to: currentUser)
        adService.removeAds()
    }
}

The next step of moving it away would be to pass these references to the initializer:

class ExampleViewModel {
    private let userService: UserService
    private let premiumService: PremiumService
    private let adService: AdService

    init(userService: UserService = .shared, 
         premiumService: PremiumService = .shared,
         adService: AdService = .shared) {
            self.userService = userService
            self.premiumService = premiumService
            self.adService = adService
    }

    func makeUserHappy() {
        let currentUser = userService.currentUser
        premiumService.grantSuperPowers(to: currentUser)
        adService.removeAds()
    }
}

It’s already looks much better. Now we can create mock variants of these classes for our tests using inheritance like this:

class MockUser: UserService {
    override var currentUser: String {
        User(id: -1, name: "Bob")
    }
}

class MockPremiumService: PremiumService {
    private var superUsers: [Users]
    override func grantSuperPowers(to: User) {
        user.powers.append(.premiumPowers)
        superUsers.append(user)
    }
}

Inheritance can help us replace the implementation of exposed service methods, but the rest of the underlying logic remains the same. This can lead to serious side effects, especially if the internal logic of our service classes is complex. A much better approach is to rely on protocol conformance instead of concrete classes in our ViewModel.

Taking this into consideration, we can end up with something like this:

class ExampleViewModel {
    private let userService: UserServiceProtocol
    private let premiumService: PremiumServiceProtocol
    private let adService: AdServiceProtocol

    init(userService: UserServiceProtocol = UserService.shared, 
         premiumService: PremiumServiceProtocol = PremiumService.shared,
         adService: AdServiceProtocol = AdService.shared) {
            self.userService = userService
            self.premiumService = premiumService
            self.adService = adService
    }

    func makeUserHappy() {
        let currentUser = userService.currentUser
        premiumService.grantSuperPowers(to: currentUser)
        adService.removeAds()
    }
}

Then we can implement MockUserService and the real UserService independently, without needing to mix parts of the real service into the mock — which is exactly what tends to happen when relying on inheritance.


// Protocols

protocol UserServiceProtocol {
    var currentUser: User { get }
    func fetchUserData() async
}

protocol PremiumServiceProtocol {
    func grantSuperPowers(to user: User)
    func purchase(_ product: Product)
}

// Real implementations

class UserService: UserServiceProtocol {

    var currentUser: User {
        persistence.currentUser
    }

    func fetchUserData() async {
        if let user: User = try? await network.request("/user/me") {
            persistence.saveUser(user)
        }
    }
}

class PremiumService: PremiumServiceProtocol {

    func grantSuperPowers(to user: User) {
        var updated = user
        updated.isPremium = true
        database.saveUser(updated)
    }

    func purchase(_ product: Product) async throws {
        try await storeKit.startPurchase(productId: product.id)
    }
}

// Mock implementations

class MockUserService: UserServiceProtocol {

    var currentUser: User = User(id: "test-id", name: "TestUser", isPremium: false)
    var fetchUserDataCalled = false

    func fetchUserData() async {
        fetchUserDataCalled = true
        // Instant predictable mock result
        currentUser = User(id: "mock-123", name: "MockUser", isPremium: true)
    }
}

class MockPremiumService: PremiumServiceProtocol {
    var grantedUsers: [User] = []
    var purchasedProducts: [Product] = []

    func grantSuperPowers(to user: User) {
        grantedUsers.append(user)
    }

    func purchase(_ product: Product) {
        purchasedProducts.append(product)
    }
}

What we have here is called initializer-based dependency injection because we pass our dependencies through the initializer. In my opinion, it’s the best basic way to implement dependency injection for iOS applications. It’s a simple concept that anyone can learn quickly. It offers excellent testability: all dependencies are injected at object creation, so tests can consistently provide mocks or stubs. There’s no risk of uninitialized dependencies, which makes tests more reliable.

It’s also characterized by strong modularity. Components are fully decoupled from concrete implementations, and each dependency is clearly defined in the initializer, making it easy to swap implementations.

However, there are several other ways to handle dependency injection, which I will briefly explain in the next sections.

Property injection

class ExampleViewModel {

    // Dependencies are optional until injected
    var userService: UserServiceProtocol!
    var premiumService: PremiumServiceProtocol!
    var adService: AdServiceProtocol!

    func makeUserHappy() {
        let currentUser = userService.currentUser
        premiumService.grantSuperPowers(to: currentUser)
        adService.removeAds()
    }
}

// Somewhere else 
let vm = ExampleViewModel()
vm.userService = UserService.shared
vm.premiumService = PremiumService.shared
vm.adService = AdService.shared

This kind of dependency injection is usually seen in views containing IBOutlets, or in cases where we depend on view components that need to be initialized first. It’s more flexible because we don’t have to pass dependencies through the initializer—the injection timing is more flexible. However, this comes at a cost: there’s a risk of calling dependencies before they are injected, which can crash the app. It’s also harder to enforce correctness. That’s why I prefer the initializer-based dependency injection described in the previous section.

It can be handy for testing, as we can easily swap dependencies after object creation, but it’s also easier to break and make our tests flaky.

It’s not optimal in terms of modularity because objects rely on external code to inject dependencies before use. The contract of required dependencies is less explicit, making it easier to misuse the component.

In my opinion, code clarity can also suffer because readers of our source code must track when and where dependencies are injected.

Method injection

class ExampleViewModel {
    func makeUserHappy(
        userService: UserServiceProtocol,
        premiumService: PremiumServiceProtocol,
        adService: AdServiceProtocol
    ) {
        let currentUser = userService.currentUser
        premiumService.grantSuperPowers(to: currentUser)
        adService.removeAds()
    }
}

// Usage:
let vm = ExampleViewModel()
vm.makeUserHappy(
    userService: UserService.shared,
    premiumService: PremiumService.shared,
    adService: AdService.shared
)

This kind of dependency injection is more functional. We don’t need to store our dependencies as properties, and it’s also easy to test methods implemented this way. On the other hand, calling these methods can become quite verbose. It’s also not very optimal if we want to call the method from many different places. In that case, the problem of keeping everything consistent is simply delegated elsewhere, and we still need to manage it somewhere.

It’s very testable. Each method call receives its dependencies explicitly, making it easy to test in isolation. However, it may take some extra effort to setup dependencies in our tests.

In terms of modularity, we also can find a strong advantage of this approach. Objects don’t need to store dependencies as properties, reducing hidden state. But on the other hand, it can become cumbersome if multiple methods need the same dependencies repeatedly.

Summary

There are three basic approaches to dependency injection in Swift. What do you think about these approaches? Do you use dependency injection in your projects? Or maybe you use a dependency injection framework—if so, what do you think about these lightweight approaches?

Regardless of the approach you choose, the key is to make your code more modular, testable, and maintainable. Even lightweight dependency injection can significantly improve the architecture of your Swift projects without adding unnecessary complexity. Experiment with different techniques and see which one fits your team and project style best.

👉 This post was originally published on my blog: https://michalcichon.github.io/software-development/2025/11/25/dependency-injection-patterns-in-swift.html where you can find more articles like this one. 🙂

Overengineered vs Underengineered Code: Finding the Balance

Michał Cichoń — Sat, 11 Oct 2025 21:48:00 +0000

We start with a simple idea — just a few lines of code. A few weeks later, someone adds a new feature, and suddenly that “temporary” solution you wrote on a Friday evening has become a critical dependency. Sounds familiar?

So next time, you try to make it better — adding layers, abstractions, interfaces, dependency injection, and tests. The code now feels future-proof… until no one can understand it, or Product comes up with a new feature that makes the whole structure pointless.

There’s a moment in every developer’s career when you realize that both too little and too much engineering hurt a project just the same — only in different ways. Welcome to the never-ending dance between underengineering and overengineering.

Don’t try to foresee too much

We all want a future-proof codebase, but in reality every codebase has an expiration date. iOS is a great example: when Apple introduced Swift, many of us were excited—and also asked, why? We already had Xcode, Objective-C, simulators, Instruments—why did we need anything else? Suddenly there was a new language, and we faced the prospect of fewer and fewer developers comfortable with Objective-C while sitting on a huge Objective-C codebase.

Requirements change, goals change, and standards evolve, so pieces inevitably get rewritten. Large platforms show this clearly: the Linux kernel, for instance, has replaced or refactored much of its early code over the years as it has grown. The lesson: build for the near-term horizon, and be ready to evolve.

But don’t block yourself

Like in chess, good coding requires strategy. At first glance, “too complex” and “too simple” code seem like opposites, but if we accept change as inevitable, what really matters isn’t complexity — it’s adaptability. Adding a new feature should require as few modifications as possible and shouldn’t break existing contracts. And if we do make a mistake and need to rewrite a component, it’s far better when the code is simple, with minimal dependencies and layers.

That’s why it’s usually better to start simple, but with room to change and evolve. For example, if we need to add a flag to our API that identifies a user as a moderator, it often makes more sense to introduce a more flexible parameter like roles (a collection) instead of a plain boolean is_moderator. Then, if we need to support additional roles in the future, we can simply add new ones instead of cluttering the API with more boolean flags.

If we design our code to be more extensible, we might only need to write a small “plugin” or a new class that reuses existing components, without worrying that the entire codebase becomes more complex. It’s already complex because we’ve pulled that complexity forward—we’ve extracted it from the future code we’re now implementing.

Think about contracts

One of the best ways to make a system more maintainable is to think in terms of APIs and contracts.
When you start working on a complex feature, the first question should be: how will this code be used in the existing codebase? That mindset can simplify a lot from the very beginning.

I remember when I was a junior full-stack developer (Java + JavaScript) working in a team of more experienced engineers. I was tasked with building a date-range component for a banking application. I assumed I could reuse as much code as possible, so I looked at the existing date picker and created an abstraction that could handle a date range instead of a single date.

The result was not great:

The implementation was scattered across multiple files instead of being self-contained.
The new component was complex to use — we had to create two independent date fields and then manually bind them through my abstraction layer.

Apart from that, integrating my code into the dashboard turned out to be a nightmare:

<div class="dateButtons">
    <span buttons-radio
        model="dateRange"
        options="dateRanges">
    </span>
    <button 
        ng-class='{active: highlighted}'
        date-range-picker 
        highlighted='customDateHighlighted'
        date-range="customDateRange"><img src="" />
    </button>
</div>

One of my senior colleagues suggested a complete rewrite and came up with this simple Angular API:

<div date-range-selector="dateRange" date-ranges="dateRanges"></div>

I was surprised that the internal implementation didn’t reuse the existing date field at all — it was actually much simpler than mine.
That experience taught me that reuse isn’t always the best choice, but thinking about how others will use your code always is.

Be pragmatic

Once, I was involved in developing an iOS banking application. We had a really nice API for creating forms, mainly used for transfers. The API was well thought out and required very little effort to build a new form. I don’t remember the exact code, but it looked something like this (though at that time it was written in Objective-C):

var internalTransferForm = FormBuilder()

let firstNameField = FormField(name: "first_name", type: .string)
let lastNameField  = FormField(name: "last_name", type: .string)
let ibanField = FormField("iban", type: .iban)

internalTransferForm.addFields([firstNameField, lastNameField, ibanField])

view.addSubview(internalTransferForm)

It worked almost magically, handling things like signing, validation, and submission under the hood.
Or at least — it did, until we had to add a field that wasn’t sent to the backend or signed at all, but still needed to behave like a regular form field on the client side.

We struggled for a few days with that new requirement, considering whether to add a boolean flag to our FormField definition that would mark fields as nonSendable or clientOnly, and then extend our coordinator to handle that new parameter. But that approach would have required changes in many places across the codebase.

Then one of the junior developers suggested that we could simply use the UITableView API directly and add the field there — after all, our Form was essentially a UITableView under the hood. We gave it a try, and it worked perfectly.

In the end, we never needed another field like that again, so extending our entire FormField abstraction for this single case would have been a poor decision. Sometimes, the pragmatic shortcut really is the right one.

Keep it DRY, but not super DRY

“Don’t repeat yourself” is a wonderful principle. In a perfect world, we’d anticipate every future use case, and our code would be perfectly composed into small, reusable components — with no duplication at all.

I’ve seen too many codebases that ignore this rule, and the result is always the same: a nightmare to change anything. When we try to add new logic in one place, we suddenly have to update it everywhere.

The real problem appears when we notice that we need to add that new logic in places A, B, and C — but not in D. That’s when we realize something isn’t quite right.

But we can also easily go too far in the other direction. Imagine we have two entities — let’s say two DTOs — that looked identical at the time we implemented them, so we decided to extract their common fields into a parent class.

A few weeks (or months) later, it turns out that the relationship between them was only illusory. By then, we’ve written a lot of new code that depends on this false inheritance. Now we not only have to split these DTOs again, but also rewrite much of the code that was built on top of that mistaken relationship.

Recently, I discovered a similar issue in the codebase I work on. A struct named ApiError, conforming to Error, was actually a REST API response type that also conformed to Decodable. It was being reused as an error type. Inside that struct, you could find both fields coming from the backend and additional fields used for internal error handling. As more and more cases had to be considered, we kept adding new fields to something that was supposed to be just a simple DTO.

Fortunately, we caught it early — before too much dependent code was written outside of our networking layer.

Final thought

Finding the balance between the simplest implementation and something overly engineered can be challenging. We all aim to build future-proof codebases, but it’s hard to truly foresee the future. What we can always do, though, is ask ourselves a few simple questions: Can I explain this code to someone in five minutes? Is the API easy to extend? How easily could this code adapt to a constantly evolving environment?

We should never feel unhappy about what we push to our repositories. If something requires cutting corners due to time constraints, we should at least ensure that what we add is easy to reverse — something we can later replace with a more durable implementation.

There’s nothing more persistent than a temporary solution but if we stay aware of it, document it, and design for change, it doesn’t have to haunt us forever. Good engineering isn’t about avoiding compromises. It’s about making them consciously.

If you enjoyed this post, you can find more of my writing on my blog:

👉 https://michalcichon.github.io/blog/

From Crypto Mining to Folding@Home: Using GPU Power for Something Good

Michał Cichoń — Wed, 08 Oct 2025 14:52:09 +0000

We often talk about how powerful our GPUs are — how many teraflops, how many frames per second. But have you ever wondered what else they could do besides mining crypto or running LLMs?

A few weeks ago, I decided to explore a different path — using that same computing power for something that might actually help science. This led me to Folding@Home, a distributed research project that turns idle PCs into part of one of the world’s largest supercomputers.

Here’s what I learned about ethical computing, personal responsibility, and the surprising impact of donating a few spare GPU cycles.

👉 Read the full story on my blog: http://michalcichon.github.io/technology/2025/10/08/ethical-computing-cryptocurrencies-ai-protein-folding-at-home.html

🤖 Vibe-coding a simple game with ChatGPT, Claude, and Gemini — who did it best?

Michał Cichoń — Thu, 02 Oct 2025 18:19:41 +0000

Take a look at my new article — this time, I’m vibe-coding a simple game with ChatGPT, Claude, and Gemini.

The idea was simple: I wanted to see how far I could go without writing a single line of code myself. I described what I wanted, pointed out the issues, and let the models do the heavy lifting.

The results? Some hilarious failures, some surprising wins — and a lot of insight into how these models actually think when tasked with a small but complete project.

💡 In the post, you’ll see:

How each model approached the same problem
What kind of mistakes they made
How close they got to a working game
Screenshots and examples of the generated code

👉 Read the full article here:

https://michalcichon.github.io/programming/2025/10/01/game-vibecoded-in-chatgpt-gemini-and-claude.html

Take a look at my new article — this time, I’m vibe-coding a simple game with ChatGPT, Claude, and Gemini. https://michalcichon.github.io/programming/2025/10/01/game-vibecoded-in-chatgpt-gemini-and-claude.html

Michał Cichoń — Thu, 02 Oct 2025 18:11:06 +0000

How I Vibe-Coded a Game Using ChatGPT, Claude and Gemini | Michał Cichoń · iOS Software Engineer

Coding without actually writing any code sounds tempting. In this article, I tested the capabilities of three popular LLMs: ChatGPT 5, Claude (Sonnet 4.5), and Gemini (2.5 Pro).

michalcichon.github.io