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.

Reply via email to