So far I've made two largish bits of code: Meowpocalypse (a text based choose your own adventure I made before arriving at code school as an exercise in using classes) and this budget app.
The game is about 1000 lines long. The budget app is about 500 lines with another 100 in an associated module I wrote that ensures input data. In other words - big projects for a beginner, not so big for production. They also don't have to interface with anyone else's code.
I've read about how big software programs work in that there can be far more lines of code than any one person can understand or, really, work with. You have, in essence, enormous, highly complex blocks with, ideally, very simple interfaces. Information is passed from block to block at the interface...but the internal workings of the blocks is often opaque. As a programmer, you may have no more than a general idea of what other people have made. All you know is that data in a certain form is passed into the realm you can influence, and you must see that your code-minions pass it out to right place at the right time and in the right format.
I got a tiny taste of that in my own somewhat complex budget app. Things that I hard-coded, like categories of information to collect, have a strong potential to break functions in other parts of the script. For example: my app can open a csv and construct a dictionary from the data there-in. Every function that specifies values or attributes rather than pulling them from the state variable is a risk of failure. A string that contains the column headers, for example, is difficult to alter if the column titles are changed by some other part of the program. The more dynamic (built as-needed from a data source that every function can access) the processes are, the less likely they are to suffer a conflict with how other parts of the machine are built.
There's more, but it's late again, and we're doing more with recursion tomorrow.
No comments:
Post a Comment