After reaching the enemy's point: iOS developers spent three months in Google

The following is the main content of Chris Hulbert's article: As an iOS developer, I recently terminated my contract with Google (sysydney). My job is to develop Google Maps Coordinate applications. Before I forget this experience, I would like to share some experiences with you. However, because the time is not long, there will be no major news. When I heard this message from iOS developers who work at Google, the first response was "iOS? At Google? Isn't this like working on the enemy's front ?" Yes, you won't see an iPhone at Google, except for the iOS team's testing machine. Everyone loves their Android phone. I guess this is because they get a free Nexus phone every year. Since I left before Christmas this year, I don't know what they got this year. People there have some anti-iOS emotions, and you will often hear them make fun of Objectiv-C's strange syntax or Apple's other defects (such as maps )...... On the other hand, there are actually more iOS developers in Google than you think. If you want to, you can do a career there. Google has a very good small internal Community. If you are in Mountain View City (Google headquarters), you need to make good applications, but sysydney does not have that high requirement. However, if you are an iOS developer very close to mountain view, it is not far from cubitino. What is the workflow in the workflow? Each person has a task list, and each task has branches. After your task is completed, you can submit the code for review, if "Readability" or "Owner" is recognized, the code is accepted. Readability is an internal authentication passed by the relevant language, while the Owner indicates that the code is recognized on a specific source branch. The best case is that your code is recognized and can be further developed. However, the most common situation is that your code always has such errors or style violations and needs to be modified. Reviewers will give comments in the comment system, pointing out the points to be modified. Google has strict requirements on the Code style. For example, small details such as incorrect spaces or the number of rows that are less than 80 characters away will be corrected. In addition, reviewers have also corrected many basic principles for incorrect operations or provided better language organization suggestions. One advantage of this kind of work method is that the code can be written better, but the cost is high, and there are also some disadvantages-resulting in slow working process. You have finished your work and submitted for review. It is likely that your code will be reviewed immediately after work. If you want to modify the code at this time, you will wait until the review is completed the next day, the comments can be modified only after feedback, and then submitted for review. Sometimes a reviewer goes out for a meeting and has no time to review your new code. I have never heard of any code that can pass the review within a week. If your work is continuous and divided into stages A and B, you have to wait for A to pass the review permit before you can start B's work. This takes A lot of time. Therefore, I staggered my work. For example, after I submitted job A, I went to another job without any contact with job A. After job A passed the job A, I went on to perform Job B. Generally, I have 3 to 4 different jobs submitted for review. The highest record is 6 jobs. My work style saves time, but it is very laborious because it is difficult for a person to draw energy from this task to another unrelated task. Although this kind of workflow is a bit frustrating, the cost of good Google Code is more and more slow developers, and I have no better suggestions for this cost. As an iOS developer, I am used to the "design first" principle. First, some people design applications, and then UX (User Experience) staff make wireframes, then the designer simulates what they want and finally submits it to our developers. This design looks good. The user experience staff knows how to create a better user interface, while the designer knows how to make the application more feasible. However, Google does not seem to be very concerned with design, and a poor android UI is a good description. In general, I had a good experience working at Google (sysydney), and I got a lot fatter during that time. The only thing I regret is that, due to uncontrollable family factors, the contract had to be terminated in advance. Csdn update: iPhone development is worth mentioning that there are several interesting aspects in developing iOS applications on Google: 1. If you cannot merge it, you will not be able to use it. Have the merge conflicts on xib files been solved? Neither have I. Therefore, xib is not allowed. This is my appetite-I have never liked xib or story board, and these are all junk. 2. The pbxproj file will have a merge conflict, so it will not be checked into the source control. Google uses GYP, which is an open-source tool developed by them and has very good results. Unfortunately, GYP has very few documents and cannot execute configurations for certain projects (for example, per-file-fno-objc-arc ). 3. test coverage is very important. Google's metrics are above 90%. We use the CoverStory tool to detect this metric. Both unit testing (SenTest encapsulated by Google) and integration testing (using KIF) are indispensable, but only unit testing is included in coverage. 4. instance variables are sorted in alphabetical order in the header file. Therefore, dealloc also performs this operation, making it easier to check for memory leaks. But I think they started using ARC in all the new projects, at least that's what I was behind ...... It seems like a big project ......