• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: General development tips
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: General development tips


  • Subject: Re: General development tips
  • From: Chris Hanson <email@hidden>
  • Date: Sun, 5 Nov 2006 20:26:16 -0800

On Nov 5, 2006, at 2:25 PM, David Aames wrote:

But my APIs are getting more in number & more complex with every single day so what are you guys using to help you with the development? Any bug management software (bugzilla, no?), source documenting systems (I haven't found any good Obj-C ones), etc. Thanks for sharing.

Techniques from agile software development "interoperate" very well with Cocoa development, since most of that movement has its roots in the Smalltalk world. (Objective-C is essentially C plus the Smalltalk object system.)


In particular, I've found breaking down the features I'm working on into individual user stories and applying the Planning Game to their estimation and prioritization works very well. An outlining application works well for managing this type of information. On many projects, I'll keep the story collection outline in source control and referenced from the Xcode project itself, marking items complete and moving items around as necessary.

Similarly, test-driven development and unit testing in general work very well with Cocoa development. By applying these techniques, and also rigorously (and religiously) refactoring your code, you can keep your codebase very well-decomposed, which is a huge boon for both understanding it later and making it extensible. Just remember that the mantra of test-driven development is red, green, refactor: Write a unit test whose failure expresses the step you want to take, write the code necessary to make that unit test pass, and then go back and refactor your code to keep the entire codebase clean and free from duplication. Note too that your codebase isn't just the code for your application and/or framework, but the code for your unit tests as well; they need to be kept clean and well-factored just like the rest of your code in order to be extensible with it.

Also, keep in mind that the Cocoa frameworks are built around a number of common design patterns — model-view-controller, target-action and chain of responsibility, delegation, notification and observation, etc. — and structure your code along the same lines. That will keep your cognitive load low as you work with your code, in that the only thing you'll really have to worry about is what's unique about your code, since its interaction with the rest of both your code and the frameworks you're using all follow common patterns.

An example of leveraging the Cocoa design patterns could be in implementing a custom view. Say you want to implement a view to display a hierarchical diagram of some data in your application. One way to do this is to tie your view very tightly to the data it's displaying — even to the point of having the view act as the "container" for that data. However, if you do this, you'll have to remember everything about this code and how it works every time you want to change it. Instead, with probably about the same amount of effort, you could implement your view in such a way that it uses an arbitrary cell to actually draw its data, and it's designed to be bound to an NSTreeController (and/or uses the NSOutlineView data source informal protocol) to obtain the data to display. This may result in a slightly more complex internal design, but it's likely to be both more reusable and easier to maintain because much of what it does goes through standard interfaces. In other words, the only code in the view is the code that makes it unique and the code that hooks it into the rest of Cocoa.

Finally, you can leverage platform technologies as well. For example, if you're creating reusable views and controls, put them in a framework, with their own set of tests. If you're creating reusable model and controller objects, put them in another framework, again with its own set of tests. In this fashion you can keep your different units of work distinct; you're working on your application, you're working on your extended controls framework, you're working on your model & controller framework, you're working on your Cocoa extensions framework, etc. This can really help organize your work.

  -- Chris

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >General development tips (From: David Aames <email@hidden>)

  • Prev by Date: Phone number [:.VIRUS.:]
  • Next by Date: ip addresses and countries
  • Previous by thread: Re: General development tips
  • Next by thread: Re: General development tips
  • Index(es):
    • Date
    • Thread