Dr. Dobb's Journal - September 2008 - (Page 28)

d09ryla_p2as 7/14/08 8:39 AM Page 28 Core Technology BUILDING A ROBUST DEVELOPMENT ENVIRONMENT continued from page 26 Even though namespace-based folder structuring can sound appealing to .NET and Java projects, it can get out of control and lead to nesting problems. This is not always the case, as namespaces in either language are meant to span physicality. But without being very careful and having a core team responsible for the structure, complexity can sneak in. There’s usually enough complexity in the actual application design that it’s wise to keep the physical source structure as simple as possible. A flat-folder structure applied itself well to resolve the folder structuring problem. Each project composing the greater website solution received its own renamed project folder and lived adjacent to the other projects, eliminating all project nesting. Now project groupings happen at a logical level instead of the physical folder level, making the structure less brittle; see Figure 1. Perfect Source Structure? Is there a direct connection between how source is structured and how software is designed? No, not in compiled software. When software compiles, this is an indication of its abstraction from the source files. Don’t confuse application architecture with source-code management. It’s possible to achieve your design goals and reuse across products without heading down the path of sharing source code. The usual suspects of binary compatibility, RPC, and web services are answers to this question that do not effect source code nor introduce additional complexity. Don’t make the mistake of trying to create the ultimate source-code repository as a companion to an idealized application architecture. If the history of software development provides any guidance, then one of these is probably a chimera. Ownership of source code is important for its health and maintenance, therefore some group must take ownership. To accomplish this, ensure that all source code is accounted for and part of a team’s roadmap. Avoid getting caught in unrealistic expectations of architecture driven by the source management process. There isn’t a singular application architecture that must be subscribed to. After all, every system is unique and requires tradeoffs for longevity. To move the process forward, it’s essential to help stakeholders understand that there are many scenarios— some better than others—for structuring source. Strive for as good as possible for the reality of your teams. Branching and Continuous Integration Continuous integration (CI) was the initial—and still long-term—goal for build Figure 1: Project groupings. 28 Dr. Dobb’s Journal l www.ddj.com l September 2008 http://www.programmingresearch.com http://www.programmingresearch.com http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - September 2008

Dr. Dobb's Journal - September 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook A Conversation With Erik Demaine Application Lifecycle Management Meets Model-Driven Development Building a Robust Development Environment Real Users Really Matter Matching Wildcards: An Algorithm The Android Mobile Phone Platform Managing Application Thread Use Signalling Integer Overflows in Java .NET Development & the IBM WebSphere Portal Server The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.