Technical Debt

Mijn top 5 van TODO's (in mijn mening foutbronnen)in algemene zin

1 Gebrek aan test van bestaande code. Levert veel code op die meestal werkt maar niet altijd. Maakt schatten en bouwen op bestaande code lastig.
FIX : tester(s) in het team.
2 Gebrek aan encapsulatie van classes (veel members onnodig public), maakt code complex en nodigt uit tot sterk gekoppelde classes. Hier schaat ik ook event bubbling onder omdat dit ook encapsulatie breekt (je exposed je internals).
FIX : mentaliteit wijzigen in private tenzij...ipv public tenzij
3 Singleton references (Habitat.Plugin.Instance.Gui.Apllication.GuiCommandHandler..etc. Maakt code ontestbaar en zorgt er voor dat er verborgen afhankelijkheden zijn.
FIX : niet doen en afhankelijkheden 'injecteren' bij instantie van class.
4 Automagische properties. Properties die veel code voor je doen omdat het handig is. Bijvoorbeeld een add doet veel meer dan alleen Add. Maakt doorgronden lastig omdat veel code side-effects heeft.
FIX : Acties expliciet maken en niet te veel 'clever' code
5 Ambitie bij implementatie iets lager stellen. Kies de simpelste oplossing in eerste instantie. Bij het opstellen van wat er gedaan gaat worden wordt te weinig gekeken naar implementatie mogelijkheid en toegevoegde waarde voor klant (bijvoorbeeld data in Toolbox)
FIX : Lever eerst iets werkends en maakt het dan (eventueel) complexer

Stinky Code:
1 Functions en bijbehorende complexiteit, zou hier en daar simpeler kunnen door wat consessies te doen aan functionaliteit.
2 PropertyChanged aspects. Voegen veel onhelderheid toe.
3 TreeView nodepresenters. Logica is niet afdoende en onhelder.
4 DataItemSet

High level issues

1. Split DeltaShell solution into the following parts:
   • Framework - mainly interfaces, Core + Gui: Plugin, Model, Project, linking data between models, Views, etc. Lightweight!
   • User Interface
   • Common Plugins - project explorer, data access,
   • Common Libraries - mapping, arrays, hydro, netcdf
   • Application Plugins
2. No any immediate changes by the team within framework and common libraries without prior design session!
3. Changes in these components will be coordinated and reviewed by me so that things remain consistent and don't break.
4. Create visual map of all components available in the Delta Shell and dependencies between them
5. Put all tests in order
6. Increase test coverage!
7. Learn how to write unit tests by example, the following topics must be clear to everyone:
   • What is unit test?
   • What is integration test?
   • How (and when, why) to use mocking?
   • Where to put data files used by data access tests?
   • How to test forms and how to minimize necessity to do it?

More issues

• Separate common plugins (maybe merge some of them) and application plugins
• Define convention on where data of the integration tests will be stored.
• Split Integration tests into a few projects (limit dependencies)
• Use WeakEvents in PropertyChanged and CollectionChanged implementations in order to avoid memory leaks
• Use interfaces such as INotifyPropertyChanged explicitly (wait and migrate to PostSharp 2.0?)
• Extend NetCDF import to use custom dimension names for custom types, currently it is hardcoded in FunctionBuilder
• Review and fix HACK and TODO in the code.
• NetCDF must use CF convention while detecting arguments for regular grid coverages, see "coordinates" attribute
• What do we do with NaNs?
• HydroNetwork.HydroNetwork - clean-up namespace names
• Buggy Windows.Forms test hangs on build server due to Drag and Drop BrokenLinearModelViewTest.ShowView
• Parsing and converting using ToString() when writing / reading data from DB stinks - use default NHibernate types
• Names of the tests should be based on name of class, in EXACTLY the same namespace, e.g. WaterFlowModel1DTest.cs, test other more specific tests maybe should have name like WaterFlowModel1D_WithLateralSources.cs, WaterFlowModel1D_WithWeirs.cs. Currently there are situations like: WaterFlowModel1DTest.cs WaterFlowModel1DLateralDataTest.cs WaterFlowModel1DWeirTest.cs
• Don't call integration test classes using only class name ClassXxxTest, but ClassXxxTest for unit tests and ClassXxxIntegrationTest for integration tests
• Don't use 2 categories above the test class ["Integration"] ["DataAccess"], chose one - ["DataAccess"], it is also an integration test but a bit more specific. Specifying 2 categories makes test run 2 times on a build server and locally.
• Fix all memory leaks for integration tests
• Refactor chunking logic to use stride-based approach to calculate chunks, current algorithm is slow
• Use a single way to setup logging in the tests (see http://wiki.deltares.nl/display/TOOLS/2010/01/21/log4net+configuration)
• MOVE DelftShell.Plugins.NetCDF.Filters in tests - there is no implementation of Filters in NetCDF plugin
• Rename IFolderItem to IEntity and move it to DelftTools.Utils
• WindowsFormsTestHelper is a MESSSSS! Refactor it.
• Extract utility methods from ModelBase to extension methods
• Refactor IDataItem, IDataItemSet in IModel, IDataProcessingActivity to work on top of properties so that model won't know anything about data items.
• Better implementation of DDD principles (presentation about DDD, maybe invite external experts)

• Make the following script work (as a user I want to run the following macro):

# create simple network containing 3 nodes and 2 branches
network = HydroNetwork(Name = "test network")

node1 = HydroNode(Name = "node1")
node2 = HydroNode(Name = "node2")
node3 = HydroNode(Name = "node3")

channel1 = Channel(Name = "channel 1", Source = node1, Target = node2)
channel2 = Channel(Name = "channel 2", Source = node2, Target = node3)

# add nodes to the network
network.Nodes.Add(node1)
network.Nodes.Add(node2)
network.Nodes.Add(node3)

# add channels to the network
network.Branches.Add(channel1)
network.Branches.Add(channel2)

# add network to the project
CurrentProject.RootFolder.Add(network)

• • Script should look simple.
  • If Branch, Node implement INetworkFeature, where Network is set?
  • How node1.IncomingBranches property works?

During start up of DeltaShell many errors are thrown. This is bad because:

• It probably slows down start up time significantly
• It makes it impossible to spot important exceptions
  We should eliminate these exceptions