'/%3e%3cpath%20d='M50.3943%2022.237V39.5876H43.5185V22.7481C43.5185%2019.2029%2042.0411%2017.3949%2039.036%2017.3949C35.7325%2017.3949%2034.0778%2019.5338%2034.0778%2023.7585V32.9759H27.2434V23.7585C27.2434%2019.5338%2025.5857%2017.3949%2022.2822%2017.3949C19.2949%2017.3949%2017.8027%2019.2029%2017.8027%2022.7481V39.5876H10.9298V22.237C10.9298%2018.6918%2011.835%2015.8754%2013.6453%2013.7877C15.5128%2011.7049%2017.9623%2010.6355%2021.0028%2010.6355C24.522%2010.6355%2027.1813%2011.9885%2028.9542%2014.6917L30.665%2017.5633L32.3788%2014.6917C34.1517%2011.9885%2036.811%2010.6355%2040.3243%2010.6355C43.3619%2010.6355%2045.8114%2011.7049%2047.6847%2013.7877C49.4931%2015.8734%2050.3963%2018.6899%2050.3943%2022.237Z'%20fill='white'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_89_8'%20x1='30.5'%20y1='0'%20x2='30.5'%20y2='65'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%236364FF'/%3e%3cstop%20offset='1'%20stop-color='%23563ACC'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Verwaltet von:
Doing a (brief) presentation Monday on long term software development (>10 years). Things you regret in year 8. I'd love to hear things you found out and wished you'd done differently. Or conversely, what worked out really well. Will turn this into a public presentation & blog post. To kick it off: PLEASE KEEP YOUR CODE AS SIMPLE AS POSSIBLE.
@bert_hubert Having worked on one project for 17 years, the best decision I've made was to minimize dependencies and choosing tech that seemed like it'd stick around for a while.
I've had much more recent projects where I already regretted using a library that broke within a year or two and isn't being maintained anymore.
① Are other people using it? (easy to check via distros like Alpine or Gentoo)
② Could I end up maintaining it? (either due to upstream passing me maintenance, or needing to fork/patch it)
Question ① isn't very important but makes sense to check, could otherwise end up missing a better dependency without doing so, and sometimes turns out the dependency is used by no one because it's unusable.
Question ② is probably the most important, could skip it for throwaway scripts but well… temporary sometimes spans for a very long time.
Note: I tend to consider not just libraries but also utilities, buildsystems, language implementations as part of the dependencies. Could even consider deployment like packaging into distros in there as well but can't really call that a dependency of the software.
@lanodan @bert_hubert @ayo In some cases it makes sense to code your own packages instead of relying on external parties. Minimising the number of dependencies stands out to be the most effective way to make your system future proof and easy to maintain.
Operating systems, file formats, protocols, … do change, and dependencies can help on this part, so you'd have to be careful to not minimise too much.
And picking a dependency should mean keeping an eye on it, hence the question of possibly ending up maintaining said dependency.
And future proof… I think the best way to approach the future proof ideal is to allow independent implementations to be made.
You can have code which should work well in the future but realistically there's no telling what will happen in roughly 10 years. Which to me is a rather short timespan for software, but enough for big changes to happen.
@lanodan @bert_hubert @ayo It is always a fine balance between what is good for the short term and what is wise for the long term. Especially in web development there are new frameworks and related components popping up left, right and center. One should always think twice before jumping on the next hot thing that comes along. Keep it simple and have future maintenance in mind. That might mean that you have to do a little bit more work now in order to save time and money in the long run.
Like web browsers have pretty good API compatibility between each others and APIs very rarely break, same thing for NodeJS itself.
One thing that's lacking is the JS standard library, so if you want to target both browsers, NodeJS, … you're definitely going to need wrappers and maybe few libraries. Which okay makes sense, you're targetting different platforms.
But then you have build tools and frameworks that are so API-unstable that keeping up is a challenge.
Which makes no sense and just means that using them undermines what otherwise would be very stable platforms.
@lanodan @bert_hubert @ayo I never managed to get into the whole server side JS thing. My background is PHP and now with version 8.4 coming up thing are starting to look very bright on the LAMP stack.
The problem with most JS client side frameworks and tools is that they 'try' to turn JS is some sort of OOP thing which it just isn't. This results in some half-hearted construction with namespaces and classes that don't seem to make things better.