139 reputation
5
bio website dougmcdonald.co.uk
location UK
age 31
visits member for 1 year, 11 months
seen Jan 23 at 9:17

.NET Web developer from the South West UK with an outside interest in PHP/MySQL Javascript and anything else which seems fun!


Jan
22
comment Architectural / Application Practices to guard against 'breaking changes'
Yeah the edmx merge is a pain, we tend to use database projects to ensure we can merge more easily and then update the edmx from the db itself. Typically for example I'd do this: 1. Accept the incoming edmx 2. Merge changes in the db project, where it's easier to see changes. 3. Update my local db to bring in the new db changes from the db project. 4. Update the edmx from the db.
Jan
22
revised Architectural / Application Practices to guard against 'breaking changes'
Removed C# tag
Jan
21
awarded  Commentator
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
I can see one way of working, whereby we always make sure everything 'works' but this would quite often add a significant amount of effort to the task. Take a report, during sprint one, we 'make it work' with the changes in order to remain deployable. During sprint two we make it work again with some more changes, and again in sprint 4, 5...20. At this point we've re-written the report many times, when if we had been able to wait until the end, a single re-write would have been possible.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
In a way that the amount of change needed, is not possible to deliver in a single sprint, without breaking related areas of the system. An example would be, by changing the structure of the data storage, the existing data may not be able to be displayed properly or a report no longer works as the underlying data is depend on is too different. Making the report 'work' as part of this sprint may be pointless as during the next sprint, the next change may again change the way the report needs to operate.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Excellent answer: Data - yeah we use EF and wrap repo's (generic first, then typed) Query / Tables - I like the EAV as a concept, but with my DBA hat on I cry a little bit! We have a simplified EAV design going on with this bit of work, and pivoting some things may well help (but would obviously require major rework in queries, and possibly require logic pushed into views etc or quite a lot of complex EF code as we compose the more detailed queries). The system is relatively complex and we have hit the limit on EF a few times and had to end up in SQL directly :( Good advice though, thanks
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Yeah I get what you mean, I think this is more than the collection of stories is the entire workpackage, which could take several months. The code, during this phase would be non-deployable but we have other work during this period on the same project which does need to be deployed. As a result, I'm looking for approaches which could allow parallel development and retain the ability to deploy, during a potentially unstable state for 'some' of the code.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Interesting answer, this sits with my current thinking in that there isn't an easy way to accommodate changes which impact vertically. Annoyingly, although I can divide the changes vertically into stories, the completion of one (or even a collection) of stories, doesn't leave the user in a working state. I'm wondering if the best approach at the moment is to split the changes into 'breaking' and 'non breaking' and incorporate the 'non breaking' into the main development stream, with 'breaking' as it's own arm.
Jan
21
comment Architectural / Application Practices to guard against 'breaking changes'
Yeah I guess that could be true, I think I was thinking that the code itself 'is' (to an extent) maintainable, but are there any ways of managing two parallel versions of code, without impacting on the ability to deploy. One option would be to develop a second version alongside, e.g. via branches. Whereas another option may be to duplicate the code and feature flag one, until the second is complete.
Jan
21
awarded  Student
Jan
21
asked Architectural / Application Practices to guard against 'breaking changes'
Oct
3
comment How does TDD address interaction between objects?
I suppose it would depend on what you mean by TDD. TDD is not limited to unit tests in my book, I see it as a wider discipline regarding writing the expectations of your functionality before you develop it. Whilst in its simplest/purest form it may be unit tests for single classes, I believe it does/should extend to integration tests between groups of classes and functionality. Testing the way individual classes fit together helps route out design issues by noticing when dependencies are difficult to provide or when the inputs and outputs of methods are not easy to provide or validate.
Oct
2
answered How does TDD address interaction between objects?
Jan
30
awarded  Autobiographer
Jan
30
awarded  Supporter
Jan
30
awarded  Teacher
Oct
31
answered How do you proactively guard against errors of omission?