When things come to mess, we have to think about how to modularization. The benefit of modularization is pretty good, especially when we’re working on a huge project or building things in long term. Those are includes:
- We can dedicated team working in parallel independently with project.
- Can be re-used on other projects.
- Can be maintenance.
- Easy to testable and measure.
I’m preferring for open source module where we can share whole code to use. For whom expected to privately your code, I prefer to use private repository where only member has rights to access.
- Class scope: There are two type of class scopes:
- Module accessible: It could only be access through your module. For Swift, you don’t need to put public before class. Ideally for some part of module like utilities we don’t want to public it yet for use. Just keep private
- Outside accessible: It could be access for outside and inside module. Those are the classes where we define public methods to invoke. For Objective C, we put in *.h file, for Swift, we define as public prefix. - Variables and methods scope: Be sure that only define public functions/variables for the one that you would like to public. To be more effect, it’s better to do in section and space. Where on top we define public variables and methods, bellow we define private functions and variables(for Swift). Or in header file for public methods/variables and implement file for private methods/variables (for Objective C). To be testable, we will need to set expected output for public functions and variables only.
- Measure your code with Unit Testing and report: When we create a module, please also create a Unit test project (target) as well where we could put the. The expected is to prepare to test all public functions. The outcome of this is to making a code coverage page where we could share the output as html page how many functions has been tested and how many test cases provided. This will convince that you module is in high quality and good to use.
- Document your code: In terms of module re-usable we have to document your module. Especially in case other developers will use and he would know the meaning of functions, input and output, etc. So, document your public classes/functions/variables are quite important. It’s even better that you could also document your private method where you hide the logic of implementation in case later on someone would improve and maintenance.
- How to make your module work for both Swift and Objective C: We’re prefer to use Swift to making module. However, for some of projects still in Objective C. And we probably consider to support both. So, ideally Objective C has a main class than NSObject which is the root class. So, every classes or functions would use in Objective C, please put @objc at prefix of class or function. Or, inherit from NSObject.
Conclusion: Above points that even done by me, but for someones it might not better enough. Also there might be other points that not mentioned above but worth to use. So, be considered those are references and your feedback are appreciated welcome.
