Having a look at a piece of work I built for client reflectively. I noticed that I had early on opted for a bottom-up approach to an implementation where I control a remote machine.
Python script ~ 300 lines
Powershell script > 500 lines
Mobile API ~ 10 lines <= where all the work happens
If I had written it from top-down and written around 500 lines of Python, it would have shifted the balance but left us with around 200 lines of Powershell and a large performance hit per step in the test because the Python code cannot cache the Mobile API remote session connections. Every test probe or prod, would be a round trip and would need a new connection. My biggest regret is not sticking to my guns and moving more code to the Powershell side because it's easier to manually run pieces of Powershell as scriptlets when manually verifying. You could probably run python functions in the Python console/ide as manual steps too, but I need to stick to my expertise more often in future. Anyway, the Python code balance is annoying because maintainers do have to learn 2 languages. Top down would have been easier to maintain by nature.
Bottom up is not a design Pattern
I said to myself that it was wrong to have gone that way about it, because bottom up meant starting from a windows mobile API and then wrapping it in Powershell, and then wrapping that in a Python unittest. In balance it's a bit light on Python which means anyone reading or maintaining needs to learn a lot of Powershell. The powershell scripting is managing a remote connection session across test steps. This balance is a side effect of bottom-up.Python script ~ 300 lines
Powershell script > 500 lines
Mobile API ~ 10 lines <= where all the work happens
If I had written it from top-down and written around 500 lines of Python, it would have shifted the balance but left us with around 200 lines of Powershell and a large performance hit per step in the test because the Python code cannot cache the Mobile API remote session connections. Every test probe or prod, would be a round trip and would need a new connection. My biggest regret is not sticking to my guns and moving more code to the Powershell side because it's easier to manually run pieces of Powershell as scriptlets when manually verifying. You could probably run python functions in the Python console/ide as manual steps too, but I need to stick to my expertise more often in future. Anyway, the Python code balance is annoying because maintainers do have to learn 2 languages. Top down would have been easier to maintain by nature.
Strangle Hold
I am enjoying the Python learning, which was part of the reason for my bottom-up by starting in Powershell, and learning the Python language all over again in the background while I worked my way up. I could not have commanded the Python well enough to start there I suspect. Quite happy with the outcome in terms of the refreshing of my very stale and super-basic Python. But would do it the other way if I did a similar project again.
Wierdest thing is that Python seems to be language lawyer territory in terms of style far more than in terms of looks than for example C code is lawyered over, where performance is 50% of the game. Snakebite on the other hand is 50% of the Python game. By snakebite I mean pretty pythonic code. A lot of time is spent making code look like it is pretty. Python actually has keywords and syntax (above and beyond the indentation rule) to help you make the code pretty. A pity because the excellent pylint tool is actually two tools in one, style and grammar, and because pylint parses the code and the references or lack of usage, which you don't want often. And so I find myself disabling some of the pylint warnings that are not so much about code prettiness, but rather syntactic rules, which should have been totally separated in the debate. I want my code to compile, before I want it to look like it wants to be eaten!
Comments
Post a Comment