We usually hear and see stun people saying ” This guy really knows everything about IT, he can code in any language!!!”. may be such a guy can develop a durable software. really?
To be able to code with a range of technologies such as java, php, nodejs, Ruby, Python, Objective C, C#, etc… can be really very good as long as you master most of them since this will spare you from sticking on one technology that you need to adapt on any requirement even when the nature of the technology itself is against the requirements. However an over appetite of knowing multiple programming technology can be devastating to one’s ability to master any of them. This is something you need to consider whenever you feel like you need to play around a new technology. Knowing new things can be good as long as you know how to make a choice that embraces what you already have rather than conflicting with your livelihood .
Anyway have a list of technologies on your CV does not guarantee a long lasting software. As I stated in the title , my post today is about an overlooked secret to become a complete application developer. Have you wondered why you can develop an application, everyone is happy about it, it ranks 5 stars, but one year later the reviews looks really very different. the key word for your reviews change from “Amazing” to “Rubbish” ?!
If you ever have had this question in your mind, then think about the following steps may be your apps will keep the “Amazing” label for years.
Take time to understand the requirements for the application before you start coding any single word.
Rather than focusing on presentation, think about datafiles. how is you data going to be stored? How is it going to grow in terms of size for a given period? if it comes that your database’s tables are bigger; let’s say more than 30 millions of entries, will your database queries be able to fetch within 3 to 5 sec utmost. if not then don’t disregard the next steps
Think carefully about table indexes. depending on the nature of your data, choose adequate indexes. one of the biggest mistake is just to create an index without knowing which one to create and you end up using B-Tree indexes for every scenario. I some scenarios a Bitmap index plays well. Another big mistake about indexes occurs when you create indexes on a table that has data that are constantly deleted without a permanent index rebuild. This is actually what happens when a data is deleted: its orphans indexes are kept in the index table simply linked to a file number that does not exist. as a result the index table keep growing and reach level 4 very quickly. If you think you are going to delete much of your data, then plan how you can have an automatic mechanism of rebuilding your indexes on a regular basis.
Think about table partitioning. if your data is going to be big, think on a way you can partition those tables with big data. Partitioning addresses key issues in supporting very large tables and indexes by letting you decompose them into smaller and more manageable pieces called partitions. SQL queries and DML statements do not need to be modified in order to access partitioned tables. Think about what partition you need, is it a range one? list ? Hash or Composite one? the answer to these question will save you from the “Rubbish” label.
Last but not least, assume you have done all the above mentioned but still your data keep growing and your app is now nothing but slow. Your probably need to think about indexes partitioning. sometimes a table of data can be easy to navigate(I avoid to say scan as the word ‘scan’ means something else in a database language) but it takes time for the right index to be found. partitioning the indexes table into small portions of tables will make sure that the engine will find the index as quick as possible.
I hope these few lines will help.