Dev
This page will house my developement work flow. I tend to get a large chunk of time to work on a lot of programming projects and then nothing for a long time. It is good and bad. I am always hungry to start again because I don't get burnt out. I learn a lot then forget a good portion of it because I am not actively using it. This section is to combat the second part, a place to put things and ideas so I don't lose them. A place to document what works for me.
Project Structure
First things first. Layout a project structure. It doesn't have to be exactly what it ends up looking like but giving some forethought to the code organization, classes, data structures, functions, variables, data bases, etc. will save you a significant amount of time in the long run. Project Structure Examples:
Project Organization Tutorial:
Get the folder set up right. Nice and clean and organized. If you get tired of doing this which is very likely, you are a lazy programmer after all, there are projects like cookiecutter. But you have to overcome the short term laziness to learn how the tool, ya making an investment in the long term laziness. Gotta think about and plan for the future. Links:
Testing
Make a freaking testing folder and use it. Don't wait until you have
half or more of the production code typed out. Write a function, test a
function. Write class method, test a class method.
python -m unittest -f test.test_some_stuff
The reason to write test code so that when it is crunch time and people
ask for changes you can make them and easily know if the behavior of the
rest of the code is still correct.
It also helps to find bugs before you use tape and paperclips to stick
everything together.
It is the most pleasant experience to make some changes to your code
base. Run one command from the commandline and know that
everything is ok. There is no manually running examples at it everytime a
change is made. You write the example once to run at the production code
and you are done. (Unless you find more examples.)
Testing Part Dos
Write a basic test to check all the functions, class, and methods. Then write tests for separate worked examples that show that the software actually works real problems correctly. These can be examples from textbooks, papers, or examples that are worked by you by hand. This expands on the "Unless you find more examples." In structural engineering it is not so easy to use random tests to test the software. One must input the example in a very deliberate way and test to make sure the output is correct. The more examples that are tested the more confidence you can have that their software works correctly. Sure it takes a while to find good examples and write the code to automate the testing but then you have one more problem that you know is correct. It becomes part of the testing suite for all tests run in the future.
Documentation
How are you going to remember how your software works in 3 months, or 6 months, or a year if you don't explain in plain english what it is doing when you write it? Docstrings are on par in importance with testing. Not only do you have to test the software you have to know how it works. If you ever want someone other than yourself to use the software they have to learn how it works. In 3 months could you read just the code you wrote and figure out what it's doing? Probably not. Don't expect someone who is coming to the code base new to figure out something you wrote. Explain it to them via the documentation.
Git and Github
If you have made it this far then you are probably actually going to
start writing something if you haven't already (stop it, stop it right
now).
Go start a git repo right now. Even if it is just a local one.
git init
Now commit to it when you make changes. The more often the better. If it is
a big change use,
git commit
and actually put some information in the commit message. If you are just
making little changes I guess it would be ok to use the other one,
git commit -m "Message goes here"
but use it sparingly.