Tracking change and innovation in the enterprise software development community
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Create REST
-enabled Web Apps
with Project Zero
from IBM.
Rule your SOA
with CentraSite
standards-based
registry/repository
Plan-driven dev
Environments and
Agile tutorials at the
Better Software
Conference & Expo!
Introducing the
SpringSource
Application Platform:
Next-gen Java
AppServer
In this interview from OOPSLA 2007, Michael Stal talks about architecture refactoring. He describes what architecture refactoring is, its relationship to code refactoring and patterns, and he gives real world examples of how architecture refactorings have been done and when not to do it.
After asserting that one must, as a rule, always version their database work, Scott Allen detailed an approach to making the best of versioning databases. Allen presented a comprehensive, practical approach to creating a baseline, using change scripts to manage schematic revisions, controlling programmatic database objects, and handling branching and merging.
Steve Yegge touched a nerve in the development community when he argued that keeping the code size to an absolute minimum is the most important thing when developing software. In his view, you may have to sacrifice some design patterns and avoid refactoring at times just to keep the lines of code down. And if your problem is large enough - you may have to switch to another programming language.
Patrick Smacchia is a Visual C# MVP with over 15 years of software development experience. He is the author of Practical .NET 2 and C# 2, books about the .NET platform. He has worked on software in a variety of fields including the stock exchange at Société Générale and a satellite base station at Alcatel. He's currently the lead developer of the tool NDepend.
Can refactoring and unit testing really create robust “working software” that survives the real world? In this story adapted from his book Release It! Michael Nygard contends that "abstractions leak": we need to attend to architecture, even in Agile projects, to guard ourselves against the 5AM failures that occur when foundational abstractions misbehave.
Debate sprang up at JAOO '07 around Bob Martin's assertion that "nowadays it is irresponsible for a developer to ship a line of code he has not executed in a unit test." In this InfoQ video, he debated with Jim Coplien on this and other topics, including Design by Contract vs. TDD and how much up-front architecture is needed to keep a system consistent with the business domain model.
Ramnivas Laddad talks about domain aspects, how aspects fit in the design phase, how to model aspects in UML, how to enforce policies with Aspects, how he used Aspects to diagnose production problems including touch threading problems, and using aspects to simplify design pattern implementation.
Many people assume that agile methods mean an absence of design. Design still happens in agile projects, but it shifts from an up-front phase to a continual evolution. Design decisions should be left to the last responsible moment, but some design decisions do need to be made at the start of a project. Martin Fowler explores this topic through a panel discussion of design in an agile context.
Bob Martin of Object Mentor presents the first of his five principles of agile design. Beginning with an explanation of the real purpose of object-oriented design - the management of dependencies - Bob walks through a code example to illustrate how dependencies can be managed with abstractions, and that good designs are those in which high-level abstractions do not depend on low-level details.
