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.