IOS app Development stuff: How to choose the right people, specs, and frameworks?

Since doing team leader, the body and authority have changed, so I am not bothered by a specific function, the implementation of an interface, but how to make incremental improvements on the basis of existing code, to create a more appropriate specification and framework, so that members of the group to complete tasks faster and better. A year down, quite a bit of ideas, so wordy a few words about the development of iOS app those things.

the right person

First, make it clear that the right person refers to the construction of a purely technical team. A strong combat effectiveness of the technical team, in the face of a loose, divided into minutes to overturn their original idea of the Product Manager/project manager, and then a good play can not sing out. Spend a few months working overtime to do the project, have not released, directly overturned redo, at this time you have to go downstairs to the ATM machine to see the balance of the card: the balance is enough, clean up to find the next family.

The computer community has a famous saying: All computer-related problems can be solved by adding an additional layer of abstraction. But software development is not the case: the increase in the level (manpower) to a certain extent can speed up the development progress, when a certain threshold after the effect is not so obvious, and even counterproductive. What is needed for a project is often not more members, but an appropriate amount of suitable members.

Each person has different understanding and thinking mode for the program development because of different educational background, background, project experience (technology selection, learning experience, project management). The response is a variety of code styles in business. For example: Some people want to separate all the single functions into classes, while others prefer a large class of voluminous to write thousands of lines. Most of the time I tend to prefer the former, but as I often spit out: it depends. More than just software development, almost everything boils down to a unified problem: What is a degree?

A group of people who are far away from the idea of working together is a very painful thing: a good part of the time is wasted explaining, arguing, and upsetting the frustration and anger that comes with it. The ancient language: The Tao is different, does not compare for the conspiracy. But in the real work can not so with the sex, lack of sufficient power of the elderly, the ability of outstanding technical backbone, energetic but inexperienced newcomers need mutual understanding, learning and running. So most of the entrepreneurial team's technical team because of the concept of similar, often efficient enough, and large companies within the development team will never be able to achieve that efficiency, but also need a corresponding normative and procedural framework.

Another reason for this conclusion is that I am pessimistic about human being's shape: Most people do not have the will, the power and the ability to jump out of the limits of their own thinking. Few people will continue to summarize their learning progress (active learning type) without any outside pressure, while the rest of them are either not willing to pay attention to the completion of the task and get paid, or want to progress and not law. And your team can't all be composed of active learning members, when the introduction of the normative and procedural framework can make all types of people better cooperative.

the right specification

Everyone understands that software development requires appropriate specifications: code specifications, procedural specifications, process specifications, and so on, to reduce the occurrence of surprises: the least surprising principle . But in the actual implementation will encounter a variety of situations, the biggest problem is: how to identify which specifications are required to enforce, those specifications are recommended implementation. The enforcement of the specification results in increased readability and ambiguity of the code, and the downside is obvious: for most of the programmers who have an idea, the rules are too rigid to cause resistance and create unrest. This situation is common in various standard outsourcing companies.

If most of the specifications are set to recommended execution, the specification is easily overlooked without good guidance. There are many code specifications for OBJC on the internet, such as Apple's own specifications and Google objective-c Style Guide. These specifications generally have only two ratings: recommended and not recommended. And I would recommend dividing the code specification into five levels: mandatory, strongly recommended (but not mandatory), good, acceptable and unacceptable. Here are just a few examples to illustrate.

• In accordance with the Apple standard naming method.

• The class name starts with uppercase, and the method and variable names are named after the hump. Strongly demanded, this is nothing to say, the Apple System Class library and most of the third-party open source libraries are the same. But in some Apple's sample also saw the use of M prefixes to denote class member variables, these are the legacy code problems, is still acceptable scope, but their own code inside the use of a similar Hungarian naming law is unacceptable.

• The class name is prefixed with at least three characters, and the internal method prefixes it with two underscores. Highly recommended. The above approach minimizes the duplication of names with the System class library: Because Apple claims to retain the right to use all two-bit prefixes, its internal method names are prefixed with an underscore.

• Whether you use the K&r style or the Allman style is an acceptable range, but it is highly recommended to keep a form within a file.

• Keep the code short and consistent on the basis of the readability of the code: small class, small method, unified function return. Small, small methods make it easier for others to focus on class logic, rather than specifics, while reading, and a unified function return can reduce the difficulty of accidental errors and troubleshooting. It is also important to ensure that the code is short and not verbose, and you will often see the following code: > (Count > 1) {return YES;}  {return NO;} I really can't look straight.

• Good code/Engineering structure

• Create worksapce for the entire project.

• Categorize resource files according to their responsibilities: each type of resource is stored in a separate directory: Pictures, sounds, configuration files, and so on. And the picture can be stored in different subdirectories according to the type: Global type, background map, logo, login and so on.

• A reasonable code structure. Recommend the following project directory structure

Core: Some common mechanism implementation classes in engineering: Unified task management, module management, service management.

General: Common classes and methods, including in-Project Viewcontroller,uitableviewcell base class (base), common category, public UI component (CustomUI), public helper method (Helper ) and the macro definition (Marco).

Model: Common data Models

Sections: Different program units. such as login, settings and so on. It can be divided into sub-directories according to functions: The custom UI component used by the current cell, the management class, the data model and the Viewcontroller, and so on.

Vendors: third-party libraries.

the right framework

A suitable framework is not a silver bullet, and it seems to me that the problem that the framework solves is never: with the framework, the project can go on very correctly. What a good framework can do is simply to reduce the complexity of common problems and reduce the likelihood of errors. Personally think a good iOS app framework should have the following features:

• Define a clear hierarchy.

• Presentation layer (Presentation layer), responsible for managing the UI and Uiviewcontroller

• Logical Layer ( Business/service Layer), responsible for the definition and forwarding of logical data, play a connecting role. The

• Data access layer, which is responsible for specific API constructs, network requests, data persistence, and so on.

• Each layer uses a single-layer or multilayer structure within the complexity of the business logic. Taking data access layer as an example, it can be subdivided into network layer and persistence layer. In general, the presentation layer (UIView and Uiviewcontroller) is presented directly using the model provided by the logic layer, but in some scenarios it is often necessary to have the same interface display for different model (such as our app, the session interface, the collection interface, The question function needs to show the picture, but the model definition under the three modules is not consistent, which requires adding additional viewmodel layers for bonding the presentation layer and the logical model.

• Horizontally, each module is independent of each other and communicates only through a limited number of interfaces. The ideal state is that other modules are pluggable except for the core modules. Vertically, the relationship between the various levels is clear, and there is no reverse dependence. The

• Landscape module generally relies on business requirements and is often defined as a variety of service or manager. A good practice is to have a unified Service manager responsible for the corresponding serivce loading, unloading, monitoring and distributing app-level notifications to the appropriate service, such as front-end switching, receiving memory warnings, and so on. In this way, it is easy to achieve the above-mentioned module pluggable, on the other hand, it also guarantees the consistency of the common characteristics processing. Well done in this respect, all the basic modules are inherited from Mmservice and managed by Mmservicecenter. Of course, the header file from the dump can also find some management disorders, such as some viewcontroller are inherited from the mmservice.

• Vertical Hierarchies There is no big difference between the basic apps, which can generally be divided into three levels:

• Adhere to the solid principles and careful use of various design patterns. This is a cliché topic, is not unique to iOS development, to start talking about a few days and nights, do not repeat.

• Define your own UI base class: Uiview,uiviewcontroller,uitableviewcell. The benefit of this is self-evident, that all sub-View,controller,cell can easily inherit the common behavior of the base class, style. But also will introduce the very big management risk: The group member always can not withstand the temptation to the base class plug various not universal characteristic, causes the base class authority and authority the infinite expansion. The Daji class not only increases the difficulty of the group members ' understanding of the code, but also increases the difficulty of troubleshooting when problems arise. In this respect, the Uiviewcontroller base class design is extremely unsuccessful: Mmuiviewcontroller.

• Provides easy-to-use tool classes. Some easy-to-use tools often become an integral part of the framework, solving local problems quickly and easily without introducing too much complexity. Nstimer's retain cycle is a very easy-to-fall pit, so providing a Nstimer package based on block or weak delegate is a good choice. The use of KVO easy to take place add and remove the unworthy call, then introduce the thobserversandbinders or FB Kvocontorller. When some core modules need to be dependent on multiple modules, introducing XMPP-like gcdmulticastdelegate can be easily decoupled.

• A good example. In the dark days of using C + + in previous years, one of the things I used to think about was how to limit and circumvent some errors at the API level. For example, the task thrown into the thread pool must be the allocated object on the heap, so how to force the incoming pointer to the heap address instead of the stack address? This silly question is largely non-solvable, and sometimes the solution is an unusually awkward one. And now I am more convinced of the possibilities offered by the broken window theory: To do a demonstration, and everything will come to a ripe future.

IOS app Development stuff: How to choose the right people, specs, and frameworks?