How to work with someone else code?

[Niegodziwy Beru]

Hello. 

TLDR:

I work for company that make lot of software projects, some of them are only for internal use, some of them are only in maintenance mode, most of them are rather big. Sometimes management gets an idea that we need add very important feature to maintained application, because our client really want it. Because maintenance team is very small, and most of developers from this particular project already move to work on something else, management decide that company need to make special force team. They "borrow" few developers from other projects for 3-6 months, to help maintenance team. Projects mostly have unit tests and integration tests, but a lot of them rots, code sometimes looks better, but there is a lot of hidden domain knowledge in abbreviations. There is also specification, but you can't verify what you read, with "old" developers, they don't work here anymore. I trying to follow uncle Bobs advice in project that I already work, or in new code that I create and this work great, but ...

Problem:

How to deal with big code that you don't know, you have limited period of time, no domain knowledge, no one that could help you, no idea how architecture of this software really looks like? Something like you want to work on big open source project (linux kernel, Firefox, Chromium, ...) without internet. You have real documentation = source code, and monkey with software skills.

My current approach (reverse engineering), but with low efficient:

• When I look to the code, and I want to understand it I'm trying not to think about refactoring it.
• Sometime I'm trying to draw what I already know, state machines, design, but at the end I have mess. You always need to add additional arrows or rectangles.
• I wrote script to "decipher" integration tests logs. Sometimes I just want to get messages flow, without looking what content they carry, and it take me to log to analyze tests (hundreds of nested functions).
• I read about specific feature in documentation, and then I look for it in code. All decoded abbreviations I put in spreadsheet. Sometimes code is refactored/more generic, because there is dozen of similar features and these are very difficult moments. Trying understand one feature without understand all of them at once.
• I discuss with people, a lot. Sometimes they have useful tips.

Maybe someone know some books/articles about such reverse engineering problems? Uncle Bob, what do you think about this for you next lesson?

[Per Lundholm]

I second that, sure would be nice to be a lot better at this!

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Caio Fernando Bertoldi Paes de Andrade]

There’s Micheal Feathers’ book “Working Effectively with Legacy Code”, that addresses lots of problems on how to invert dependencies and put legacy code under test. This video made by Sandro Mancuso from LSCC is a good start. It’s in Java, but the principles can be used in any other language.

I start by finding where a small business rule is, for example a tax calculation or some other critical rule, and put it under test, inverting dependencies only when really needed. If you already have some integration tests, that’s great, they will help you know whether you broke anything. IDEs’ automatic refactoring features help a lot in inverting dependencies and allowing you to safely rename abbreviations to the real words.

Hope this helps,

Caio

[Tristan Mills]

Sadly this is never going to be a nice job and the only solution is to ensure the project is left in a reasonable state and kept clean.

The tool I use most often is exploratory testing. I'll branch the codebase and start writing tests to see what the code does. Once its nailed down a bit more I can start refactoring if I need to, or even tweaking bits of code to see what the effect is.

Any abbreviations in naming can easily be changed with modern IDEs (unless the spelling mistake is exposed in the public API and will break clients if you change it - yes I've seen this :( )

I second 'Working Effectively With Legacy Code', it gives lots of tools to help in this sort of situation.

Tristan

[Per Lundholm]

The book on Mikado Method is also to recommend. The toolbelt for Feather's tools. :)

Manning: http://www.manning.com/ellnestam/

/Per

[Dave Schinkel]

Take Caio's advice and get that book. I have it, it ROCKS.  It will help you drastically.

[Dave Schinkel]

"Sadly this is never going to be a nice job and the only solution is to ensure the project is left in a reasonable state and kept clean."

Yup, if you don't have people on your team who are a huge advocate for Craftsmanship (Clean Code, TDD, and the such), life is gonna suck.  Your options?  Stay if you think the organization's appraoch can and might change (either you have a ton of patience and try to help change that or whatever) or else Leave...unless they get off their ass and change their ways.

If you leave, find an XP/TDD shop is my advice.  There are a slew of reasons why I say this.  Those shops are hard to come by but look hard and try very hard to get in them if you have the passion for clean code and not having to pride your work on fixing bugs.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Sebastian Gozin]

Leaving remains a very tricky proposition. I suspect it's something you must be able to take your time with as it's just too hard to tell which gigs are good and which are bad.

[Jakob Holderbaum]

Hi!

On 05/31/2014 11:45 PM, Niegodziwy Beru wrote:
> Hello.
>
> *TLDR:*

> I work for company that make lot of software projects, some of them are
> only for internal use, some of them are only in maintenance mode, most of
> them are rather big. Sometimes management gets an idea that we need add
> very important feature to maintained application, because our client really
> want it. Because maintenance team is very small, and most of developers
> from this particular project already move to work on something else,
> management decide that company need to make special force team. They
> "borrow" few developers from other projects for 3-6 months, to help
> maintenance team. Projects mostly have unit tests and integration tests,
> but a lot of them rots, code sometimes looks better, but there is a lot of
> hidden domain knowledge in abbreviations. There is also specification, but
> you can't verify what you read, with "old" developers, they don't work here
> anymore. I trying to follow uncle Bobs advice in project that I already
> work, or in new code that I create and this work great, but ...
>

> *Problem:*

> How to deal with big code that you don't know, you have limited period of
> time, no domain knowledge, no one that could help you, no idea how
> architecture of this software really looks like? Something like you want to
> work on big open source project (linux kernel, Firefox, Chromium, ...)
> without internet. You have real documentation = source code, and monkey
> with software skills.

At shops I worked with, there were similar rather large applications
like the ones you described, Niegodziwy. Very often even without tests!

> *My current approach (reverse engineering), but with low efficient:*
>
> - When I look to the code, and I want to understand it I'm trying not to
> think about refactoring it.
> - Sometime I'm trying to draw what I already know, state machines,

> design, but at the end I have mess. You always need to add additional
> arrows or rectangles.

> - I wrote script to "decipher" integration tests logs. Sometimes I just

> want to get messages flow, without looking what content they carry, and it
> take me to log to analyze tests (hundreds of nested functions).

> - I read about specific feature in documentation, and then I look for it

> in code. All decoded abbreviations I put in spreadsheet. Sometimes code is
> refactored/more generic, because there is dozen of similar features and
> these are very difficult moments. Trying understand one feature
> without understand all of them at once.

> - I discuss with people, a lot. Sometimes they have useful tips.
>


Very often, as you stated, is it not feasible to refactor such systems
initially, because you first have to struggle with understanding internals.

I do like the approach of writing tests to get a basic understanding of
whats going on, even if there are already tests.

For example, I try to setup a separate acceptance test application which
boots up the application and is able to stimulate and inspect its
barriers (e.g. with Windowlicker or Capybara). Depending on the type of
application, similar aspects like the database or the filesystem can be
observed while executing your stories.

By setting up such a harness, I am able to formulate domain-related
questions in code and let them hit the entire application. These tracing
bullets can give me a basic idea, which concepts the authors had in mind
while specifying and implementing the application.

Additionally, I feel a lot more comfortable in making actual changes
with such an approach. Regression test for free, basically :)

> Maybe someone know some books/articles about such reverse engineering
> problems? Uncle Bob, what do you think about this for you next lesson?
>

Have you read "Working Effectively with Legacy Code" by Michael
Feathers? I think you can find some great value regarding a similar
topic in this book.

Cheers, Jakob

--
Jakob Holderbaum, B.Sc
- Systems Engineer -
phon 0176 637 297 71
mail h...@jakob.io
page http://jakob.io

[Niegodziwy Beru]

Hello,

Thank you Jacob, and all of you for your great answers and tips. I see that, there is no easy solutions to deal with this problem. I thought, about this intensively, and I feel I need some systematic approach. I decide to make in next 2-3 months, some short notes every day (week), with basic daily problem, potential solutions, best solutions (when someone from my team get some brilliant idea or tool) or just unsolved. Next I group them, and maybe I get some conclusion where I need to put more work 

 

 Have you read "Working Effectively with Legacy Code" by Michael 

Feathers? I think you can find some great value regarding a similar
topic in this book.

No I don't read this, but now is on my list to order from amazon. Thanks