|
Ithaqua posted:TFS really is a wonderful product for those of us who are Microsoft-centric. I want to learn git better, but all of the commands are scary and obtuse. religion aside, Mercurial is probably what you want in this case.
|
# ? Jan 15, 2013 22:52 |
|
|
# ? Jun 5, 2024 21:38 |
|
qntm posted:It's true, comprehending code does become rather difficult when you start ignoring random characters. in languages where variables are $var_name, it can be quite easy to miss (!$, especially when you're tired. (in perl I tend to use (not $var) or unless
|
# ? Jan 15, 2013 23:00 |
|
Otto Skorzeny posted:Perhaps, if there were some way to put associated Names in their own Space, we wouldn't have to prefix them ourselves to prevent Collisions. But alack!, such a technology is beyond our grasp, despite our most earnest Declarations. PHP only got namespaces relatively recently, and a code obfuscation tool that doesn't work on terrible shared hosts running ancient versions of PHP is extra pointless.
|
# ? Jan 16, 2013 01:49 |
|
Ithaqua posted:TFS really is a wonderful product for those of us who are Microsoft-centric. I want to learn git better, but all of the commands are scary and obtuse. The commands are really easy if you have half a clue and just some basic SVN experience. Ignore the stuff about how it's a directed acyclic graph and all that; it's helpful when understanding rebasing and how branches/tags actually work but you really don't need it just to escape lovely VCSs.
|
# ? Jan 16, 2013 09:44 |
|
Found this while I was refactoring some of our code. This stuff has been in production for 4 years.Java code:
|
# ? Jan 16, 2013 17:16 |
|
If the horror fits on on eline, its not an horror.Python code:
how!! fucked around with this message at 17:27 on Jan 16, 2013 |
# ? Jan 16, 2013 17:25 |
|
Problem: A procedure is too long. Solution: Django! There are options somewhere in between. Gazpacho fucked around with this message at 20:31 on Jan 16, 2013 |
# ? Jan 16, 2013 20:29 |
|
Solution: how!! posted:the entire project could be re-written
|
# ? Jan 16, 2013 20:30 |
|
how!! posted:The sad part i that the entire project could be re-written using django and could be a fraction of the size So why are you pasting the code that wouldn't be made any smaller?
|
# ? Jan 16, 2013 20:48 |
|
how!! posted:If the horror fits on on eline, its not an horror. php:<? /* https://oursite.com/s3cr37s7uff/do_cmd.php : 17 */ $output = shell_exec("php /var/important.php ". mysql_real_escape_string($_GET['myvar'])); ?>
|
# ? Jan 16, 2013 21:01 |
|
Zamujasa posted:My boss begs to differ: Ok, that one's funny.
|
# ? Jan 16, 2013 22:08 |
|
Gazpacho posted:Problem: A procedure is too long. Naw I'm totally sure he'll remember the supply fee discount on small orders in the re-write since's it is adequately documented outside of the code.
|
# ? Jan 16, 2013 22:25 |
|
how!! posted:The sad part i that the entire project could be re-written using django and could be a fraction of the size, but "that would take forever". Oh, it's you again. Does Django 1.4 do your read your order processing manual for you now? I haven't used the newer versions, but that feature would certainly help with this very specific procedure. JawnV6 posted:Naw I'm totally sure he'll remember the supply fee discount on small orders in the re-write since's it is adequately documented outside of the code. Thanks to how!!'s refactoring prowess, company profits are up!
|
# ? Jan 16, 2013 22:57 |
|
how!! posted:If the horror fits on on eline, its not an horror. Counterpoint: C# code:
|
# ? Jan 16, 2013 23:08 |
|
JawnV6 posted:Naw I'm totally sure he'll remember the supply fee discount on small orders in the re-write since's it is adequately documented outside of the code. Its not documented anywhere, including in the code. Which is why no one is going to miss it if it gets lost in a refactor. As it is now, that code I posted above is completely worthless. It doesn't mater that the code "works". It is completely incomprehensible by anyone except for the person who write that code. The reason why this code is so terrible is largely because the whole thing is using a NoSQL database instead of a proper relational database. So all the data is ridiculously denormalized. Any time you make a change to one data structure, you have to also update all the associated other records. A lot of the complexity you see above is not complexity inherent in the business process, its complexity brought on by poor technical architectural decisions. The business this code belongs too is a house cleaning business. Its not some kind of rocket science simulator. Code that people understand but the computer doesn't is more valuable than code that the computer understands but people don't. how!! fucked around with this message at 23:21 on Jan 16, 2013 |
# ? Jan 16, 2013 23:17 |
|
how!! posted:Its not documented anywhere, including in the code. Which is why no one is going to miss it if it gets lost in a refactor. I'm sure any customers that get recurring bills would miss it, but who cares about them when you've got software to
|
# ? Jan 16, 2013 23:23 |
|
how!! posted:Code that people understand but the computer doesn't is more valuable than code that the computer understands but people don't. This is one of those dangerous "axioms". "people", here, means "you after five seconds of looking at the code". People can understand it, eventually, and you need to understand it, so you can figure out what it's doing, so you can write its replacement. Yes, it sucks. But you are here to provide value to the customer, and add features to their web app. Obviously, clear, maintainable code helps achieve this, and spending an hour or two to take those parts that really suck and just make them suck less can be a fun weekend hack. I can already spot some basic transforms I'd do to that code to help make it more clean, and Django and a rewrite is not one of them. Suspicious Dish fucked around with this message at 23:40 on Jan 16, 2013 |
# ? Jan 16, 2013 23:38 |
|
how!! posted:Its not documented anywhere, including in the code. Which is why no one is going to miss it if it gets lost in a refactor. Customer: "Last week I bought X and it cost Y, today I bought X and it cost Z....."
|
# ? Jan 16, 2013 23:38 |
|
Suspicious Dish posted:This is one of those dangerous "axioms". "people", here, means "you after five seconds of looking at the code". People can understand it, eventually, and you need to understand it, so you can figure out what it's doing, so you can write its replacement. That'll take just as long as doing a complete re-write. Did you see the code I posted above? Thats 300 lines. How long did it take you to completely understand that code? How long will it take you to understand the remaining 50,000 lines? How long will it take you to implement a software application that books cleaning ladies using proper development techniques?
|
# ? Jan 16, 2013 23:43 |
|
When considering a rewrite of an application it is wise to consider that often 10 percent of the features/requirements of an application are responsible for 90 percent of the complexity in the implementation. This can bite you pretty hard if you glance over an application, implement a useful subset of the functionality you see in a couple hundred lines and then use that to justify a rewrite to "finish off those other minor things". As Suspicious Dish said, one should seek to steadily improve poorly-written codebases rather than throwing them out.
|
# ? Jan 16, 2013 23:44 |
|
how!! posted:How long did it take you to completely understand that code? How long will it take you to understand the remaining 50,000 lines? I got the gist of what it was doing fairly quickly. The intricacies and complexities of cross-cutting concerns will take me longer, but I'd need to understand them anyway in order to provide equivalent functionality in a rewrite anyway, so I can rewrite all of it, or I can rewrite just this function. The latter will take shorter.
|
# ? Jan 17, 2013 00:07 |
|
how!! posted:That'll take just as long as doing a complete re-write. Did you see the code I posted above? Thats 300 lines. How long did it take you to completely understand that code? How long will it take you to understand the remaining 50,000 lines? How long will it take you to implement a software application that books cleaning ladies using proper development techniques? Edit: Also let's not kid ourselves here and pretend you have a spec that encompasses everything your codebase does, because you don't.
|
# ? Jan 17, 2013 00:07 |
|
php:<? function cronupdate($currentVersion) { // for future update checking exec("wget -q -O /tmp/update.txt [url]http://localhost/Forum%20Static%20Files/update.txt[/url]"); sleep(5); if(file_exists("/tmp/update.txt")) { $handle = fopen("/tmp/update.txt", "r");$newestVersion = fread($handle, filesize("/tmp/update.txt")); fclose($handle); $newestVersion = $newestVersion + 0; if ($currentVersion < $newestVersion) { echo "NEW VERSION AVAILABLE"; } else {} } } ?>
|
# ? Jan 17, 2013 00:10 |
|
Isilkor posted:Do you have a proper spec for the code? Because if you don't, you'll have to completely understand all 50,300 lines anyway before you can rewrite them. No I don't have the "spec", thats the problem. No one has a spec because one does not exist. I don't have to under stand all 50,300 lines, I just need to understand the entire business. Theres a difference. Just because the code is 50,3000 lines doesn't mean the company does 50,300 things. This particular company only does like 10 or 15 things. A big misconception people always have is that complex code is always complex because the problems are complex. The code is complex because you're doing work arounds. The work arounds are there because you had to work around other work arounds, etc.
|
# ? Jan 17, 2013 01:06 |
|
how!! posted:I don't have to under stand all 50,300 lines, I just need to understand the entire business. In any large and/or well-established organization, or in any reasonably complex problem domain, there are going to be really weird rules and requirements that, if you're lucky, a handful of people in the company will understand or even be aware of. You will probably not be one of those people. You'll rewrite the software according to your imperfect understanding, and within a week you'll have someone in your office saying "Why doesn't it foo the bar when the moon is full and the current millisecond is divisible by 37? It has to do that because of the Kwijybo Act of 1873, otherwise we'll be out of compliance and we'll get fined!" Somewhere, deep in the bowels of the code you threw out, was a chunk of code that handled it that was written by a consultant in 1997. It was undocumented. It was obscure. No one even knew it was there anymore because the code was functioning properly.
|
# ? Jan 17, 2013 01:20 |
|
how!! you should rewrite that poo poo and prove all these haters wrong.
|
# ? Jan 17, 2013 01:41 |
|
Ithaqua posted:In any large and/or well-established organization, or in any reasonably complex problem domain, there are going to be really weird rules and requirements that, if you're lucky, a handful of people in the company will understand or even be aware of. You will probably not be one of those people. The real problem was that your Kwijybo Act of 1873 code was so hidden and unknown to begin with. The fact that my theoretical refactor broke it and resulted in a fine is actually a good thing. At least now we can re-implement the Kwijybo Act of 1873 code, and this time we can do it so that its comprehensible and documented. The fine we had to pay is the price it costs to improve the business. Maybe the original Kwijybo Act of 1873 code was buggy and was resulting in us paying more in [whatever Kwijybo Act of 1873 does]. It kind of reminds me of all those companies still using IE6. When IE7 came out, they made a deliberate decision to not upgrade because (most likely) it would require some code that no one could understand to be rewritten. Those companies are now stuck on IE6 forever. In 20 years, those same companies will still be on IE6, because code that is not understood today, will still be not understood long into the future.
|
# ? Jan 17, 2013 01:41 |
|
how!! posted:No I don't have the "spec", thats the problem. No one has a spec because one does not exist. A big misconception people often have is that a big picture understanding is as valid as a complete understanding when it comes to getting abstractions right. There are hierarchical levels of organization to code or information in general. You can think of complexity as a branching tree, where each node you inspect reveals more details you can explore. Lack of abstraction may make such a tree to flat to be internalized and understood. For example, if I wanted to become some guru of everything some company does: code:
A flat level of organization makes it very hard for someone to focus on any single category at once, understand it, and be able to modify it. Code, documentation, and whatever, can all be reorganized and routinely cleaned up to present cleaner abstraction whether they're classes, modules, high-level concepts, functions, chapters of documentation or whatever. If we imagine the tree as being purely about code, each of the leaves can be a pure piece of poo poo, it will still be somewhat maintainable and repairable if things are isolated enough that someone can focus on any of these at once, as a unit, gain expertise, and keep working with it. That's very basic stuff in terms of understanding abstraction and isolation of concerns. Problems happen when you need to break that neat structure because of new changes. Then it becomes harder and harder to fix anything without gaining more external knowledge than the topic at hand. Advocating that a high-level understanding of the code, that just getting to know one shallow aspect of things, is enough to rewrite it all is generally a very bad idea. It means you're taking what could be the skeleton of the tree and say "I can just fill in all the blanks really easily as long as I know the general structure". This is rarely the case, and in fact, re-engineering, or rewriting an application without knowing enough about what it does in details is a risky thing where you're likely to fall in the same trap of having picked the wrong structure, being short on time, and then needing to work around your design. If, on the other hand, you know what the code does, understand the initial abstraction and why it's broken, then it becomes easier to reorganize it the right way. Rewriting code without understanding what it does is a surefire way to shoot yourself in the foot.
|
# ? Jan 17, 2013 01:42 |
|
Smugdog Millionaire posted:how!! you should rewrite that poo poo and prove all these haters wrong. "These haters they gon' hate on you like anyway" -gucci mane
|
# ? Jan 17, 2013 01:43 |
|
how!! posted:The fact that my theoretical refactor broke it and resulted in a fine is actually a good thing. So your theoretical refactor is theoretically a good thing because it costs your company money to theoretically fix a theoretical problem that might not even theoretically exist. Please inform any employer that you feel this is the way it is before they hire you.
|
# ? Jan 17, 2013 01:45 |
how!! posted:No I don't have the "spec", thats the problem. No one has a spec because one does not exist. I don't know if you're trolling or not because I don't see how an actual person who claims to be a software engineer can be this dumb, but admitting you don't understand 50000 lines of code and using that as a lame excuse to rewrite it is terrible. I mean are you claiming to know all of the built up knowledge (bug fixing and the like) involved in maintaining that code? I don't even know why I'm asking this question. I'm sorry not all solutions to problems are as elegant as you'd like them to be but every other person in the world does just fine. Perhaps get some therapy?
|
|
# ? Jan 17, 2013 01:45 |
|
Damiya posted:So your theoretical refactor is theoretically a good thing because it costs your company money to theoretically fix a theoretical problem that might not even theoretically exist. In an interview, how!! asks you if you value your code. If you do, he won't work for you because he won't be able to rewrite it in lieu of reading it to understand it.
|
# ? Jan 17, 2013 01:46 |
|
When traveling, how!! brings a white sheet of paper and draws the map as he goes, because "there are way too many lines" on those that exist.
|
# ? Jan 17, 2013 01:47 |
|
I once threw out an entire authentication system because it was an undocumented, unreadable piece of poo poo and I suspected it was full of bugs and security holes and other nasty poo poo. It turned out that we did actually use that system to allow users to log in. We lost an entire month of revenue while I rewrote the thing using clean, well-documented, understandable code that resembled none of that ugly spaghetti code we had previously. We still haven't gotten our user base back to what it had been. And to make things worse, two months later some rear end in a top hat hacker found a SQL injection exploit and ended up stealing our entire authentication database. Just the cost of improving our business, I guess.
|
# ? Jan 17, 2013 01:52 |
|
echo <<<EOFhow!! posted:The real problem was that your Kwijybo Act of 1873 code was so hidden and unknown to begin with. The fact that my theoretical refactor broke it and resulted in a fine is actually a good thing. At least now we can re-implement the Kwijybo Act of 1873 code, and this time we can do it so that its comprehensible and documented. The fine we had to pay is the price it costs to improve the business. Maybe the original Kwijybo Act of 1873 code was buggy and was resulting in us paying more in [whatever Kwijybo Act of 1873 does]. EOF >> how_quotes.tzt The code wasn't hidden and unknown. You never bothered to read the very minor 300 lines in the first place to figure it out, because "oh man this is so complex". how!! posted:It kind of reminds me of all those companies still using IE6. When IE7 came out, they made a deliberate decision to not upgrade because (most likely) it would require some code that no one could understand to be rewritten. Those companies are now stuck on IE6 forever. In 20 years, those same companies will still be on IE6, because code that is not understood today, will still be not understood long into the future. It's not because they don't understand the code, in most cases it's because they bought some cheap CMS from a company that went out of business in 1996 and they don't even have the code.
|
# ? Jan 17, 2013 02:01 |
|
Biowarfare posted:
Reminds me of a similar script from a prior company. Hosted client sites (all on the same network at the time, mind) accessed a public PHP page on the main company website that dumped out all the rows of a database table. It then dropped its entire table and replaced it with the downloaded data. Over 10 MB of data each time, in plain text, every day. The data was for patterns to match e-mail bounce messages and changed about once a quarter.
|
# ? Jan 17, 2013 02:03 |
|
Damiya posted:So your theoretical refactor is theoretically a good thing because it costs your company money to theoretically fix a theoretical problem that might not even theoretically exist. Hows that any different than a new manager coming on board and noticing that %0.13 is being shaved off all transactions. He asks the programmers why that is. None of the programmers have any idea. Three days later a programmer finds that on line 63463 theres a bit of code that subtracts %0.13 off all transactions. Manager asks why it is doing that. Programmer has no idea. No other manager has any idea. Manager tells programmer to remove that code. Company is then fined. I call it How!!'s rule of software complexity: As software complexity increases, bugs and features become indistinguishable. (USER WAS PUT ON PROBATION FOR THIS POST)
|
# ? Jan 17, 2013 02:07 |
|
Rewriting code because you don't understand it may not quite be as insane as it sounds. I read a Kent Beck blog post (I think, could've been some other notable person) wherein he claimed that refactoring was a useful technique he used to understand new codebases: he'd take a look at existing code and refactor it until he understood it. But of course he doesn't destroy 100% of the functionality in the process.
|
# ? Jan 17, 2013 02:08 |
|
how!! posted:The fact that my theoretical refactor broke it and resulted in a fine is actually a good thing. At least now we can re-implement the Kwijybo Act of 1873 code, and this time we can do it so that its comprehensible and documented. The fine we had to pay is the price it costs to improve the business.
|
# ? Jan 17, 2013 02:09 |
|
|
# ? Jun 5, 2024 21:38 |
|
how!! posted:I call it How!!'s rule of software complexity: As software complexity increases, bugs and features become indistinguishable. Smugdog Millionaire posted:Rewriting code because you don't understand it may not quite be as insane as it sounds. I read a Kent Beck blog post (I think, could've been some other notable person) wherein he claimed that refactoring was a useful technique he used to understand new codebases: he'd take a look at existing code and refactor it until he understood it. But of course he doesn't destroy 100% of the functionality in the process. That bold bit is the key point; there's a difference between refactoring and rewriting.
|
# ? Jan 17, 2013 02:10 |