First, I'd try to identify how the status quo affects your bottom line. How will you determine if the rewrite/refactor is being successful?
Be wary of the glamour of "doing things the right way". Don't want to get into a new mess.
Ask HN: How’d you go from a noodler to writing large well structured programs?
41–50 of 77 posts
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#42I monk purges possessions. It is painful, but necessary.
I had many scripts for blogging and doing many types of divine oracles. I generated my website from within TempleOS. It wasn't ugly code, but it got out of hand.
Today, I hand-code my website in html, just an index page and I make naked Unix directories, just putting files for download because every browser can navigate a naked file system. Unfortunately, my high def video files cannot be downloaded because the browser invokes the media viewer which stalls. I guess I could disguise the files.
Eventually, TempleOS DD.Z, GR.Z and AU.Z and RedSea ISO.C will be universally supported.
God says... confessions Crusoe cancel Nembutal whiskey Forest recopies updraft Afrikaners jawbreakers sect sang coifs hassle recrimination's firebug practiced Kojak shoestrings sameness oaf vests crèches yap hockey's ratings causality argon's root defects bullpens meters
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#43what a joke. take your binary opposition and walk out of here.
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#44Start using Git right away. The time dimension of code is the most useful to organize.
Then learn and use some object oriented programming. Don't go too deep- just enough.
Then organize your code into files and folders based on the class relationships that start emerging. It's really that easy.
One more thing: don't read any books about structuring code or go by any blog posts. They will only teach you someone's opinion. Code structure is a team decision. Make an effort, even a small one, with clear advantages, and your work will be appreciated. Overload your team with demands based on something you read somewhere and they will resist.
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#45Accept one simple fact:
Your first attempt is going to suck. How bad is a shade of gray, but it'll suck.
Accept this fact:
Your first attempt is going to suck. How bad is a shade of gray, but it'll suck.
And accept another fact:
Your third attempt is going to suck. How bad is a shade of gray, but it'll suck.
At some point, your attempts start to suck less.
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#46Start using Git right away. The time dimension of code is the most useful to organize. Then learn and use some object oriented programming. Don't go too deep- just enough. Then organize your code into files and folders based on the class relationships that start emerging. It's really that easy. One more thing: don't read any books about structuring code or go by any blog posts. They will only teach you someone's opin…
>It's really that easy
It's really not. Neither git, OOP, nor nice folder structures are a panacea (nothing is, of course). I've seen beautiful C in Source Safe and I've seen awful, overly engineered class happy crap in git repos.
Writing good, non-trivial systems requires experience and skills in many areas. No design pattern or source control system will save you from yourself if you're just not at that level yet.
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#47A lot of commenters have recommended reading books that lay out clean code structure and the such, but if the problem is as bad as you say it is, I would recommend reading the somewhat satirical "How to write unmaintainable code". You should be able to find out what issues you do need to fix with that, and the remedies you'll be able to find in the recommended clean code books.
As the parent mentions, you're looking specifically for ways to write 'maintainable code'- that's the terminology you should be searching for, not well-structured code.
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#48I've found that a good rule of thumb is the "3 rule".
When you start using the same code in more than 3 places, put it in a shared lib type of file / folder.
When you start using the same code across 3 projects, put that into a "module" and manage independently in version control.
Depends on the language / framework you're using, but I've found that general rule pretty helpful in my experience.
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#49I am a quantitative developer working on industrial size projects.
Best way to learn personally is to get hired into a team that does serious project in the area you are interested in. If you are not looking to switch jobs, hire few people who have done that into your team, or get them on a contract (going to be crazy expensive but totally worth it).
First, basics, start with Joel's 12 rules of better code[1]
Next, buy everyone a copy of "Clean Code" book and read it from start to finish.
Look at the open source quant code bases, how they are organized and built. I suggest quantlib[4] and opengamma[3].
If you are looking at architecting quant library specifically, read this article by Russell Goyder[2]
[1] https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s... [2] https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2311743 [3] https://github.com/OpenGamma [4] https://github.com/lballabio/QuantLib
Re: Ask HN: How’d you go from a noodler to writing large well structured programs?
#50I am a quantitative developer working on industrial size projects. Best way to learn personally is to get hired into a team that does serious project in the area you are interested in. If you are not looking to switch jobs, hire few people who have done that into your team, or get them on a contract (going to be crazy expensive but totally worth it). First, basics, start with Joel's 12 rules of better code[1] Next, b…
These are some great suggestions, thanks.