Jakub,
I'll be interested to learn how you work this out. I also work with data
whose structure is known to functions in various modules, thus its very
shape is a contract. This is coming from the other end of encapsulating
everything in Java classes and interfaces. Also, I write test cases at a
high level and not really as unit tests, which prevents rewriting test
after a refactoring but will like to know how you handle that too so as to
reduce any rework there or else whether it's worth the maintenance.
Short of a massive refactoring of data and code, maybe writing
data-transform function? Not sure about the proxy concept (is that data?)
but if a function can produce the new format from the old you may start
changing one consumer function at a time; then work on the producers until
you can switch and remove the transform.
On Thursday, May 22, 2014 1:17:52 AM UTC-7, Jakub Holy wrote:
>
> I have a nested data structure, used by a bunch of functions that presume
> knowledge of its structure, and I wonder how to change a part of the
> structure in a safe way, preferably in small incremental steps, rather than
> having my code broken until I update all the functions and tests for the
> new structure. I believe many of you must have experiences with this, would
> you care to share some tips?
>
> The data structure is first built incrementally and the collected data is
> later summarized. Instead of replacing the raw data with their summary, I
> want to keep both, so I want to wrap the data with a map; i.e. from:
> { <id> [ data...] } ;; later replaced with {<id> summary}
> to
> {<id> {:data [data...], :summary ...}
>
> I have a number of functions operating on the structure and tests for
> those functions (with test data that also need to be updated w.r.t. the
> refactoring).
>
> When I change one of the functions to produce the new data structure (i.e.
> data wrapped in a map instead of the data itself), everything else breaks.
> So I fix some tests and another function and get even more failures. This
> does not feel as a good way to do it as I prefer to have limited
> red<http://www.infoq.com/presentations/The-Limited-Red-Society>and am fond of
> parallel
> change<http://theholyjava.wordpress.com/wiki/development/parallel-design-parallel-change/>for
> that reason.
>
> Ideally, I would have an automated refactoring or the possibility to wrap
> the data in some kind of a two-faced proxy that could behave both as a
> vector (towards the old code) or as a map containing the vector (towards
> the updated code) [some thing like lenses/cursor?!]. I haven't either so I
> guess the only option remaining is a well-controlled process of updating
> the structure and code. Any advice?
>
> Thank you! /Jakub
> --
> *Forget software. Strive to make an impact, deliver a valuable change.*
>
> *(**Vær så snill og hjelp meg med å forbedre norsken **min –** skriftlig
> og muntlig. Takk!**)*
>
> Jakub Holy
> Solutions Engineer | +47 966 23 666
> Iterate AS | www.iterate.no
> The Lean Software Development Consultancy
> - http://theholyjava.wordpress.com/ -
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
