Is there a Haskell version for this?
Undebt: How We Refactored 3M Lines of Code
81–90 of 143 posts
Re: Undebt: How We Refactored 3M Lines of Code
#82Earlier quoted context omitted.
I don't know exactly what Yelp does, but assuming that they have listings for restaurants that aren't their customers, one cause could be that they take in data from lots of sources. Ideally, that is all in the same format, with an enforced data scheme. However, if you require that, you'll notice that very little data manages to make it through your entry port. Few suppliers will want to bend their system for you to…
> On top of that, once you operate world-wide, you'll learn the joy of differences in addresses. Does a country have states? Zip codes? If so, where does one specify them in an address? If you want to localize that in your app (in yelp's case, people may want to show an address to a taxi driver. For that, it would help if the address followed local conventions) line count skyrockets. This is not the first time this i…
This is something that grows slowly on you, and it is a very hairy problem. By the time you realize the scope of your problem, finding a library that can be shoe-horned into your code and doesn't have huge regressions on your data is hard.
Also, assuming a robust generic solution exists, it will almost certainly be slower than a customized one. It is very tempting to think "but our data is relatively clean, we don't need the full feature set of that library that makes imports take an hour longer to run".
Re: Undebt: How We Refactored 3M Lines of Code
#83It would be nice if some research institution would pay for the rehabilitation of some huge, bloated, ancient, but relatively unimportant app. Ideally by independent teams in parallel. Just to get some real data on what works, rather than anecdotes from veterans.
Your comment opened my eyes. Considering the importance of software development in today's world ( and tomorrow's), the fact that those best practices or code management technics are found mostly in blogs, instead of scientific papers with proper experiments, tells a lot.
I don't follow. What does it tell?
Re: Undebt: How We Refactored 3M Lines of Code
#84"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are wor…
> I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt. I had a Philippino friend who told me of his early experience in a Japanese development outfit - the team got praised by management (maybe not CEO) on performance improvements and code reduction. At the time I thought those priorities would never have flown in t…
Do you know what sort of project/product the team produced? I find that to be a key indicator of what sort of work management expects.
If are building something that will be sold, particularly in a competitive market, management will almost always believe that new features trump reducing technical debt. To a product manager, even four weeks of technical debt reduction sounds like "no new features for a month."
Re: Undebt: How We Refactored 3M Lines of Code
#85Earlier quoted context omitted.
> I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt. I had a Philippino friend who told me of his early experience in a Japanese development outfit - the team got praised by management (maybe not CEO) on performance improvements and code reduction. At the time I thought those priorities would never have flown in t…
Do you know what sort of project/product the team produced? I find that to be a key indicator of what sort of work management expects. If are building something that will be sold, particularly in a competitive market, management will almost always believe that new features trump reducing technical debt. To a product manager, even four weeks of technical debt reduction sounds like "no new features for a month."
Sometimes it's a struggle to get blessing for four days of technical debt reduction...
Re: Undebt: How We Refactored 3M Lines of Code
#86Google has a similar tool called Refaster
Re: Undebt: How We Refactored 3M Lines of Code
#87How do web applications explode out to 3 Million lines of code? Yelp, to me, looks like a typical CRUD app and I would have been surprised if it were more than 100,000 lines of code. The software I develop is pretty large and typically doesn't surpass 40,000 sloc written in-house (i.e. excluding third party libs). Does anyone here maintain such large codebases? Are they truly that big or are people just counting thir…
I work on a product in payments, specifically a client-side checkout application. It's essentially responsible for collecting data from the user (billing and shipping addresses, affordability information, etc.), presenting the various payment methods and displaying up sell stuff after completing the purchase. Just the client side application is about 250000 lines of code, not including third party stuff.
It feels like applications grow with the team that develops it. At our peak, we were around 10 people working on it, and it's just so hard to do meaningful refactoring when large parts of the codebase are being modified by 10 people in parallel. Not only the technical challenge, but also getting everyone to agree on and embrace patterns and structure.
Re: Undebt: How We Refactored 3M Lines of Code
#88This smells as being a need that comes as a consequence of using a dynamically-typed language. Because the example given seems to be just getting rid of the usage of a certain method, to replace with a new one. In a statically typed language, e.g. C#, you just mark the old method with an [Obsolete] attribute and go fix all the warnings. (Granted, a tool that replaces all these usages is also useful, but to me, there…
In VS2015, showing all references to methods, props, classes, etc. is just one click away. Unfortunately it's not available in the community version. https://msdn.microsoft.com/en-us/library/dn269218.aspx?f=255...
Use MonoDevelop/XamarinStudio.
Re: Undebt: How We Refactored 3M Lines of Code
#89Earlier quoted context omitted.
That's by far the best way to work. It's hard to explain to someone who hasn't experienced it how much easier it is to develop in a bug free code base.
I challenge that; I don't think a "bug free code base" actually exists. Joshua Bloch has a great article about this which I think may be of interest to other readers: https://research.googleblog.com/2006/06/extra-extra-read-all... . To paraphrase: We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are gre…
There exist, however, code bases where any refactoring or feature addition exposes a latent bug that has to be fixed before proceeding. Additionally, fixing that bug often exposes another one.
Re: Undebt: How We Refactored 3M Lines of Code
#90Earlier quoted context omitted.
IMO the main reason Python standard library is so wildly inconsistent. They don't really have the tools to migrate stuff painlessly and the 'batteries included' approach with weak versioning means you can't change stuff without breaking everyone who upgrades a python version.
I don't think your theory is right (I simply don't think it has been given enough polish), but even so, the other side of the coin is that you can relatively easily hack in temporary migration paths. For instance, a function can examine the parameters it is given and convert them to the latest API, spewing out a warning. Backwards compatibility is mostly an attitude problem.
Yeah if all you have is straight calls to functions, as soon as you do stuff like assign function to a variable, method calls you need to do sophisticated code analysis and that's not even touching the untraceable stuff like string/dynamic access, monkeypatching, etc. etc.
Refactoring in python is bad even if you restrict yourself to "sane" code (no metaprogramming and abusing dynamic stuff so the tools can follow what you're doing) if you need something that will work for everything out there it's just impossible to do.