Evolutionary couplings between files reveal poor software design choices
1–10 of 85 posts
Re: Evolutionary couplings between files reveal poor software design choices
#2This is an amazing approach to making some hard-to-understand aspects of software more visible. This sort of improved information is how software process and tools evolve over time. I look forward to seeing where this project goes.
Re: Evolutionary couplings between files reveal poor software design choices
#3A "correctly layered" app with UI view separate from UI logic separate from server-side logic etc. will show up as coupling, if commits are feature oriented.
There's certainly a hint as to where to look for bad coupling, but expected "coupling", like tests, need to be discounted.
Re: Evolutionary couplings between files reveal poor software design choices
#4I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
Re: Evolutionary couplings between files reveal poor software design choices
#5That looks really interesting, and I'd love to run it on my own projects. I'm curious though, why do you think you need to make it a web service? And why tie it to github? I would like to run it on a local git repository and output the results into a local file. That seems like a good small program.
Re: Evolutionary couplings between files reveal poor software design choices
#6I played around with this a bit in June. This is what I managed to come up with in the time I was interested in it:
Re: Evolutionary couplings between files reveal poor software design choices
#7There was another recent HN post that showed an analysis of IntelliJ's architecture using a source code analyzer [1]. Does anyone have more information on these types of tools? There seems to be a genre of tools that are used to inspect the architecture of a program, and I have no idea where to start learning about them.
Re: Evolutionary couplings between files reveal poor software design choices
#8I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
So does non-TDD. If you're fixing a bug, your tests should test for conditions that trigger that bug.
If you're modifying behavior, you will need to update the tests that break because of that, whether you write tests before or after.
Re: Evolutionary couplings between files reveal poor software design choices
#9I think it is a mistake to think of coupling caused by TDD to be a false positive. What this outlines really is that TDD will force you to edit two files instead of one for many changes. This is a clear indication of how TDD will slow you down.
0. It has nothing to do with TDD
1. It's a tooling artefact, testing systems certainly don't have to mandate split code and tests. Rust's test framework allows tests in the same file as the tested code, the testing guide recommends that unit test live alongside the code they test[0] and the standard library follows this practice[1]. I'm reasonably sure you can also do so in e.g. py.test[2]
2. I'm not convinced editing two files slows you down, most editors and window managers will let you put both files side-by-side and trivially jump between them. Are java developers slowed down by having to jump between files?
[0] http://doc.rust-lang.org/guide-testing.html#the-test-module
[1] https://github.com/rust-lang/rust/blob/4deb27e/src/libcollec...
[2] by marking all python files as "test modules"
Re: Evolutionary couplings between files reveal poor software design choices
#10A "correctly layered" app with UI view separate from UI logic separate from server-side logic etc. will show up as coupling, if commits are feature oriented. There's certainly a hint as to where to look for bad coupling, but expected "coupling", like tests, need to be discounted.
> A "correctly layered" app with UI view separate from UI logic separate from server-side logic etc. will show up as coupling, if commits are feature oriented.
It would show some coupling commits, but e.g. bug fixes should/would be segregated to the relevant files, not spread across the system.