@pnathan Any tips for maintenance of code? I'd hate for things to devolve into a mess over new features and bugfixes. Is continuous refactoring the best way to handle this?
@motokochan No. that is a waste of time. You have to take a broader view. The goal of a codebase is habitability(c.f. Gabriel). So you need tests- within reason. The code needs to be organized and have loose coupling between modules. Think of a city. Always changing and being maintained, but somehow *almost* everything is working. This is done by limiting blast radius of changes.
Then, periodic file level and module level reworks to ensure things are in order.
@motokochan to be churning on constant refactoring and to have 98% code coverage is sort of a fools game. The aim is to make progress and to have a clear system design that can cope with change over time.
BTW one advise I do have: strongly typed languages make refactoring and changes epically easier.
@motokochan hope that helps?
tell me if these thoughts are full of beer, er... crap.
@pnathan I think it does. This code is really the first I've had to consider long-term maintenance needs due to others using and depending on it.
@pnathan Yeah, the main codebase I'm concerned about is PHP, so strong typing isn't an option here. I have been working on increasing code coverage where it makes the most sense to make sure things won't break with changes. I'm parsing HTML pages, so there's a strong need to make sure the results are sane.
Don't know of the Gabriel citation. Can you provide more details on that?
@motokochan Richard Gabriel's collection of essays, Patterns of Software. Habilitability and Piecemeal growth.
PHP does not work with the developer to help with maintainability.
@pnathan I'll definitely look them up. I haven't had much formal training in CS, though, so anything that can help me improve is appreciated.
PHP doesn't work with the developer for much. However, it was the language both the co-developer and I had in common. I'm relying on Symfony and the PSRs to enforce some rigor, however.
@motokochan cs doesn't really relate to code maintainability. that's usually taught on the job in the first 1-3 years. system/algorithmic scaling is more CS
@motokochan i tell profs flat: don't teach software engineering. we'll cover that in the junior years when you start work. you teach algorithms and fundamentals.
@pnathan I was a lit major, so I didn't really get any background outside topics I read on my own volition.
@pnathan I used to work for a hosting company and website/application development company as a server admin and occasional bug fixer. We didn't have a lot of long-term projects, but I at least learned some of the things to not do that caused headaches down the road.
@motokochan theres a lot of wank about the proper way to develop software. so many methods and cargo cults out there.
it's simple and profound, but subtle in implication and effects, and hard to carry though.
write code. do hierarchical decomposition. have high cohesion and low coupling between each layer of the system. write tests for your code. log and monitor what your code does. smaller functions win over larger ones. use source control. use continuous deployment. care when tests fail
@pnathan I've been finding that out a lot on my own, but it's nice to see it written out and know I'm on the right track. Thank you for the expertise.
@motokochan glad to help, glad to chat any time.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!