Forem: Dattatraya Anarase

Protected Properties and Methods in Swift - An Alternative

Dattatraya Anarase — Tue, 24 Oct 2017 08:59:45 +0000

Originally posted on my blog site.

It's always been a quite demand from swift developers to add protected access in Swift's access control. Lot of times it's been asked on stack-overflow that how to write protected methods in swift. But still swift hasn't provided any direct way to do it. Can we really achieve protected access in Swift? Yes, we can!

Apple has already published a blog Access Control and protected in 2014 regarding this demand and how unnecessary it is. But still I believe there are lot of situations in projects where we need to hide some properties and methods from outside classes but only accessible to children. So here's what I have come up with:

//Animal.swift file
class Animal {
    fileprivate var protectedVar: Int = 0
    fileprivate func protectedFunc() {//do stuff}
}

class Dog: Animal {
    func doSomething() {
        protectedVar = 1
        protectedFunc()
    }
}

If we try to access protectedVar or protectedFunc() from outside of Animal.swift file then compiler will throw an error.
To achieve protected access like this only thing we need to keep in mind that children must be declared in same file as parent declared in. Also this approach can not be used while developing libraries, packages or frameworks.

Have you any time stuck searching for protected access in Swift? Then tell me how you got through it in comments below.
Also if you have any other solutions, please post those here or on Twitter @d4ttatraya.

References: Apple's Developer Guide

Handover Project Using Pair Programming

Dattatraya Anarase — Tue, 26 Sep 2017 19:52:27 +0000

Currently I am handing over my ongoing iOS project to my replacement guy. This is the first time I am handing over my work to any buddy. So I was under little pressure of how can I make sure that he will understand almost every thing I built in this project. I was planning my handover module wise, feature wise, classes wise, etc but I ended up handing over project by pair programming!

This was not at all planned but it happened to be in this way. Two three weeks before arriving replacement guy I stopped implementing new features and started refactoring my code. While refactoring I found that my application code and back end services code was very tightly coupled and that should anyhow be get decoupled. So I started putting interfaces between services and application, using protocols. By the time this guy arrived and I was in the middle of refactoring. Instead of explaining him existing working, coupled code, I continued refactoring the code while this guy was sitting next to me and carefully watching what I was doing.

Then after spending around one week like this he started getting good idea of existing code and new proposed refactoring. Then he started telling me ways to decouple code, and then he started actually refactoring slowly. Then we both started planning refactoring and cleaning code. Now I am sitting next to him and watching him refactoring the existing code; ðŸ˜Š

I think now that he is getting better idea of existing code also and newly re-factored code also. What do you guys think of this approach of handing over projects by pair programming? Please feel free to criticize my approach and leave your opinions and suggestions below; thanks!

Defining Done As Boolean

Dattatraya Anarase — Sun, 10 Sep 2017 09:11:03 +0000

Originally posted on my blog site.

Often in software development environments its been asked to developers whether they are done with their task or not. And its pretty obvious question for managers to ask to developers, nothing wrong or unexpected. Developers tend to answer this question as "yes, I am done" and if anything that can be wrong and unexpected here is what they mean by done!

(Image Courtesy: http://www.quickmeme.com)

What developer mean by done can vary from developer to developer and we can not predict what actually done by him/her. Is done a boolean that clearly means either not at all done or actually finished everything? And again what is mean by 'actually finished everything'? As definition of done varies from person to person, there are always chances of understanding/assumptions gaps between developers' done and managers' done and business persons' done and its consequences can disturb the whole product delivery chain and can attract negative attention towards that developer.

So here I have listed some of the done's in order from totally wrong to almost right:

Just Works

Many times, rather most of the times developers say they are done once they have written a code that just works. So they write code for new feature, run it and see if its working. Is this right definition of done? Of course not. Why? Because code that just works is not approved by clean coders as final code. To know about how code that just works is not perfect solution, have a look at my previous post.

Works and Clean, Unit Tested

So, code that just works is not enough to say that we are done with feature. We should write that code matching standards of existing code and it should be clean; that is readable, testable, modifiable. Also we should add unit tests to make sure that code is working as intended in various test cases. Even if we did this, we are not done to say 'I am done!'

Works and Clean, Unit Tested and Passes Automated Tests

Once we have code that works, code that is clean and code that is unit tested, we have to look for next criteria to get feature done. And that criteria is to pass all the already written automated tests. These automated tests can be integration tests and acceptance tests. Integration tests make sure that newly written code is integrated with existing system correctly and breaks nothing.

Works and Clean, Unit Tested and Passes Automated Tests and QA Approved

Once we have finished all the above steps, still we are not done. What is remaining now? After finishing all the above steps, we should handover working system to QA and wait for his/her feedback, either bugs, modifications or approval. When QA approves our newly implemented feature, then and then only we can say that "I am done!", finally. So now we can say that our done is boolean where not at all done or doesn't work or all above definitions falls under value-0 and only this definition falls under value-1.
As Uncle Bob says-
Done means done, no complete, no done-done.

Bonus

So many times its mentioned that we should always re-factor or clean the existing code, we can add this too in our definition of done. We should not say done until we re-factor(if required) existing code related to our newly written feature.

Every company has their own definition of done, but if any company doesn't then they should get it defined immediately and should ask their employees to follow it.

If you have already defined your own done or have defined it now, then don't forget to put your definition in comments below!

References:
Uncle Bob's Clean Coder Book and Talk About Professionalism

Advantages(!) of Dirty Code

Dattatraya Anarase — Fri, 18 Aug 2017 19:39:51 +0000

Originally posted on my blog site.

First and foremost advantage for me is that I don't need to define it; ðŸ˜Š! Almost everyone, who have written any kind of program, knows what dirty code is; whether or not everyone realizes it is another story.

Internet is flooded with principles, rules, techniques, best practices, how-to steps to write code. And now-a-days almost every programmer is also talking about some kind of techniques to follow while writing code in respective programming languages. While using such techniques in writing code we have to follow lots of rules and best practices. Ultimately it puts many constraints to write code freely, slows us down, makes us fail to achieve time-lines of deliveries, and much more pain than any real programmer can imagine.

Here is high-level summary of side-effect of following such practices:

Takes lot of time to name things
Needs unnecessary separation between modules
Makes us write lot of extra code which never will be in product builds
Not allowing to add comments
Force to make intentional errors first and then solve them Let's get into more details of these side effects and see how painful they are.

Naming Things

Many people around internet talks about giving meaningful names to variables, functions, classes, modules and their necessity. But why it is so necessary? What will happen if you name a variable d instead of numberOfDaysInTrailPeriod?

int d = 10;
int numberOfDaysInTrailPeriod = 10;

No error will be generated by compiler and nothing is going to break runtime either.
Similarly this

int rdsTrail(){//code}
int remainingDaysInTrailPeriod(){//code}

Come on, let's not waste our time thinking appropriate and meaningful names for things.

If we ourselves in future or anyone else is going to work on this code later will debug and understand what int d and what int rdsTrail() stands for.

De-coupling of Modules

This is another most discussed topic under some techniques when writing bigger projects which contains many modules interacting with each other. This is also brought on when writing interfaces for modules. I don't understand what makes them think to hide implementations behind these interfaces? They call it some kind of abstraction.
No one is going to disturb that implementation. Here we are already tired implementing new features and fixing bugs; and why should we go and change others' implementations.
And why should we keep fine separation between modules if they are interacting with each other so intensely and so frequently? We have written modules for our project and our project is useless if we remove any of the modules. Then why think as if we are going to use each module separately and independently.

If in future we need to replace any module then just modify respective code according to new module, or if need to reuse it in any other project just rewrite it.

Unit Tests

Yet another myth of programmers, just to put more and more efforts and time writing simple piece of code which will take no more than a minute. The main purpose of unit testing is to see if our code is working as expected or not, but if there are QAs and testers sitting next to us why should we bother about testing code by ourselves?
Unit testing unnecessarily forces us to split our big good fat functions to smaller chunks. Putting limit to number of lines in functions also puts limit to our speed of writing them. Also why would we always follow the rule of single responsibility and top to bottom flow of functions calls? It's of course going to slow us down.

If anyone wants to test workability of code after making some changes or adding more code then he/she should just have to give program to testers.

Readability

People also says that code should written in a way that not only computers but also humans can understand it. Again, if we tried to follow this rule then we need to waste our time writing code which can easily be understood by another programmers just by reading it. But, simply, if we are having such beautiful and powerful IDEs why programmers need to read code instead of run it and watch output direct.
Another constraint they put here is no more comments in code. All the IDEs support adding comments in code. Instead of trying to make it understandable by just reading code, let's put comments wherever needed to explain. In above example, we can add comment like

int d = 10; //number of days in trail period

There is nothing wrong in this, neither compiler throws error nor compiled build will include these comments.

If we are worrying about understandability of our code by reading, let them understand it by debugging it or by reading console logs or simply by reading comments.

TDD

Now I can use this word, NIGHTMARE! TDD is nothing but a nightmare to all programmers, particularly to one who actually follows it. Make a mistake, correct it; again make another, correct it... How silly is this? And this flow, believe me, creates another parallel program that is bigger than actual program, also takes more than double time. And what purpose this serves is forces us to follow all above rules.
To make even very small modifications we need to first modify respective tests or to add small code we need to first write test. That is we have to think about test first and then implementation; isn't it time consuming?

Instead of let tests drive our development why can't we go straight forward and start without making any errors.

At the end

I would like to argue you about not fall for what people are saying and just ignore following side-features of our code:

Easy to read, understand
Easy to replace modules, algos
Easy to debug and fix bugs
Easy to modify and reuse
Easy to add new features We can think of these whenever it's required in future. So just chill and write a code that just works!

You know what do I mean by this blog post...!!!
(Image Courtesy: rathod.milan053@gmail.com)
If you are on either side of coding, dirty side or whatever the other side, please leave comments and give a ðŸ‘ !

References: Uncle Bob's Clean Code