rappor

nt your tests to calcify the structure of your code. I've seen that happen a lot with fine-grained testing, and it's a big pitfall. I would say at the beginning, I write unit tests for tricky parts, but don't aim for 100% unit test coverage. I aim more for high integration test coverage. And then at the end of the project, when you are fixing bugs, that is when you can do fine-grained testing without worrying about making a mess of your code. Here I did parameterize random() (irr_rand), because it's very important to the function of the code and needs to be tested: https://github.com/google/rappor/blob/master/client/python/r... So it all depends on the context. That's why I say it takes some practice. It takes practice to: - not end up with more than 3-4 parameters for each class. - not end up with too many classes. Java code seems to fall into this. A lot of things are just functions with dependencies. Actually this style I think reduces the need for classes -- they are your parameters rather than being your context! - not structuring your code as a deep tree of calls. Instead it should be a relatively flat object graph. A relatively static "Object graph" is really the idea that distinguishes OOP from "structured programming" (i.e. a pyramid). I think I would differ with you in that I don't think DI and functional programming are that different. I think they are trying to get at the same core idea. Things I ALMOST NEVER use in Python: - setters and getters. - Especially, setters for dependency injection. I always pass params through constructors. - decorators. This can always be accomplished with composition of objects. I find that style a lot more readable. decorators are non-trivial code at the global level, when it really should be in main(). - classmethod and staticmethod. Static methods should just be functions. Class method is kind of a hack for singleton-like behavior. - As mentioned, the singleton pattern is banned. Singletons are just classes you instantiate once. I like that this style gets rid of a lot of concepts: thread local (as mentioned above), explicit singleton pattern, and "static/class methods". Also I think it's true that Java's static type system might get in the way a little bit, but I don't have a strong conclusion on that. However, I also wish Python were a little more strict. I don't use 90% of the dynamism of classes.

tests in Python, JS, R, C++, etc. - when I fix bugs later, I tend to reproduce it with a system test. This makes bug fixing easy. Then I write a unit test to zero in on the broken part, and sure it never comes back. I probably save 70% lines of test code, while delivering the same level of quality. A system test can be fast and can substitute for a lot of unit tests, and it helps you not ossify your code structure too early. I don't have an example of that online, but you can see 880 lines of shell in the root dir here: https://github.com/google/rappor Granted, this is more like scientific / batch code than web / backend stuff, but I assure you I follow the same strategy in the latter case. It's basically using Unix as leverage. One thing I would notice about the scripts is how the last line is "$@". That runs the function $0 with the args $1 ... $9. This is a very handy trick that helps keep everything modular and independently executable. I use shell scripts for all these things: - building code (in C, JS, Python, or any language) - testing code (running unit tests in multiple languages, and also system tests, constructing test data) - deploying code - sys admin; setting up servers (e.g. setup.sh in the repo), backup, managing log files - building docs; making static web sites - building config files and data files (e.g. lists of URLs) My assertion is that, combined, these things take up MORE time than actually writing code! If you can speed them up, you will be more productive at "coding" overall. In addition, using the same tool (bash) for all of them makes you more productive (once you have climbed the admittedly substantial learning curve). I'm not a fan of all these language-specific build tools now. I don't even use make that much; my first choice is bash! Here is one concrete example of shell minimalism, which helps you get things done faster. Think about the common situation of having a {star}_test.py files in many directories, and you want to run them all together as a test suite. I am embarrassed to say that at one point I spent 2 or 3 days researching and implementing some kind of Python test runner (this was over 10 years ago). I think people do it now with "nose" or something. Here is my preferred solution: find . -name {star}_test.py | sh -x -e Or if you need parallelism, something like: find . -name {star}_test.py | xargs --verbose -n 1 -P 10 -- sh -c ({star} should be asterisk; HN is not letting me escape those) That's it. It doesn't necessarily give you pretty output, but it's what you need to deliver working software. Add one line to a bash script and be done with it, rather than getting distracted by yak shaving. The shell scripts may not look that impressive until you think about what they actually save -- what common alternatives are. One line CAN actually save you 2 or 3 days of time; this is not the only time I've experienced this. The overall point is that I used to spend a lot of time on tooling and automation (yak shaving), because I wanted a certain level of code quality and iteration speed. But now I do most of those things with a small, sharp tool -- bash -- and I find it saves a lot of time. I get in the zone and don't get distracted from the main task.