As Martin Fowler point in his book “Refactoring”:
Refactoring is a controlled technique for improving the design of an existing code base. Its essence is applying a series of small behavior-preserving transformations. [..]
So refactoring is about improving existing code but without changing its behaviour, by small transformations.
For example, this could be refactoring activities:
Refactoring aims to create more readable and understandable code without introducing any behaviour changes. We shouldn’t call activities like:
I don’t want to elaborate on is singletons are good, bad, useful, helps solve some problems or introduce ones. I would like to focus on how they affect code testability.
Code that heavily relies on singletons is commonly considered untestable. It’s very hard to verify our assumptions or fakes input data when we cannot use test double.
But this kind of code can be easily refactored in few steps to allow testability.
Imagine our application can generate some kind of report. To do it application makes a network request. The amount of data is quite big, so this operation can…
When I started to write unit tests for my code main metrics for me was code coverage. I was proud because Xcode prints almost 100% coverage for all my classes— but sadly QA team starts ping me with tickets for my part of application and I was like “What? I have unit tests for that!” — But I haven’t. I did test one happy path and thats all. Code coverage prints 100% for this method and I assume it is enough.
I did add new test method which cover bug pointed by QA, refactor my code and run tests again…
If we target our application in more wide range than our country, it is good to localize application to be understandable by users. Very good habit is localize application in your native language and at least in English.
Making localizations in iOS application can be little tricky.
Old days to localize interface file (xib or storyboard), xCode create clone of that file with in *language-code*.proj.
We have exact the same file, where we can change properties on UI components like labels, buttons, etc.
One plus of this approach is that, we can define entirely different UI for different countries.
In almost every app there comes time when we have to make some formatting. Some time we need to convert
Bool into readable string, more often
Date object into text literal which will be understandable to people who use our application, not saying about rounding numbers to two spaces after coma/dot sign (depending of country or OS settings) or placing separator between thousandths parts of number.
Apple come across this requirements and create sets of formatters which we can consume in our applications. Intension of Apple developer was creating very clear API, which witch will be country independent but also…
Some times we need some configuration at build level. To present something for one client and hide for other. In Swift projects we have Swift Compiler — Other Flags where we can define flags (by adding line with
-D prefix like:
-DOUR_FLAG in build configuration).
Moreover we are restricted to check if flag was defined or not only. We can’t read value from there.
If we have application splitted over frameworks we have to define ours Other Flags in each framework which using them.
Let’s say we have product which is shipped to five clients. Each of them have different…
Sometimes we need to know how long our code is executing. Mostly for debug purposes. If we have that knowledge, we can perform some steps to optimize algorithms or find bottlenecks in our code.
In some language aspect oriented programming (AOP) can solve our problem in some aspects, but Swift is limping in that concept (… for now?).
While I’m developing my application, I can find lot of places where I put some code to calculate how long my methods are executing. …