The importance of algorithms and data structures (hereinafter referred to as algorithms because of their association) to programmers has long been a subject of debate. Some programmers have a natural rejection of the algorithm, once the algorithm knowledge is investigated in the interview, it will be laughed at by many programmers, but some companies have been insisting on this practice. As an iOS programmer, LET me give you a little perspective.

Not knowing algorithms is not a barrier to being an iOS programmer, but rather the relationship between knowing algorithms and being a good programmer. In my view, the two are an inadequate but necessary link. At least a modest knowledge of algorithms is a prerequisite for being a good programmer, including iOS programmers. Its importance can be summarized in the following three aspects:

  • Algorithmic considerations are rare when it comes to writing iOS code, but when it comes to specific algorithmic issues, not having an algorithmic foundation can be an insurmountable obstacle.
  • Algorithms help foster “programmer” thinking, or “computer” thinking. This way of thinking and habit is important in finding solutions to programming problems, bringing us closer to the truth of the program.
  • Algorithms exercise brain power and get into the habit of asking questions.

I have to admit that algorithms are not something you fall in love with on first encounter. I spent a lot of time from the initial meeting with the algorithm to the establishment of the basic algorithm knowledge system, from entry to give up and then entry again.

When writing code, you will encounter algorithm-related problems from time to time, but they may be selectively ignored or avoided. I can give two simple examples:

Example 1: Check the changes in the address book and upload the information to the server

In order to detect the changes in the address book of iOS system, every time we receive the change notice, we need to enroll the correspondence in Device and compare it with the address book in Database to confirm whether there are any new changes. Some students will write the following codes:

for (MyContact* deviceContact in deviceContacts) { BOOL exists = false; for (MyContact* dbContact in dbContacts) { if ([deviceContact isEqual:dbContact] == true) { exists = true; } } if (exists == false) { [dbContacts addObject:deviceContact]; }}Copy the code

Assuming the device has 1000+ address book records (not uncommon), these two layers of for are 1,000,000 cycles, inadvertently creating a performance problem hole, and if you know how to calculate time complexity and know the hash table, you can write better code for this scenario. The problem of unordered sets, ordered sets, hash table query elements is the foundation of the algorithm. The time complexity of hash table query elements is one of my frequent interview questions.

Example 2: The use of indexes in database table building

Some programmers have never heard what an index is, and some have learned from their predecessors that an index can speed up queries but have little understanding of the principles behind it. Therefore, it is necessary to master the theoretical knowledge behind these common techniques to make rational use of them. For example, why don’t we index every field in the table? Understanding that an index is a quick query through “new table” and “B+ tree” will help you understand the advantages and disadvantages of this tool. Index is also one of the must-ask questions in my interview.

Algorithms are also a great way to exercise your brain power. In my previous post, THERE is a Tip to keep your brain active each day: solve a small problem in the morning before you get to work. Algorithm problem is a good choice, algorithms are more independent and targeted. QuickSort, for example, rearranges your thoughts in your spare time, or even types them out in code. It’s like doing push-ups every night.

Algorithm quicksort(A, lo, hi) is if lo < hi then P := partition(A, lo, P -- 1) Quicksort (A, p + 1) hi) algorithm partition(A, lo, Considerations hi) is Pivot := A[HI] I := LO // place for CONSIDERATIONS J := LO to HI -- 1 do if A[J] ≤ PIVOT then swap A[I] with A[J] I := i + 1 swap A[i] with A[hi] return iCopy the code

Although there are only 14 lines, can you see the solution at a glance? The partition function, in particular, describes a neat idea in just seven lines of code, which is part of the programmer’s fun.