Ask HN: How to go from scripting to Programming/Architecture?
7 comments
I highly suggest you learn about Design Patterns in a language that you enjoy. For example I wouldn't suggest buying: Design Patterns: Elements of Reusable Object-Oriented Software but learn how to use design patterns in a language you want to use. Learn about singletons, factories, and learn about anti-patterns as you go. Think and give yourself some time to decide "what is it that I want to create". Also, design patterns for like a web app are going to have different patterns for a video game. Not every language is object oriented nor is every language functional. So different language types may have different patterns.
Personally I like react because it allows me to make reusable components. I have worked in various places that rather just copy and paste a block of html and css that they use in many places. It becomes hell if you want to change it. Sure you can search and replace, but sometimes those pieces may change a bit based on requirements.
In my opinion the more hands that pass through a codebase without following any standards becomes a nightmare. I think when you are worried about bigger programs, the important thing is to understand how different components are connected. You don't need to know the exact code running in that moment. Although it could help if you have a photographic memory.
Personally I like react because it allows me to make reusable components. I have worked in various places that rather just copy and paste a block of html and css that they use in many places. It becomes hell if you want to change it. Sure you can search and replace, but sometimes those pieces may change a bit based on requirements.
In my opinion the more hands that pass through a codebase without following any standards becomes a nightmare. I think when you are worried about bigger programs, the important thing is to understand how different components are connected. You don't need to know the exact code running in that moment. Although it could help if you have a photographic memory.
There's no right answer I guess. It really depends on what you're doing.
For me if I'm starting a project and I have no idea how to structure it I'll typically look for some simple example projects which do something similar.
So if you're looking to build a small game with say the Phaser framework then you could just Google "phaser example games" and look for some projects that you think are structured well.
Other than that it's mostly just about splitting up code into smaller reusable modules. If you're finding your code hard maintain that's generally a sign that you need to break it down into smaller components that can be reasoned about easier. I think one of my strengths as a developer is that I'm kinda dumb and have really bad memory, therefore I have to simplify everything just to get thing done.
Another thing I see devs do wrong a lot is that they tend to want to extend existing code too much. The reason for this is obvious, generally it's quicker and easier to add an extra parameter to an existing method rather than taking a step back to think about how to add the functionality without increasing complexity of any given method / component. But if you keep adding parameters and extra logic eventually you end up with something that's extremely complex and hard to maintain.
I find if I just focus on reducing state and the number of parameters I'm passing between methods as much as possible then I'm forced into good patterns.
It's also worth just taking a step back from time to time and thinking about the high-level architecture of your project. As a project develops and grows in complexity there are times where you might need to make larger changes to keep things maintainable. This might not be the case for you if you're just working on smaller projects, but there are times where it can make sense to split projects up into smaller services.
For me if I'm starting a project and I have no idea how to structure it I'll typically look for some simple example projects which do something similar.
So if you're looking to build a small game with say the Phaser framework then you could just Google "phaser example games" and look for some projects that you think are structured well.
Other than that it's mostly just about splitting up code into smaller reusable modules. If you're finding your code hard maintain that's generally a sign that you need to break it down into smaller components that can be reasoned about easier. I think one of my strengths as a developer is that I'm kinda dumb and have really bad memory, therefore I have to simplify everything just to get thing done.
Another thing I see devs do wrong a lot is that they tend to want to extend existing code too much. The reason for this is obvious, generally it's quicker and easier to add an extra parameter to an existing method rather than taking a step back to think about how to add the functionality without increasing complexity of any given method / component. But if you keep adding parameters and extra logic eventually you end up with something that's extremely complex and hard to maintain.
I find if I just focus on reducing state and the number of parameters I'm passing between methods as much as possible then I'm forced into good patterns.
It's also worth just taking a step back from time to time and thinking about the high-level architecture of your project. As a project develops and grows in complexity there are times where you might need to make larger changes to keep things maintainable. This might not be the case for you if you're just working on smaller projects, but there are times where it can make sense to split projects up into smaller services.
Have you tried working through any of the "make your own X" projects?
https://viewsourcecode.org/snaptoken/kilo/
https://viewsourcecode.org/snaptoken/kilo/
Oh wow! Thanks! "Build your own X" as search term on HN really is great resource - and a rabbit hole I guess...
Thats classic OR(experience, problem_OfOtherPeople) :)
no, joke. I read out, that you have problems with software architecture. This might be a key word to get you starting. I can't help you much here, except of telling my experience/thinking. You can also do study SA. Obviously, its not as easy, as one might think - if even a whole study can be filled with that topic.
But also, I think that still not the thing you need. SA can be seen as a kind of build-up structure of software, flowcharts, representations of functions, etc... for example, for communication of all the people involved in writing that software.
I think, one who's job is to write software, and not to design it, already do a kind of structure and software architecture in his head, by thinking in functions, methods, classes and imports. Without even know UML or other descriptors. So, this lead me into thinking its all experience and eloquent-ness in speaking that language.
Structure of Code / Software also does come from the "language" itself. Do you use libs? Imports? Or, do you rather write the whole thing into one large source code file? What imports do you need, what needs to be packaged into retail?
So this way, you're pushed into "thinking" what code to place where and into what module. This also very often lead to the need of refactoring of the code. Even in the "middle of a function" do some refactoring of other functions ... I would say thats the agile method ;)
You could look up coursera on that topic. I wouldn't buy books, as the internet has plenty on topic.
no, joke. I read out, that you have problems with software architecture. This might be a key word to get you starting. I can't help you much here, except of telling my experience/thinking. You can also do study SA. Obviously, its not as easy, as one might think - if even a whole study can be filled with that topic.
But also, I think that still not the thing you need. SA can be seen as a kind of build-up structure of software, flowcharts, representations of functions, etc... for example, for communication of all the people involved in writing that software.
I think, one who's job is to write software, and not to design it, already do a kind of structure and software architecture in his head, by thinking in functions, methods, classes and imports. Without even know UML or other descriptors. So, this lead me into thinking its all experience and eloquent-ness in speaking that language.
Structure of Code / Software also does come from the "language" itself. Do you use libs? Imports? Or, do you rather write the whole thing into one large source code file? What imports do you need, what needs to be packaged into retail?
So this way, you're pushed into "thinking" what code to place where and into what module. This also very often lead to the need of refactoring of the code. Even in the "middle of a function" do some refactoring of other functions ... I would say thats the agile method ;)
You could look up coursera on that topic. I wouldn't buy books, as the internet has plenty on topic.
Thanks, I'll look into Software Architecture while also just pushing ahead and prepare for some heavy refactoring!
Write longer scripts. You will very quickly repeat the mistakes for which we have architectured solutions. Then you can make informed searches to solve those problems.
You can also look at how simple applications are organized, or look at application templates to see where everything is.
You can also read about common software development patterns as they are answers to those common problems.
I don't have a specific book to recommend. I found that stumbling through worked a lot better for me. Write something simple and useful, and rewrite it often. It's very easy to keep improving upon something that you actively use on a daily basis.
You can also look at how simple applications are organized, or look at application templates to see where everything is.
You can also read about common software development patterns as they are answers to those common problems.
I don't have a specific book to recommend. I found that stumbling through worked a lot better for me. Write something simple and useful, and rewrite it often. It's very easy to keep improving upon something that you actively use on a daily basis.
Thanks! The idea of templates is great, i think!
Also just pushing ahead is just what I need to do and later refactor. I always tend to stop, when I feel something I am about to do should be done better, but don't really know how.
Also just pushing ahead is just what I need to do and later refactor. I always tend to stop, when I feel something I am about to do should be done better, but don't really know how.
Once it's finished, you'll want to make changes to it. Over time, you will see what makes changes easier or harder. Then the literature on patterns will really click.
If you read about patterns too early, they don't "click", but rather become something you overprescribe without really thinking why. We call it design patternitis.
I have overengineered far more code than I have hacked together. Now I'm a bit more cautious about it.
Templates are a good middle ground. They give you a good mold for your application, and inform you about best practices that you might not think about.
Just don't sweat it too much. If software solves problems, it does its job.
If you read about patterns too early, they don't "click", but rather become something you overprescribe without really thinking why. We call it design patternitis.
I have overengineered far more code than I have hacked together. Now I'm a bit more cautious about it.
Templates are a good middle ground. They give you a good mold for your application, and inform you about best practices that you might not think about.
Just don't sweat it too much. If software solves problems, it does its job.
Do it step by step.
Find a challenging enough problem on the next level to solve. For example, create a simple computer game, or simple web app, i.e. chat app in a browser. Approach it with the architectural mind set, i.e. first think how you would structure it, which components you will need. Then implement. If it goes well, find the next problem, if it doesn't take a look at similar OSS solutions. Study them, think about tradeoffs they made, and after learning from them try again.
P.S. Don't do more complicated scripting. I would say scripting is an area of its own. My understanding is that you want to get to more of an application development.
Find a challenging enough problem on the next level to solve. For example, create a simple computer game, or simple web app, i.e. chat app in a browser. Approach it with the architectural mind set, i.e. first think how you would structure it, which components you will need. Then implement. If it goes well, find the next problem, if it doesn't take a look at similar OSS solutions. Study them, think about tradeoffs they made, and after learning from them try again.
P.S. Don't do more complicated scripting. I would say scripting is an area of its own. My understanding is that you want to get to more of an application development.
I am a self-taught programmer/scripter. I had a lot of exposure to different programming languages on a project basis. C#, JS, Python, VB and others. And I am fine with implementing the small things/scripts needed.
But I struggle when things get more complicated. I start to overthink things and then often drop the project or end up with something that is hard to maintain.
How do I structure "bigger" programs? Bigger here is meant in terms of maybe small games/applications. Not huge Cloud infrastructure...
Are there any good books/articles/tutorials that go specifically into these kinds of problems?
Thanks for any advice! Best regards!