3 ms·

I don't understand how people do refactoring without static typing. If I change a function parameter in Typescript then I get compiler errors for each use. Awes

by Sammi 8y ago

I don't understand how people do refactoring without static typing. If I change a function parameter in Typescript then I get compiler errors for each use. Awesome. With plain Javascript I have to run the program and get it into executing all those different invocations and hope I get meaningful errors at runtime. A nightmare. In my experience Javascript code bases end up being "add new code only", because changing anything is just too dangerous, because type errors are so hard to find. So after a while of several people working on the code base it just becomes a bloated spaghetti mess that cannot be untangled, because refactoring is nigh impossible.

z3t4 8y ago
There are some tricks you can do in order to break up the code base to make it more manageable using the plugin and module patterns. Each part of the code that can be useful in other code bases you can break up into modules. For example a Vector library if you are making a game. It's OK to move out even small functions if they are common enough, like the famous leftpad module. Next step is the plugin pattern, where each plugin is totally independent of other plugins, where the plugins communicate to the main codebase via an API. The third trick is to move complexity to the architecture, meaning that some part(s) of your system, often a bottle-neck that need to be horizontally scaled - is moved out into it's own code-base aka micro-service. Now it will be much easier to refactor, you can for example write the module, plugin or micro-service in another language. I've done my fair share of managing code bases with 10k LOC of spaghetti where a change of one parameter can break code at 100 other places, but thankfully there are better ways. Then there's the fifth trick that is an old JavaScript convention, that if you do change a parameter, you also make it so that you can use the public function as before in order to not break stuff, that's the true power of dynamic JavaScript, for example if your function takes three arguments, and the first two is optional, it should be possible to call the function with only one argument, and the function will figure out what parameter belongs where. Then if there's an error in the parameters, the function should throw early with a nice human readable error, debug data/dump and stack. Also see defensive programming. Then the sixths tip is testing. After a certain point, when it takes longer to manually test, then it takes to code, it's time to introduce automatic testing. It doesn't have to be unit tests. It can for example be regression test, meaning that for every bug you find, you write a test that would automatically have found that bug - before actually writing the bug fix! Then the next step is to write integration tests (not sure about the name), where the code functionality is tested from the outside, for example in a web app a button is auto-clicked, then the DOM state is checked to make sure everything is correct. There are a ton of different types of tests you can apply, for example perf-test that make sure the performance has not degraded.
- Sammi 8y ago
  Changing things to be more modular in order to make it more manageable is a great idea. But the problem is still that you cannot make any such change to existing large Javascript codebase, because you don't have the kind of tools that you need in order to do so with any confidence that you won't have an enormous amount of uncaught runtime errors when you're done. This is what a static type system gives you.

by Sammi 8y ago

z3t4 8y ago

There are some tricks you can do in order to break up the code base to make it more manageable using the plugin and module patterns. Each part of the code that can be useful in other code bases you can break up into modules. For example a Vector library if you are making a game. It's OK to move out even small functions if they are common enough, like the famous leftpad module. Next step is the plugin pattern, where each plugin is totally independent of other plugins, where the plugins communicate to the main codebase via an API. The third trick is to move complexity to the architecture, meaning that some part(s) of your system, often a bottle-neck that need to be horizontally scaled - is moved out into it's own code-base aka micro-service. Now it will be much easier to refactor, you can for example write the module, plugin or micro-service in another language. I've done my fair share of managing code bases with 10k LOC of spaghetti where a change of one parameter can break code at 100 other places, but thankfully there are better ways. Then there's the fifth trick that is an old JavaScript convention, that if you do change a parameter, you also make it so that you can use the public function as before in order to not break stuff, that's the true power of dynamic JavaScript, for example if your function takes three arguments, and the first two is optional, it should be possible to call the function with only one argument, and the function will figure out what parameter belongs where. Then if there's an error in the parameters, the function should throw early with a nice human readable error, debug data/dump and stack. Also see defensive programming. Then the sixths tip is testing. After a certain point, when it takes longer to manually test, then it takes to code, it's time to introduce automatic testing. It doesn't have to be unit tests. It can for example be regression test, meaning that for every bug you find, you write a test that would automatically have found that bug - before actually writing the bug fix! Then the next step is to write integration tests (not sure about the name), where the code functionality is tested from the outside, for example in a web app a button is auto-clicked, then the DOM state is checked to make sure everything is correct. There are a ton of different types of tests you can apply, for example perf-test that make sure the performance has not degraded.

Sammi 8y ago
Changing things to be more modular in order to make it more manageable is a great idea. But the problem is still that you cannot make any such change to existing large Javascript codebase, because you don't have the kind of tools that you need in order to do so with any confidence that you won't have an enormous amount of uncaught runtime errors when you're done. This is what a static type system gives you.