71–74 of 74 posts
Now that it's become clear that the thing is about to collapse in on itself, you've brought in Mr. Feelgood Consultingman, to give us engineers generic advice, so that suddenly it's not your fault that this digital superfund site is in the state it is, but your engineers' for not following the consultants advice.
Earlier quoted context omitted.
> It's harder if they can't read the older examples, but I can google for a more modern example as well. It gives nomenclature and examples. Don't do that. Ostensibly you're giving these people the book so that they'll learn to deal with legacy code. Those older examples are exactly what they need to see, even if they're in a language that those devs are not using.
Junior developers in javascript codebases of 7-10 years old will not have the experience necessary in some cases. I am coaching them as a manager trying to introduce a concept, not a professor. I may be doing a disservice to their long term development at the cost of short term gains. However, I don't think this is true. There are a lot of developers who will never work in a C, C++, C#, or Java codebase. And I try to…
Kind of depressing to read because it's so accurate, yet so likely to be ignored. I remember when Martin Fowler first published the book "Refactoring" - I was so relieved at the time because somebody with some clout that executives might actually listen to had not only identified what was wrong with software but identified a way to fix it and even gave it a name! Boy was I wrong - now you have to be careful how and w…
Additionally, a lot of refactoring is about predicting the future rather than adapting the code to present expectations while keeping things easy to change. The only metric that your future self cares about is time to feedback. Refactor to adapt to present expectations while keeping the code easy to change in the future, and don’t ask for permission to do this- it is your job.
This book is extremely overrated because the whole thing can be summed up in two bullet points: * write your new code somewhere outside the main solution and call it from the old solution * automated tests are pretty cool and you should write these whenever possible I found the book to be close to useless when I was working with actual legacy code. How do I write an unit test for an application that has an embedded V…
> How do I write an unit test for an application that has an embedded Visual Basic script support with dozens of scripts that are thousands of lines long? The book does not answer this question at all because the author assumed I have the luxury of working with Java or an another language that supports the object-oriented paradigm and can be endlessly extended with no limitations whatsoever. Why does the idea of iden…
Because the script is embedded and requires the runtime of that proprietary legacy application and there's no way to make it run outside that runtime. Think of it as trying to add unit tests to Excel macros.