Reddit Reddit reviews Working Effectively with Legacy Code

We found 121 Reddit comments about Working Effectively with Legacy Code. Here are the top ones, ranked by their Reddit score.

Computers & Technology
Books
Computer Programming
Software Design, Testing & Engineering
Software Development
Working Effectively with Legacy Code
Prentice Hall
Check price on Amazon

121 Reddit comments about Working Effectively with Legacy Code:

u/_a9o_ · 188 pointsr/cscareerquestions

Refactoring: Improving the design of existing code

Design Patterns

Working Effectively with legacy code

Clean Code

How to be a programmer

Then there are language specific books which are really good. I think if you read the above, slowly over time, you'll be in a great place. Don't think you need to read them all before you start.

u/Nezteb · 43 pointsr/compsci

Some book recommendations:

u/xiongchiamiov · 39 pointsr/webdev

I've been in a somewhat similar situation. First off, tell your boss that the deadlines aren't happening. They're trying to get all three points of the project management triangle, and it's not going to work. They need to compromise on something. While they're figuring that out, let's get to work.

Step one, if you haven't done this already, is to check everything into version control. You can't do anything about the past, but you can fix the future.

Working Effectively with Legacy Code is a well-reviewed book. Maybe you'll find it more useful than I did - ask your boss to buy it for you. My summary of it is:

  1. Write tests for as much as you can without changing anything.
  2. Refactor a tad to open up more testing opportunities.
  3. Repeat.

    You need a working test environment. The one the customer calls production is ideal (for you), but if that's not going to work, you need something as close to it as possible. It is management's job to solve this problem for you so you can do your job. Tell them that you're working with the 4-hr feedback window, and the more time they take to fix that, the longer this is going to take.

    You mention that there's no documentation, and that you've read thousands of lines of code but still don't understand how it's pieced together. As you read the code, write the documentation. Be as extensive as you can. This is also a good time to write tests that verify the behavior you think is supposed to happen. And don't just read a file at a time, top to bottom - approach it always with a purpose, eg "how does this page get generated?". This will help you understand the flow, because you'll be tracing it repeatedly, so you'll start to see patterns in how it's all put together.

    May the Force be with you.
u/stevewedig · 28 pointsr/programming

Probably start by reading Michael Feather's book about this: Working effectively with legacy code.

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/

u/ryanpeden · 28 pointsr/webdev

I've been here a few times in my decade-long career.

To start, this isn't something that only happens to junior developers. Trying to approach a large existing code base can be a real challenge, even when you have lots of experience.

You're not going to understand the whole application in a day. Probably not even in a week, and probably not even in a month. On some large code bases, I've regularly run into new code *years* after I first started working on the application.

What I've found helpful is to pick a small part of the application; preferably one that's related to a feature you're trying to add or a bug you're trying to fix. Find what looks like the entry point of that small part of the application. In a web app, it could be a method in a controller class. Or it could be a method in a service class somewhere.

Once you've found that entry point, read through the code one line at a time, and try to make sure you understand what's happening at each point. If the method you're in calls another method/function, jump to that and go through it one line at a time. On code that's particularly complex, I'll grab some sheets of lined paper, and devote one sheet to each method I go through.

As I go through each method, I'll write out the whole thing by hand as pseudocode. In order to do this, I have to understand what the code is doing. Some people might find it more effective to do this in a text editor. I find that there's something about the process of physically writing it out on paper that really helps cement my understanding.

Now, the whole writing out part isn't worth it if you just need to go in and do a quick bug fix. But if you've been handed responsibility for a chunk of code and you'll need to understand it deeply, I've found it to be a useful approach. I think it can still be helpful even if you're not solely responsible for a piece of code, but will have to work on it heavily.

Start by deeply understanding one important part of the code. Then move on to understanding another important part. Soon, you'll start to see patterns and understand how these important bits of code fit together.

If you're not yet sure what the important parts of the code for you to understand are, then a good way to find out would be to look at the repository's commit history to see which files have the most commits over time. The places that change the most often are likely the ones *you* are going to have to change, so they are a good place to begin. You can find instructions on how to do this here:

https://stackoverflow.com/questions/5669621/git-find-out-which-files-have-had-the-most-commits

That assuming your code is in a Git repository. If you team uses Mercurial, you can look up instructions on how to do the same thing. If your team uses Subversion or heck, even CVS, you can probably accomplish the same thing. If your team doesn't use source control at all, then start spiking your morning coffee with rum or Kahlua because that will make your job significantly less painful.

For a look at using Git commit history to find the most important code - and the parts with the most technical debt - I enjoyed a book called Software Design X-Rays.

I've found the book Working Effectively with Legacy Code to be quite helpful in showing me different ways to approach an existing code base. Even if you don't apply all of the techniques the book suggests, I think it's still useful for finding out ways to find 'seams' in the code that you can use as points of attack when refactoring, adding features, or even just choosing a place to start learning a new bit of code.

If your employer will let you expense the cost of eBooks, you might find these interesting. If you can get access to Safari Books Online, both these books are available on there, along with a metric ton of great software development books. You might not need to pay for it - in my city, everyone with a public library account can access Safari for free. Maybe it's similar where you are?

Also, if you have a particularly frustrating day, feel free to come on Reddit and send me a DM. I might just have some useful advice. And if I don't happen to have useful advice on a particularly topic, I'll at least be able to come up with an on-topic smartass remark that will help you laugh and feel better about the code that frustrated you.

u/zck · 20 pointsr/cscareerquestions

Get the book Working Effectively with Legacy Code. It's entirely how to deal with this situation, and might be better titled as How to Test Untestable Code.

Basically, the advice is this: get the system under test NOW, then you can make changes. If there's anything you need to change, try to get it unit tested. Whenever you break something, before you fix it, write a unit test.

Slowly, the system will become better. You'll still have a lot of hair-raising problems, but each time you add a test, you'll be more confident, because you'll know that some things still work.

The problem here will be if the professor cares enough to give you time to make any changes that aren't adding new functionality.

u/keyofdminor · 18 pointsr/java

A classic text for this situation is Working Effectively with Legacy Code by Michael Feathers. Legacy code is a different ball-game than relatively clean code-bases, and has its own set of strategies. As it happens, there is a timely episode of the SE Radio podcast as well.

u/daronjay · 18 pointsr/PHP

Working Effectively with Legacy Code

Might be a good place to start. Don't rebuild in one hit, isolate functionality, wrap with tests and abstraction layer, rebuild one component at a time

u/sintos-compa · 13 pointsr/programming
u/frenchst · 12 pointsr/cscareerquestions

Three CS fundamental books in the order I'd suggest someone read them if they don't have a background in CS.

u/sh0rug0ru · 11 pointsr/programming

In Michael Feather's Working Effectively With Legacy Code, he recommends a technique of refactoring for understanding. Clean up the code as you try to understand it, extracting methods, renaming variables, etc. You don't have to commit the changes, but the act of refactoring might just foster better understanding.

u/schaueho · 11 pointsr/programming

/me suggests reading Working effectively with legacy code which helps by providing more tools for proactive handling of "legacy issues".

u/kotojo · 10 pointsr/IAmA

I'm just two months into my first real job for programming and have a few books I've been going through.

Clean Code is a book not just about writing code, but good code that is easily maintained and passed down to other people to understand.

Working Effectively with Legacy Code was a great read coming into company that has been around for 20 years and is on the third iteration of their product.

I am doing web development so You don't know JS, Javascript: the good parts and then Javascript The Definitive Guide have all been a great help.

If you aren't much a book person, Pluralsight.com is awesome for info on tons of different technologies and is well worth the monthly cost. Go follow every major name in your preferred technologies on twitter. They will tweet all sorts of cool things to learn about. Also, PODCASTS!!!. I don't even listen to music anymore. If I'm in the car alone I'll be listening to Dot Net Rocks or Javascript Jabber.

Lastly, there are subreddits for every tech imaginable. Go subscribe to them and hit everyone up for where they get all their info!

u/karptonite · 10 pointsr/laravel

I don't think Laravel is the right direction to be going, honestly. Laravel is great for starting new projects, but it isn't so great if you want it to be just a small part of a larger site.

I suggest you check out the following two books:

Working Effectively with Legacy Code

Modernizing Legacy Applications In PHP

I've read the first one, and can definitely recommend it. The second I haven't read, but it sounds like it may actually be more appropriate to your actual situation, since the first book often assumed that your starting code base is better than what you seem to have.

u/martoo · 9 pointsr/programming

Smalltalk Best Practice Patterns by Kent Beck. In my opinion, it's his best book. It's a great book on the nitty gritty of coding.. great for all programmers. It's easy to read even if you're not a Smalltalker; all you have to do is google for a Smalltalk cheatsheet.

I also like Working Effectively with Legacy Code. It's about the sort of code that most of us confront daily: how to deal with its problems, and get it under test so that you can refactor it or add to it without gumming it up.

u/Whoopska · 9 pointsr/Python

I think Working Effectively with Legacy Code is the classical book on the subject. My personal recommendation is to write a test for every piece of code you read. It doesn't have to be a perfect test, but giving yourself something that will keep your understanding tied to the code and which you can pdb through if you lose understanding will be really helpful. At a certain point, you have to say screw the side-effects and construct a large numpy array and pass that in, create some files in weird places, or inline some text to make it work. Take the time to do things the right way and they'll go faster.

u/throwaway540999221 · 9 pointsr/cscareerquestions

Here's a book recommendation: Working Effectively with Legacy Code

u/tuckerg00dd0g · 9 pointsr/programming

Sounds like a good case to harness this legacy codebase in a unit test framework.

See Working Effectively with Legacy Code.

u/logan_capaldo · 8 pointsr/programming

Martin Fowler did not write Working Effectively with Legacy Code, this guy did.

u/MoonShadeOsu · 8 pointsr/ProgrammerHumor

Sounds like you need this.

Good luck!

u/fesor · 8 pointsr/PHP
u/Orangy_Tang · 8 pointsr/cpp_questions
  1. Automated builds / repeatable builds.
  2. Automated testing of new version output vs. old version output when given identical input.
  3. https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/
u/Hawk_Irontusk · 8 pointsr/iOSProgramming

You should read Working Effectively with Legacy Code by Michael Feathers. It's a fantastic book and will help you avoid the classic mistakes.

u/gbacon · 8 pointsr/programming

An excerpt from Working Effectively with Legacy Code by Michael Feathers:

> Unit tests run fast. If they don't, they aren't unit tests.
>
> Other kinds of tests often masquerade as unit tests. A test is not a unit test if:
>
> 1. It talks to a database.
>
> 2. It communicates across a network.
>
> 3. It touches the filesystem.
>
> 4. You have to do special things to your environment (such as editing configuration files) to run it.
>
> Tests that do these things aren't bad. Often they are worth writing, and you generally will write them in unit test harnesses. However, it is important to be able to separate them from true unit tests so that you can keep a set of tests that you can run fast whenever you make changes.

u/dAnjou · 8 pointsr/django

Simply start by writing tests for each HTTP endpoint and check the content of the response.

Maybe check out Michael Feathers' Working Effectively with Legacy Code too.

u/Butter_sc0tch · 7 pointsr/learnprogramming


Senior dev here who is on the other side of things. One way to approach these situations is to try and approach the problem more from the business case. I’m not sure of your work culture, but you should be bought in as to why a deliverable is time sensitive and what there is to gain by delivering this week vs a week or two later. If people don’t have reasons, they need to be held more accountable for the longer term delivery. Tech debt is a slow killer. You’d be surprised with how much you can push back:
How is this feature being measured?
What is success criteria?
What are the next steps if successful? If unsuccessful?
What are we not doing in order to do this task? Is this the most impactful thing we can spend our time on?

Also, understand that any system is due for a rewrite every 4 years or so. No matter how clean you write, you’ll eventually have to refactor anyway. You defiantly want to maintain something workable, but keep in mind there is no such thing as a permanent solution.

And finally, Great book ok how to make small iterative improvements as you go.
Working Effectively with Legacy Code https://www.amazon.ca/dp/0131177052/ref=cm_sw_r_cp_api_i_Td0QDbFQKYV3T

u/rockyrainy · 7 pointsr/cscareerquestions

I am not a great coder, but I had to deal with this bs in the past.

Find where the data structures are, figure out the layout then focus on the transformation. Legacy code usually has some core logic (10%) and a whole bunch of one off hacks bolted on (90%).

Buy this book.
http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

Financially plan for getting fired tomorrow. Save money, don't get locked into long term rental/mortgage. Reduce your debt burden if you have one.

u/Scarface74 · 7 pointsr/cscareerquestions

Yes. But it’s a great paying skill. There are techniques for working with legacy code.

This is the go to book for it.
https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/carols10cents · 7 pointsr/cscareerquestions

I highly recommend the book Working Effectively with Legacy Code by Michael Feathers. It has a bunch of practical tips for just this situation.

u/bodiam · 7 pointsr/programming

I believe this is a pretty good book for legacy / maintenance systems:

https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/izut · 6 pointsr/programming

There's a pretty good book that touches the refactoring as learning tool subject: Working effectively with legacy code.

u/ibsulon · 6 pointsr/webdev

Don't rewrite from Scratch: Joel Spolsky goes into detail as to why. Instead, rescue the existing code

I cannot recommend Working Effectively with Legacy Code enough in cases like yours. If done right, you can reach architecture without an end state.

The new way to do this is microservices. If you can properly consolidate your javascript in one place, you can start to break apart the monolith. It's absolutely possible to do in place, and you always have a product.

u/jb2386 · 6 pointsr/PHP

Full rewrite in 1 go is the worst thing you can do. Doing it part by part will allow you to do it better.

Check this out of you haven't already: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/erreur · 6 pointsr/programming
u/qscedd · 6 pointsr/epicsystems

> Another thing I want to know is which programming languages/tools I should read up on. In my experience I've pretty much only used Java, Git and some basic HTML/CSS and Javascript. I know this is largely dependent on which team I end up on, but I might as well read up on something in the few weeks between graduation and my start date (early July).

AFAIK, we only use Java for the Android versions of our mobile products (MyChart for mobile; and Haiku). Most of our applications use HTML/CSS/JS, though, with use of these technologies increasing as we move away from VB6.

We do not use Git; instead, we use SVN. Maybe spend an hour learning how SVN differs from Git, if you'd like. But a lot of our SVN workflows have an extra layer of automation and hand-holding on top, so realistically, a deep knowledge of SVN isn't particularly useful or necessary for most developers.

I assume you've heard we use VB6 and M. Our internal training materials for these languages is superior to anything you'll find outside Epic. Don't bother hunting through an antique books store for tomes on either of them.

If you're bored and want to learn some job-relevant stuff, consider the following:

  • C# and ASP.NET. You'll very likely be trained in C# during your first month or two here, but it doesn't hurt to have a head start. You'll also be trained in the framework that we implement on top of ASP.NET. You never really learn about the ASP.NET layer directly, which is a bit unfortunate; I think it would be good for you to do some reading about that.
  • TypeScript. We'll have started switching over from JS to TypeScript by the time you get here. You may not understand how awesome this is. Trust me: it's mindblowingly awesome. TypeScript alleviates the pain of development for the web browser in a way that almost no other language/framework does (you have to start getting into esoterica like Emscripten to do any better than TypeScript, and then you start running into impedance mismatch issues).
  • Learn how to think from a testing-first point of view. I estimate that less than 1% of our code is covered by some kind of automated test (a unit test, an integration test, whatever). This is part of why we have such an enormous QA division (not that QA is entirely replaceable by automated tests, obviously). I don't recommend learning any particular framework (we have internal resources for the frameworks we use). Just learn how to write testable code; how to write good tests; how to develop with testability in mind; etc. Genuine test-driven development is not really feasible for most of the projects I've looked at, but even small steps in the direction of testability help.
  • Related to the previous point, learn how to deal with legacy code. This is not a skill you are likely to have fresh out of college, but it is a skill you will need in most software companies, and especially at old ones like Epic. The standard tome on this is "Working Effectively with Legacy Code". If you can find a cheap copy, I recommend buying it and skimming it. You probably won't really get it until you actually start working with our code, but better to be prepared than not.
  • Find a spiritual guru and have him teach you how to attain inner peace. This will help you not rip your eyeballs out every time you have to deal with VB6.

    > I guess my main concern here is that I just want to know if I should expect to be putting in 60 hour weeks.

    I have never worked a 60-hour week at Epic (unless you count time spent sitting in airports / on airplanes as part of the workweek, in which case I've worked one 60-hour week). My typical week is 35-45 hours (which, granted, is on the low end; 40-50 is more typical).
u/anlutro · 6 pointsr/PHP

If the codebase is anywhere larger than a few tens of thousands of lines of code, a complete rewrite is absolutely out of the question. Any book that talks about working with legacy code will tell you this.

To get started, start with the small tasks. Fix code styling, make it readable without making changes. Break small pieces of functionality into classes with static methods (this makes it easier to navigate and reason about than regular functions).

If you can set up a testing suite somehow (it'll probably be easiest writing acceptance/functional/system tests than unit tests), that will give you confidence to make changes and check that everything still works.

There are good books on working with legacy code out there. Here are two off the top of my head:

u/antisarcasm · 5 pointsr/programming

What you're saying doesn't make sense. Amazon has had a rating/review system for a very long time. You can access them here. As you can see, the reviews are overall very good and it is probably a good idea to purchase this.

u/Blatherard_Osmo · 5 pointsr/webdev

You should take a look at the book "Working Effectively with Legacy Code" by Michael Feathers, which is on exactly this topic. It's about ten years old at this point but still the best.

Here's an amazon link http://www.amazon.com/gp/aw/d/0131177052?pc_redir=1413174357&robot_redir=1

u/Tangurena · 5 pointsr/cscareerquestions

> I absolutely HATE having to go through someone else's confusing uncommented code and figure out what the hell is going on so I can fix some bug. I hate having hours go by where I have nothing external to show for it, even though I have been running a mental marathon trying to figure out what the problem is with the code in front of me.

This is called "maintenance" and is what everyone has to do. If it kills you, then I think you will have a short career in this field. Learn some management skills and get your student loans paid off as soon as possible. Eat ramen and ride a bike in order to do so. If you hate maintenance and " the same boring financial application for a month straight" as much as you say, it will be a race between paying off your loans and quitting the field totally.

You aren't going to remember what you wrote 6 months ago, nor why you wrote it that way. So you are one of the people whose code you will be maintaining. Learn to write meaningful comments because the person you might be saving hours of wrestling with "why did this idiot write it this way" is going to be yourself. The company I work for produces boring financial applications and several of them have been shipping to customers every year for over 20 years. Migrating from one source control system to another almost always loses all the check-in comments, so all we have is the code and the historical changes.

There are 3 books that I think you ought to read:
Brownfield Application Development in .Net is aimed at the .NET stack, but I think is applicable to any framework.

Working Effectively with Legacy Code is about how to approach "legacy code" (whatever you're maintaining) in order to fix bugs and add new features.

The Passionate Programmer is about focusing on your career and how to make it through many of life's hurdles.


Take a look at the reading list I posted on another forum. Many of the books are about how to approach your career and other people in the field.

I've been a programmer for almost 20 years.

u/dendeigh · 5 pointsr/PHP

Not particular to php, this is a book about refactoring legacy code in general https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

There are a few chapters about how to get legacy code under tests before refactoring. Some methods unfortunately cannot be applied to php (e.g. php core functions cannot be overriden), but still, I found it pretty useful overall.

u/localheinz · 4 pointsr/PHP

Rather simple, but still effective: The Way of Testivus by Alberto Savoia.

Probably very useful, once published: PHPUnit Explained by Sebastian Bergmann.

As already suggested by u/RobertTroll, the books by Chris Hartjes - they got me started testing, would buy again.

Also, Working Effectively with Legacy Code by Michael Feathers.

u/donnfelker · 4 pointsr/androiddev

Craig Russell talks about this in his latest lesson on Caster.IO - https://caster.io/lessons/mockito-what-makes-a-good-unit-test/

TLDR; If you don't set yourself up properly in a statically typed language like Java you can be in for a world of hurt when you try to test in isolation. There are ways to get there, and if you're in one of those "Oh my god, this thing is impossible to test" situations go pick up a copy of Michael Feathers book - "Working Effectively with Legacy Code". That book will walk you through what you need to do.

Still not convinced? Just look at the chapter names in the book. That was enough to sell me on it over a decade ago when I first bought it. I still have it as one of my most highly recommended books out there. It's that good.

u/illithoid · 4 pointsr/salesforce

I'll be honest with you, I don't think Head First Java would be a good choice, however DO READ Clean Code. I also suggest Design Patterns: Elements of Reusable Object-Oriented Software and Working Effectively with Legacy Code. The first is a classic MUST READ for anyone in software development. It present numerous challenges that most of us will face when developing solutions, and gives you the design patterns you will need to solve them. The second is great for learning how to fix your predecessors shitty code, you'll need this one. If you haven't already, look up Bob Buzzard and Andy Fawcett. These two guys are my favorite SFDC Dev Bloggers. I also suggest watching any Salesforce Webinar that has anything to do with code, especially security stuff.


Practice makes perfect, except for us there is no perfect, just better. Know your best practices and live by them. With everything you do ask how can I make it better? Faster? More efficient? Do I even need code, or will Workflow/Process Builder/Flow do? How can I write code, so that an Admin can customize it without any code?

> Based on code reviews--my code is pretty good, with good logic and pretty well laid out.

This is actually VERY important, having good logic is obviously crucial, but being well laid out is a kind of hidden requirement with code. You or somebody else will eventually need to maintain your code, if it's laid out well it should hopefully be easy to read and maintain.

When you write code do your best to incorporate declarative features so that further customization can be done without code (I know I said this earlier, but I think it's important). Need to write some code that uses an arbitrary set of fields, consider using Field Sets. An Admin can add/remove them without code. Maybe use a Custom Setting, or Custom Metadata to map fields to values.

Learn how to use Describe calls for everything. Need to write some code that catches dupes and merges them? Don't hard code the values, then nobody will be able to remove or add fields without updating code. Instead use Describe calls, now you get every field on the object forever. Need to remove a field from an object no problem. Need to add a field to an object no problem. Does your losing record have child records that need to be reparented? Don't hard code, use Describe calls to get all sObjects with a Child Relationship. Use Describe to find out if it can be directly reparented or if it needs to be clones (CampaignMembers can't reparent a LeadId to a new Lead. You MUST clone and add the new Lead Id).

How much do you know about HTML? CSS? JavaScript? JQuery? Visualforce? Learn 'em. Lightning is coming, and these are going to be more important than ever (except maybe Jquery).

Practice, practice, practice. One coding assignment per month isn't that bad, but if you get some work done early and you have an hour or two to spare, work on a side project. Can you think of something in your company that could be automated, spin up a Dev Org and give it a shot. Maybe your Sales people could use a new VF page for entering information just a little quicker.

Always seek to improve your code. Always seek new ideas and better ways of doing things.

Trailhead is good, do all the coding ones you can find, it's more practice!

u/CSMastermind · 4 pointsr/learnprogramming

I've posted this before but I'll repost it here:

Now in terms of the question that you ask in the title - this is what I recommend:

Job Interview Prep


  1. Cracking the Coding Interview: 189 Programming Questions and Solutions
  2. Programming Interviews Exposed: Coding Your Way Through the Interview
  3. Introduction to Algorithms
  4. The Algorithm Design Manual
  5. Effective Java
  6. Concurrent Programming in Java™: Design Principles and Pattern
  7. Modern Operating Systems
  8. Programming Pearls
  9. Discrete Mathematics for Computer Scientists

    Junior Software Engineer Reading List


    Read This First


  10. Pragmatic Thinking and Learning: Refactor Your Wetware

    Fundementals


  11. Code Complete: A Practical Handbook of Software Construction
  12. Software Estimation: Demystifying the Black Art
  13. Software Engineering: A Practitioner's Approach
  14. Refactoring: Improving the Design of Existing Code
  15. Coder to Developer: Tools and Strategies for Delivering Your Software
  16. Perfect Software: And Other Illusions about Testing
  17. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application

    Understanding Professional Software Environments


  18. Agile Software Development: The Cooperative Game
  19. Software Project Survival Guide
  20. The Best Software Writing I: Selected and Introduced by Joel Spolsky
  21. Debugging the Development Process: Practical Strategies for Staying Focused, Hitting Ship Dates, and Building Solid Teams
  22. Rapid Development: Taming Wild Software Schedules
  23. Peopleware: Productive Projects and Teams

    Mentality


  24. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency
  25. Against Method
  26. The Passionate Programmer: Creating a Remarkable Career in Software Development

    History


  27. The Mythical Man-Month: Essays on Software Engineering
  28. Computing Calamities: Lessons Learned from Products, Projects, and Companies That Failed
  29. The Deadline: A Novel About Project Management

    Mid Level Software Engineer Reading List


    Read This First


  30. Personal Development for Smart People: The Conscious Pursuit of Personal Growth

    Fundementals


  31. The Clean Coder: A Code of Conduct for Professional Programmers
  32. Clean Code: A Handbook of Agile Software Craftsmanship
  33. Solid Code
  34. Code Craft: The Practice of Writing Excellent Code
  35. Software Craftsmanship: The New Imperative
  36. Writing Solid Code

    Software Design


  37. Head First Design Patterns: A Brain-Friendly Guide
  38. Design Patterns: Elements of Reusable Object-Oriented Software
  39. Domain-Driven Design: Tackling Complexity in the Heart of Software
  40. Domain-Driven Design Distilled
  41. Design Patterns Explained: A New Perspective on Object-Oriented Design
  42. Design Patterns in C# - Even though this is specific to C# the pattern can be used in any OO language.
  43. Refactoring to Patterns

    Software Engineering Skill Sets


  44. Building Microservices: Designing Fine-Grained Systems
  45. Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools
  46. NoEstimates: How To Measure Project Progress Without Estimating
  47. Object-Oriented Software Construction
  48. The Art of Software Testing
  49. Release It!: Design and Deploy Production-Ready Software
  50. Working Effectively with Legacy Code
  51. Test Driven Development: By Example

    Databases


  52. Database System Concepts
  53. Database Management Systems
  54. Foundation for Object / Relational Databases: The Third Manifesto
  55. Refactoring Databases: Evolutionary Database Design
  56. Data Access Patterns: Database Interactions in Object-Oriented Applications

    User Experience


  57. Don't Make Me Think: A Common Sense Approach to Web Usability
  58. The Design of Everyday Things
  59. Programming Collective Intelligence: Building Smart Web 2.0 Applications
  60. User Interface Design for Programmers
  61. GUI Bloopers 2.0: Common User Interface Design Don'ts and Dos

    Mentality


  62. The Productive Programmer
  63. Extreme Programming Explained: Embrace Change
  64. Coders at Work: Reflections on the Craft of Programming
  65. Facts and Fallacies of Software Engineering

    History


  66. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software
  67. New Turning Omnibus: 66 Excursions in Computer Science
  68. Hacker's Delight
  69. The Alchemist
  70. Masterminds of Programming: Conversations with the Creators of Major Programming Languages
  71. The Information: A History, A Theory, A Flood

    Specialist Skills


    In spite of the fact that many of these won't apply to your specific job I still recommend reading them for the insight, they'll give you into programming language and technology design.

  72. Peter Norton's Assembly Language Book for the IBM PC
  73. Expert C Programming: Deep C Secrets
  74. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming
  75. The C++ Programming Language
  76. Effective C++: 55 Specific Ways to Improve Your Programs and Designs
  77. More Effective C++: 35 New Ways to Improve Your Programs and Designs
  78. More Effective C#: 50 Specific Ways to Improve Your C#
  79. CLR via C#
  80. Mr. Bunny's Big Cup o' Java
  81. Thinking in Java
  82. JUnit in Action
  83. Functional Programming in Scala
  84. The Art of Prolog: Advanced Programming Techniques
  85. The Craft of Prolog
  86. Programming Perl: Unmatched Power for Text Processing and Scripting
  87. Dive into Python 3
  88. why's (poignant) guide to Ruby
u/krabby_patty · 4 pointsr/java

Working Effectively with Legacy code is great. It's not specifically a Java book, but I've found it very useful.

https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/agentultra · 4 pointsr/haskell

If it's a web application try putting a Haskell process in front of it. The Haskell process can run the legacy server in a sub-process, holding a lock if necessary, while it proxies requests straight through to the legacy application. Write all of your tests against the Haskell code and build a good layer of unit and integration tests. As you gain confidence in the test suite slowly replace code paths into the legacy code with a Haskell module that does the same thing. Wash, rinse, repeat.

The benefit to this is that the legacy code gets under test and becomes maintainable. You can start a re-write of the code base while shipping new features. If your team wants to back out of Haskell they haven't lost anything. And if your team enjoys working with Haskell it can really improve morale.

https://www.amazon.ca/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 has plenty of good strategies for dealing with the situation you're in.

Maybe down the road your team will start to see the benefits of Haskell but I would focus on being pragmatic. I have received better results by showing people how I've used Haskell to solve problems rather than telling them why they should be using Haskell. Even if the people in your audience are skeptical they should at least see that you're getting some value out of it. That can be a compelling enough story to get them interested.

u/gtani · 4 pointsr/scala

What else is there? git history, hopefully clean w/consistent branch/merges and commit messages, server logs w/devop notes (esp. heap, maxInline, GC etc params) annotated stacktrace or profiler runs, breakpoints/debug strategy, db schema, net logs, design docs yadda yadda. Not knowing anything else, i would read thru repo's recent and early history, run unit tests, profile/load test it and see how failure prone the server(s) are

You could start with an old repo that has the basic functionality you're interested in, hopefully it's a lot less LoC.

You could read Fowler or Feathers which i remember being good: http://www.amazon.com/Refactoring-Improving-Design-Existing-Code/dp/0201485672/

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052/

u/michael0x2a · 4 pointsr/learnprogramming

This is probably a better question for /r/cscareerquestions.

I'd also recommend reading through Working with Legacy Code -- you can find a decent summary of it here.

u/fragglerock · 3 pointsr/dotnet

Michael Feathers "working with legacy code" will give you some ideas on how to remove pain points of getting untested code under test.

http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

u/snarkyprogrammer · 3 pointsr/cscareerquestions

Sadly there are a lot of companies that operate like this and I wish I could say this isn't common , but it is, especially around non technical companies that do in-house development. However, there are lots of companies changing and trying to improve their process and code base.

Working with legacy code is something every developer has to do at some point. There are techniques to make the process easier. Checkout the book Working Effectively with Legacy Code

Also, try and follow the boyscout rule of programming. Always leave the code base slightly better than you found it. You don't have to go crazy, but little improvements here and there. Test the new code you write and over time you'll have a much cleaner and better system.

I used to work on a web application that was so horribly coupled together that any small change literally break the whole thing and cause hours of debugging. I know your pain.

u/bzBetty · 3 pointsr/agile

Iirc https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 was a pretty good book and gave lots of hints on how to refactor legacy code to make it easier to replace. Been a while since I've read it though.

u/seglosaurus · 3 pointsr/ProgrammerHumor
u/DeliveryNinja · 3 pointsr/java

Its never easy working with legacy code. I would say start a new project if the code base is small, or update the existing one if it is large and add in spring boot or equivalent. Get mvn setup. Get jenkins working on it. You are now 1 step closer.

Password issue need to be addressed immediately.

Introduce some high level testing, it will be difficult to unit test everything. Start with end to end integration tests and slowly introduce more testing as you go. Any new features should test the class they are part of.

Next step is to use your tooling to help remove dupe code, intellij will highlight all dupes. Start thinking about removing these. Fix the non critical issues, exceptions, jsp/servlets.

It'll be slow and painful to get your test coverage up to a good level.

Also

https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/StealthRabbi · 3 pointsr/computerscience

Working as a software engineer, you will inevitably inherit some code that is less than stellar and not designed for unit testing. This book is very effective and teaching techniques to overcome pitfalls with legacy code.

https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/seventeenninetytwo · 3 pointsr/programming

"Call out" also means to make reference to, especially in the context of a book where you might "call out" a figure, phrase, or common theme. This is how it was used above.

This is the book. Next time when you don't know, just ask.

u/comp_freak · 3 pointsr/cscareerquestions

Yes, it's true that writing unit test for legacy project is hard. But what I have done is when implementing new feature I start using Sprout Method or Sprout Classes which are unite tested. This allow me to know that the new features I added is unit tested and works as expected. It will not be easy at first as you have to find seams or create seams for testing. But once you start doing it each time you touch the project it's get little better. Once you have something decent show it to your team and they will love it.

I found that code get uglier as there are many small classes but it's easy to maintain.

If you haven't read, I would suggest you to check out Michael Feathers' Working with Legacy Code.

u/jasonswett · 3 pointsr/rails

> I am a relatively new to development

If you're new to development, it's hard enough just to learn Rails by itself. In addition to the Rails concepts (e.g. ActiveRecord, view rendering, etc.) there's Ruby, databases/SQL, servers, HTML, CSS and JavaScript. Even if you're already comfortable with all those things, it's pretty hard to throw testing into the mix. When I first got started my question was, "What do I even test?" Do I write unit tests? Integration tests? View tests? Controller tests?

My advice would be to forget about Rails for a little bit and just practice testing Ruby by itself for a while. Then, once you're comfortable with testing Ruby, it will be easier for you to go back and try to write some tests in Rails.

> What is your recommendation on if I should focus on rspec vs minitest?

A person could make technical arguments for either. Deciding which testing framework to use depends on your objectives. If you're teaching yourself testing to become a more marketable developer, then I would definitely recommend RSpec. Almost every Rails project I've worked on (20+ production projects) has used RSpec. Having said that, it's less important which tool you choose and more important that you have a solid understanding of testing principles. I personally chose RSpec and I'm glad I did.

Here are some testing resources I often come across:

Growing Object-Oriented Software, Guided by Tests (awesome book, highly recommended)

Rails 4 Test Prescriptions (just started it, seems good so far)

Working Effectively with Legacy Code (super good book and more relevant to testing than it might seem like)

Everyday Rails Testing with RSpec (haven't bought it yet but seen it recommended a lot)

Destroy All Software (just bought it today, seems good so far)

Lastly, I myself created what I call a Ruby Testing Micro-Course designed to make it easy for people like you to get started with testing. Feel free to check that out and let me know what you think.

u/manys · 3 pointsr/learnprogramming

This book is the (or a) bible for this.

Generally: you start at tests.

u/YuleTideCamel · 3 pointsr/learnprogramming

>But I feel two things are wrong, most projects i've gotten someone else had started on years earlier and my job has been to finish them.

This is actually quite common. It's rare to start a new project from scratch at an established company. This is called a "brown field" project, whereas a new project is called "green field." Everyone is always looking for jobs with green field projects, but it's actually quite rare (relatively)

I'd recommend reading the book Working with legacy code.

Working with someone else's code , with horrible structure , deprecated code is painful. But it's also a challenge to try and improve it. I used to hate legacy code, but now i enjoy it because I see it as fixing something and improving it.

A few tips:

  • If there are no tests, start adding tests. Integration / end to end first. Then unit tests. Having a solid set of tests means you can refactor without fear of breaking stuff.

  • Take the time to note everything difficult or bad about this code. This is the best learning you can have. On future projects, that might be greenfield, then you can architect your application in a way to avoid these issues.
u/bigboehmboy · 3 pointsr/programming

If you're looking for a good book on this subject, I'd recommend checking out Working Effectively with Legacy Code. It's 90% about unit testing, but offers a lot of great advice.

u/thamesr · 3 pointsr/java

If you ever work with an older codebase, check out "Working Effectively with Legacy Code".

https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

Getting older code under test is some of the most challenging (and rewarding) work you can do.

u/kromem · 2 pointsr/javascript

Read this book.

Then, after reading the whole thing cover to cover, start working on your proposal.

From some of the questions you're asking about jQuery integrating with a framework, it's clear that some more basic concepts of how to isolate legacy code and migrate piece-by-piece would be very helpful.

Also, just a suggestion, but I'd highly recommend doing the new development in TypeScript. It'll compile to play nice with any other code you might need it to, but will offer you some awesome tooling that will help in maintaining your project moving forward.

u/Ozymandias-X · 2 pointsr/PHP

The book that helped me most coping with legacy applications: Working effectively with legacy code

u/depraved_desires · 2 pointsr/beta

> but from what I remember during my time at the company the frontend was pretty rough. The work needed to get it into a state where you could slot "labs" features in a forward compatible way would have likely been a tremendous re-write on its own

but there's proven methodolgies for dealing with giant balls of mud and untested/undocumented legacy code. (I'm partial to this one

First, make sure you have a reproducible environment. Then right a bunch of tests. A BUUUNCH. It's unglamorous, laborious, hard work, but it's necessary to make sure your changes don't break anything. Then you use a combination of heavy refactoring + abstraction, et voila.

I've fixed legacy software, from a Uber-clone that bought a template from a team in India (no shit, the code has references to "UberForX") and having to replace every part piecemeal over months, to re-writing financial services spaghetti code that was doing over a million a year. The approach never really changes.

u/audaxxx · 2 pointsr/webdev

About the refactoring:
Working Effectively with Legacy Code is a bible for refactoring. The single best thing I read about working with legacy shit I have ever read. It really helps.

Great book. After reading it I even enjoy working with shitty code from time to time!

u/povilasb · 2 pointsr/cpp

It is normal :) I've read somewhere that 20% of our work time we develop new code and 80% new simply maintain the old code. And after a while it sound like true :)

I've been in a situation like you. I've been assigned to maintain a 0.5 million line c++ code base with no tests and no previous maintainers.

Considering that most of the time you're going to spend maintaining your/someones code base, code refactoring, modernizing practices are very valuable. And right now it seems like you have a chance to learn to do so.

Personally, what really saved me was this book: http://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052/.
So I believe that working on your project is one of the paths you can become a better software developer :)

u/Scott90 · 2 pointsr/cscareerquestions

A lot of people find Dealing with Legacy Code a must. I'm personally not a big fan, but it's worth trying.

u/CoreyWhite · 2 pointsr/programming

Doesn't answer your question . . . but get this book. It sounds like it would help.

u/_____dban_____-_ · 2 pointsr/java

You might find Michael Feathers Working Effectively with Legacy Code useful. It demonstrates how to safely migrate towards TDD in legacy projects by building up automated functional tests which allow safe refactoring to more testable code.

u/Tohnmeister · 2 pointsr/programming

True. I can highly recommend reading Working Effectively with Legacy Code by Michael Feathers.

u/Midas7g · 2 pointsr/cscareerquestions

You can. These are called pinning tests. They're usually done over small parts of the code, like a single function. You pull out a bit of code into a separate function, write tests so every line of the new function is tested, and repeat.

Once the section you want to refactor is pinned down, you can change to your heart's content without fear of introducing regressions.

You should read Working Effectively With Legacy Code by Michael Feathers if you haven't already. It changed the way I approach writing code.

u/bgcatz · 2 pointsr/programming

I've enjoyed Working Effectively With Legacy Code by Michael Feathers.

It is an excellent survey of techniques for breaking up monolithic codebases into independently testable modules. He's a strong advocate of test driven development, which I would argue is rather critical to you successfully redesigning your application.

u/YMK1234 · 2 pointsr/AskProgramming

Idk if there is a name for this, but it is a well-known phenomenon, to the extent that it killed companies (Netscape anyone?). The proper way to replace legacy systems is to refactor and evolve them (eg. by splitting out services from a big monolith one by one), not trying to replace them in one big go.

I was told Working Effectively with Legacy Code is a very good on the matter.

u/phuber · 2 pointsr/dotnet

If you are open to it, here are a few good reads to help you on your way. The legacy code book may pay dividends quicker given your situation.

Clean Code: https://www.amazon.com/dp/0132350882/ref=cm_sw_r_cp_apa_ruhyybGGV0C34

Refactoring: Improving the Design of Existing Code https://www.amazon.com/dp/0201485672/ref=cm_sw_r_cp_apa_gwhyyb1VRNSKK

Working Effectively with Legacy Code https://www.amazon.com/dp/0131177052/ref=cm_sw_r_cp_apa_0whyyb3Y604NJ

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler)) https://www.amazon.com/dp/0321601912/ref=cm_sw_r_cp_apa_JxhyybA08ZQF8

u/mad0314 · 2 pointsr/learnprogramming

I think it would be a good exercise to learn something new and then go back to your old projects and apply them. For example, learn about testing and go back to your calculator and try to get a good chunk of it under tests (another good resource is Working Effectively with Legacy Code, which covers getting projects under tests when they don't have any). Then learn about CI/CD, which use tests, and make a build pipeline for your calculator. Then read Clean Code, read about architectures and patterns, and see if you can improve your architecture. This is just an example, but any of those could give you good talking points if interviewers ask about your projects.

u/donquez · 2 pointsr/learnprogramming

In terms of practical, professional skills, here are a few I would recommend:

  • The Pragmatic Programmer - writing non-trivial applications requires discipline and a practical mindset. This book is frequently recommended to new programmers as exposure to how think about and approach software development.
  • Head First Design Patterns - schooling introduces you to OOP, but design patterns really highlight the strengths of object orientation. The Gang of Four book is also recommended, but I feel like the Head First book is more approachable.
  • Working Effectively With Legacy Code - You didn't mention if you're coding professionally, but I think the above two books are applicable to someone who wants to take their work to the next level. If you are looking to work in software development, you're going to encounter a lot of legacy code - code that is poorly designed or hasn't evolved well with the application. This book gives you methods for recognizing and untangling the mess.

    For more tailored recommendations, where do you feel that you're weak? There are plenty of college textbooks that can introduce you to algorithms, but if you have an end-goal in mind, you can really focus your learning. Work on some tougher projects than you're used to, and study open source code that does interesting things.
u/balefrost · 2 pointsr/AskProgramming

Heh, sure.

A lot of people are fans of Code Complete. I tried reading it after being in industry for a decade, and I found it to be very dry and boring. The general consensus from people that I've talked to is that it's more useful when you're just starting out. Maybe I just came to it too late.

A better book (in my opinion) in that same vein is Clean Code. Clean code is shorter, more focused, and has better real-world examples. It feels less "complete" (hue hue) than Code Complete, but to me, that's a strength. As a quick point of comparison: Code Complete devotes 32 pages to the chapter on identifier naming; Clean Code devotes just 14.

I got a lot out of Design Patterns. I seem to recall that the pattern fad was in full swing back when I read this in 2005-ish. I think I had independently discovered some of the patterns already at that point, but this book helped me to codify those ideas and also showed me some new ones. Some of these patterns are now seen as antipatterns (I'm looking at you, Singleton!), and all of the patterns have an object-oriented bias. But there's still something useful in the pattern language, and this book is a reasonably comprehensive start. The book is somewhat dry, and some people report that Head First Design Patterns is a gentler and friendlier introduction. Head First Design Patterns hits the essential patterns, but misses a lot of the less popular ones.

Eventually, you'll need to work in a codebase with some technical debt. Maybe it's debt that somebody else put there, or maybe it's debt that you introduced. Working Effectively with Legacy Code is still my go-to recommendation. It defines technical debt as code that is not under test, it introduces the idea of "seams" that you can use to pry apart code that's too tightly coupled, and it then provides a cookbook of specific scenarios and reasonable approaches.

If you're looking for thought-provoking videos, I recommend anything by Rich Hickey. I don't know if I've watched all of those, but I remember good things about Hammock Driven Development and especially Simple Made Easy.

Get comfortable with a source control system. I didn't use source control in college, since it wasn't needed for any classes, and that was a missed opportunity. The whole world loves Git, so you'll probably want to learn it if you haven't already. But I'll also toss out a recommendation for Mercurial. I haven't used it in years, but I remember finding it to be quite good.

Good luck!

u/majimakjang · 2 pointsr/cscareerquestions

try to apply principles from Working Effectively with Legacy Code as you work through your tasks

u/poloppoyop · 2 pointsr/programming

No "Working effectively with legacy code". Which could be titled "Pragmatic testing".

The DDD blue book, ok. But you'd be better served with "Implementing Domain-Driven Design" which was written 10 years later and have a lot less focus on the technical implementation of DDD.

Mastering Regular Expression should be there too.

u/LeTexan_ · 2 pointsr/csharp

I'm still a young C# developper, around 3 years of C# for websites and APis for small and big companies, but it's not because your predecessors built an in-house framework that this is the right way to build a system. C# is a great language but it shine thanks to the core orientation of productivity delivered by the .NET framework and ASP.MVC.


Of course if your needs are so specifics that you want a custom framework, don't forget that it will become a HR problem. Talented people rarely want to jail themselves to a company and build a specific set of skills that can't be transferred.


But as I said, I'm young. I do think that we are living on the shoulders of giants and that not everything need to be rebuilt. Some of the coolest techs we've seen these past years around containers and micro-services were actually already implemented in the 70's.

That said, I didn't read this book, so I will read it and predictably learn a lot of things. If you didn't already, I would recommend the following books. They aren't C# specific but will help you in the environment you are describing:

u/Octopork · 2 pointsr/dotnet

Been down this road and finally started having it make sense a couple of months ago. Try as i did to be better at testing it always felt like a hassle until i shifted my focus to writing testable code.

With that in mind, aside from covering basics of writing tests:

  • SOLID principles, hopefully you know these already(or of them) but if not, read into them. I found i had to start thinking about them while programming for the ideas to click.
  • Inversion of control and DI, I highly recommend Dependency injection in .Net core. Properly following these ideals makes your code so much easier to test and refactor.
  • You don't need to learn all there is about functional programming immediately but at least understand functional purity, pure functions are fairly painless to test.

    Injecting an interface that does nothing but provide DateTime.Now seemed absurd and overly complex when i first read about it but once all those pieces came together everything finally clicked and i no longer hesitated on writing tests as they were no longer difficult to write.

    I've been meaning to read through Working Effectively with legacy code but from what i have read so far it seems to have a huge focus on making old code testable, perhaps an option if your looking at improving your code base in your current job.
u/denialerror · 2 pointsr/learnprogramming

>How does one make a structural change in a project that is this entagled and big?

Slowly, and with a lot of tests. If you want a book recommendation, Working Effectively With Legacy Code by Michael Feathers is the Bible on this subject. The key takeaway is that code should be considered legacy if you can't make changes to it confidently. The only way you can be confident is if it is well tested.

I would also say that although it is very tempting to look at a poor codebase and try and make it better, ask yourself if there is value in doing so first. Focus on what is going to add value in the immediate future.

u/freebit · 2 pointsr/PHP

I totally don't understand what everyone's issue is. My favorite thing to do is to refactor legacy code and my bible for doing it is Working Effectively with Legacy Code. I get a huge amount of satisfaction from turning a complete mess into something magnificent and the best part is that it can all be done with minimal risk.

u/remy_porter · 2 pointsr/webdev

There are a lot of answers to your question. From the very question you're asking, I already know you aren't doing much unit testing. Unit tests are one of the most powerful forms of documentation you can have, because they document the expected behavior of a module. Code without unit tests is legacy code, and unit tests will help you tame that.

Help. They are not a panacea. And don't let "you should start unit testing" turn into "we should start tracking code coverage metrics". But unit tests can add a lot of value.

For unit tests to add value, you also need to have some sort of automated build process. Most build systems will have an easy-to-enable continuous integration mode. Turn it on. At first, your builds will fail. A lot. Especially as you start adding tests. But over time, those red lights are going to get less and less frequent.

Now, what are you doing about managing changes to the application? What's the workflow for putting things onto the backlog? How do they get prioritized? How do people get assigned work? There's no right answer to any of those questions, but I have one big piece of advice: don't let anyone own a module. If Sallybob was the last person to touch the OrderProcessor, the next time it needs a change, give it to Joebob. Yes, you're going to take a small hit on your cycle time. It's worth it.

u/Nitrodist · 2 pointsr/rails

The Working Effectively with Legacy Code book is fantastic for bringing legacy code under test and then being able to refactor from there without breaking functionality.

Around 80-90% of the examples in the book can apply to ruby based projects with the remainder being C/C++ or other language specific problems (header files, being an example).

Just as important as the techniques explained in the book is the philosophy it espouses of bringing the code under test.

u/njharman · 2 pointsr/programming

This doesn't seem as much of a defense as a lack of knowledge/experience/vision(creativity).

There exists methods (processes) and ways to architect that may be applied to even the most complex domains. There are innumerable papers and books on this subject. "Working Effectively with Legacy Code" (http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052) is decent start as any.

Btw, OOO, state machine, data-driven code, abstraction layers are the methods I'd be likely to investigate given OP description of 1500 line network function.

P.S. language and tool choice is very important. Some lack the power to easily express anything better than spaghetti.

P.P.S There are actual defenses of "Spaghetti Code" or rather why not to refactor or write crap code in the first place. One is YNGNI, e.g. prototype, time (startup needs to ship early to survive till critical mass when it's all getting thrown out anyways). Like everything the cost/benefit needs to be evaluated.

u/thehouen · 2 pointsr/cscareerquestions

I feel for you OP. I recently inherited a fully functional system already in production that was horribly coded. It is now in very good shape, and with a 92% test coverage. It is possible OP! ;)

Yes definitely create the UML diagrams. When you understand it well enough to create a high-level diagram, you will be much better armed, both for making changes, and for showing outsiders why A and B are important to do, since you have something concrete to go from. I would recommend this UML editor for it.

Next, is the code sufficiently under test?
If not, buy and use the book Working Effectively With Legacy Code by Bob Martin. It helps a lot. First step is getting at least some of it it under test. The book is a big one, but you don't need to read it all to get cracking. It is like a recipe book:

"Let me see, okay, I have eggs, chicken, and a 1000+ lines class calling into an unknown legacy system. Then I should use the coding recipe on page 432, and plenty of garlic. Always use plenty of garlic."

Best of luck OP!

u/my_shiny_new_account · 2 pointsr/learnprogramming

Learn about "characterization tests." Also, read this book.

u/popcultur · 1 pointr/webdev

That looks good. There's a good chance I'll read it (this link worked for me).

u/ForeverAlot · 1 pointr/programming

I don't know of any one source that teaches "good testing principles". There are thousands of sources and Sturgeon's law is working against you. A few sources are predominantly good, most have bits (often the same bits) of genuinely good advice in-between chapters of bland, uninsightful repetition, many are appropriations of popular acronyms by closely or distantly related professions (no, you're not "testing" a requirement specification, you're just reviewing it), and some sources are just plain bad.

I had an opportunity to attend Dan North's Testing Faster course and would strongly recommend it. In my case it was more helpful for formalising my own experience than learning concrete new things but other attendees did absolutely "learn new things". He made a point that "TDD" and "BDD" are both inaccurate names and that something like "example-guided development" would have been far more honest; he recommended a book, I think Specification by Example, as a good resource to that end (and noted that that name, too, is technically inaccurate). He also confirmed that Cucumber is a solution looking for a problem.

Test Driven Development: By Example by Kent Beck is a classic, and as far as I can remember, decent. It's maybe a little old now, and it definitely misses some subtle points about maintainability of automated tests in general (or perhaps rather, doesn't really address that).

I've skimmed Code Complete 2. I don't remember it in detail but my overall impression of it was that the sooner it becomes irrelevant the better, because that would signify our profession maturing (if not quite reaching maturity). A lot of its contents would be considered basic by contemporary software development standards and that's a good thing. I don't remember what it says about testing. One thing in a very late chapter (33.8?) stuck with me, though: that seniority has little to do with age and your approach to software development will be formed early on.

Working Effectively with Legacy Code by Michael Feathers is excellent, perhaps the most practically applicable one here.

Sandi Metz is famous in the Ruby community for speaking on this topic and there are recordings on YouTube. From what I've seen her material also mainly addresses beginners but it's fast and easy to consume and her form doesn't bother me the way Martin's does.

One piece of advice I picked up from one of those mostly-mediocre sources had to do with naming in tests, trying to capture the essentials. If you're relying on a particular property of a piece of input to test behaviour, make sure this is evident. Conversely, if any input would satisfy, avoid drawing undue attention:

fn bees_can_fly() {
let some_bee = ...
let bumblebee = ...
let dest = ...

assert fly(some_bee, dest);
assert fly(bumblebee, dest);
}

fn bees_can_pollinate() {
let some_bee = ...
let flower = ...

assert pollinate(some_bee, flower);
}

Testing is about developing confidence. There are many kinds of testing and many things to develop confidence in. For automatic tests it's more about checking (arguably not "testing") that you retain correctness in the face of continuous change. Automatic tests that obstruct that change or compromise your confidence are not helping you and should be rewritten or removed. Reliability of tests is usually more valuable than coverage, for instance.

u/rakeswell · 1 pointr/programming

Thank you for this -- I will certainly try this out. I can also recommend Michael Feathers' book, Working Effectively with Legacy Code

u/suddenarborealstop · 1 pointr/PowerShell

this book may help: http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052.

also, put everything into functions and then unit test all of it (with mocks) using pester.

u/devnull5475 · 1 pointr/programming

This is a good read: Working Effectively with Legacy Code

Basically,

  • Get unit tests in place
  • Get instumentation in place
  • Start refactoring

    P.S. I assume you have already studied Refactoring by Martin Fowler.
u/itsmoppy · 1 pointr/golang

BTW, have you read the Feathers book on legacy code? It's pretty damn good and helped me a lot.

I'm not saying you're a bad developer. What I am saying is that Feathers is a rare genius.

edit: https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

(There might be a newer edition)

u/Naut1c · 1 pointr/dayz
u/MSpeedAddict · 1 pointr/webdev

Have you read Working Effectively with Legacy Code?

I ask because mundane problems and new solutions do not always go hand in hand. Sometimes, working on the bleeding edge isn't possible; even when it is I've been there correcting Microsoft employees in C#, correcting Google on timezones in Chrome, tooling employees in their own stack, etc. and I don't think that's even what you're looking for. Its more of the same.

I've found grace in truly helping companies refactor, restructure, re-stack and modernize their applications for scale. Be it on mainframe applications or full-stack client-facing web applications, taking something old and completely ripping it out for something new is an art form. It's much easier to try and write your own code, find a problem - hit a wall, search for a solution and copy pasta. It's much harder to understand the problem you're facing, that stems from understanding someone else's code and derive a solution. In the same way it's easier to create something new then fix something old (holding constant creativity).

This is what has led me to the art of architecture, refactoring beyond SOLID and design patterns by the GoF - but in truly coming in to a new company and really understanding their business first then their solutions and the consequences of re-writing all of their applications in a new, automated way.

I'm not your "pixel-perfect" guy. While I see why you focus on the "front-end" being what bores you, I think instead you're bored by cookie-cutter solutions you can even begin to find on StackOverflow. I've traced problems on a mobile web client down to processor implementations. I refer to real problems as greenfield, most likely inaccurately. I find design both consequently and paradoxically crucial and irrelevant to success. You can have the prettiest looking face with no neck, working body and arms or everything working just fine but damn ugly to look at and you'll steer clear. It just might not be what interests you.

It's finding where you fit into the puzzle that matters most - this career is both scientific, relational and calculated as it is the most creative art form on the planet. They say development is one of the most free art-forms one can hope to master. Go figure.

--ramble, ramble, ramble

u/roosterruley · 1 pointr/PHP

It sounds like the first problem you have is that the code is not written in a way that is easily separated out. That is unfortunate, but unless you get a magic wand it is something you will have to deal with. It sounds like you have the .git sorted out, but really git is just both a parachute and a deployment tool - your problem is in the code.

Your basic setup sounds good with a development server. What I'd recommend is that you either run the developer server locally on your machine or run it in a virtual machine since you don't always seem to have access to a development server.

  1. Stop making changes and make a list of the problems that you want to address, then figure out which you need to work on first.
  2. Have a consistent development server setup
  3. Refactor complicated code into simpler code - if you are spending too much time trying to figure it out it could be done better. Check Refactoring or Working Effectively with Legacy Code. Make little changes that work and test it. Don't try to fix the entire application at one.
  4. Test what you are changing to be sure you don't break things (PHPUnit is perfect for this).
  5. Define an overall structure that makes sense - it doesn't have to be a perfect MVC separation, but it have to make sense to You.
  6. Use an HTML templating tool (if you are not already).
u/amazingmikeyc · 1 pointr/PHP

Yes. Also, Michael Feather's book is good (I think they both reference eachother as they're both in the agile/tdd clique) https://www.amazon.co.uk/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

(tldr; write automated tests where you can)

u/ThereKanBOnly1 · 1 pointr/dotnet

I'd recommend two books to help you with the project, Working Effectively with Legacy Code and Refactoring: Improving the Design of Existing Code. "Legacy" has a bit more unit testing coverage than "Refactoring", but chances are there will need to be some design changes to the code to be unit tested effectively, and these books will help you make those changes if you eventually want to get to the place where you do have unit testing coverage on that part of the codebase.

u/Omnius · 1 pointr/programming

Write an interface layer then use modern language and tooling against the interface.

https://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/jocona · 1 pointr/cscareerquestions

I would add Working Effectively with Legacy Code to the list. Each chapter title is a problem (e.g., Chapter 14: Dependencies on Libraries are Killing Me) that the rest of the chapter tries to resolve.

It’s great to read through once and occasionally look back on as a reference book. And by learning how to fix bad code, you learn how to write good code in the first place

u/brews · 1 pointr/learnprogramming
u/maze-le · 1 pointr/softwaredevelopment

Try to make a sketch: What are the dependencies of each function / class / module. How are they interconnected, what is the scope of each dependency (can they be bundled into a module / class on its own?). I usually make such sketches on paper -- old school.

If you have the sketch, you can start unbundling it by trying to minimize the dependencies of each part to one another. Once that is done, you can either refactor or outright reimplement the code. Depending on how big the mess is, a complete reimplementation can be simpler sometimes (albeit more time consuming).

There are also very good books on that issue:

u/alexanderleon · 1 pointr/learnprogramming

The bootstrap you'll use to run your tests will come together and that part will be easy soon enough. Writing testable code will take longer to grock completely. You will learn how to write [SOLID] (http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) code.

I'd start with the Michael Feathers book.

Stick to it. You will be a far better programmer for the effort.

u/Eligriv · 1 pointr/cscareerquestions

Refactor as you go.

Here are some sources on how to get better over time, at doing right the first time as well as getting it right afterwards :

  • First quick read : www.sourcemaking.com
  • How to write readable and maintanable code : clean code
  • How to refactor as you go : working effectively with legacy code

    Take your time with it. It took me ~5 years of practice before i was able to produce good code. And it will probably take me another 5 to produce great code. That's the way it is.

    I was in your exact position at my first gig : i also removed my name from all the code. But that's good because it meant that i improved enough to see what i was doing wrong at the time.

    After that i discovered unit tests, and then clean code, tdd etc.
u/[deleted] · 1 pointr/TwoXChromosomes

Fiction - A Clash of Kings, the second book in a Song of Ice and Fire.

Non-Fiction - Working Effectively with Legacy Code & OpenGL ES 2.0 Programming Guide. A Coder's gotta code.

u/alinroc · 1 pointr/cscareerquestions

Change what you can, when you can, without introducing significant additional risk. Lead by example - write code the way you feel it should be written within the confines of the system.

Assuming you're using a VCS that was created in this century, delete dead (commented-out) code in files when you're in them for other purposes.

Do not randomly reformat code (especially tabs to spaces or vice versa) unless doing so will make the file internally consistent.

Do not rename things for the sake of renaming them (especially public .

You may find this book useful.

u/carillon · 1 pointr/Python

Working Effectively With Legacy Code is probably the best book currently on how to add tests to an existing system.

Specifically it outlines a number of strategies for getting badly-written code under test so you can begin refactoring with confidence.

If you took an untested (or poorly tested) Django app from GitHub or BitBucket and added some tests that would be a really effective example.

u/kraftvgs · 1 pointr/java

I had minor programming experience from a NASA internship but no practical object oriented programming experience aside from very basic classes. Effective Java is a wonderful book and if you have read it and comprehend it then you are more than ready for an entry-level programming job. Seriously, just start applying.

If you want to do more reading I would recommend staying away from Java books and dive into more generalized coding practice books. IMO, Clean Code is a must read, especially for a new programmer. Also Working With Legacy Code is a great read if you plan on going into a business setting where you will be working with a well-established code base. Again, these are just opinions. Go with all of the advice you've seen in your thread. I haven't seen a shred of bad guidance.

u/cronofdoom · 1 pointr/cscareerquestions

I would recommend picking up Working Effectively with Legacy Code. It sounds like you could really use it. It teaches how to get unit tests in, how to start finding places to split up the monolithic jumble into smaller, more testable components, how to add features without breaking stuff, and that is just cracking the surface. it is a highly recommended book in the community and I suggest you pick it up.

If you were in PHP I would recommend a book called Modernizing Legacy Applications in PHP, which was my saving grace when I was in your position. If you can find a book like that for Rails then you are set.

I also want to point out that this is a fantastic opportunity for you. They don’t usually teach these skills in college and they are very important. My first job out of college I was in a very similar position. I had a 250,000 line PHP site that was business critical. I had unrestricted access to its very helpful author, however, he had no idea as to modern software development practices and architecture. No source control, no tests, no rollback procedures no documentation or comments, and the site was the spaghetti monster, but holy cow it worked. Oh don’t even get me started about the crazy database naming conventions, the 5000 line “this takes all night to run because the database table doesn’t have a single index” stored procedure, or the crazy hack jobs of ETL from seven or eight other databases.

I ended up reading a lot of code, writing tests, doing a ton of refactoring, and added some features too. It was very, very painful but I learned a lot. Learning to work with complicated code you don’t understand is a very very important skill you will use for the rest of your career. And you can do it!

One other thing. Please do not openly or privately criticize or blame the previous authors or even the code. It is easy to play the blame game and use that to justify things you were doing. Others might be doing it too. Regardless, it will be seen as immature and unprofessional. There are many ways to indicate places for improvement without tearing down the people and code. Please learn from my mistakes.

I wish you the best and offer any other advice, mentorship, or moral support that you require. Just pm me.

u/guifroes · 1 pointr/cscareerquestions

Computer Science wouldn't have helped you there, they don't teach this kind of stuff.

You say you've been studying and it's helping a lot, how are you studying? Books? Courses?

For your kind of problem (code architecture and design, legacy code refactoring, etc), I don't think there's a shortcut. It's all about knowledge and (probably years of) experience. I can suggest some books that will definitely help you (you might have read some of them):

u/oliviacode · 1 pointr/programming
u/phillaf · 0 pointsr/programming

The conversation is drifting, but the problem you are describing can be vastly eased when using proper methodology.
https://www.amazon.ca/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

u/uzomi · 0 pointsr/gamedev

Well, when talking about code maintainability it's not the same thing.

It's clear that both of you do not understand the concept of clean code. That's why you guys think that there is some language barrier that does not exist since you guys do not know what concept I'm talking about.

There is some stuff that's very valuable for every programmer to read and I recommend for you guys.

Clean Code

Working Effectively with Legacy Code

The SOLID principles

Those are very good books, give it a try and you might thank me later.

Have a nice day to you too Inukai!

u/sgmctabnxjs · -1 pointsr/programming

Why would you do that? That's nothing to do with Agile.

Have you not read Working Effectively With Legacy Code?

edit: Added link to early pdf of ideas which became the book