| Design Guide |
| ============ |
| |
| Make the obvious way the right way |
| ---------------------------------- |
| |
| A developer coming to a new-to-them project should be able to quickly learn the |
| correct way to interact with a project's code, and the "path of least |
| resistance" should also be the correct way to make changes to a project. |
| |
| Build on the shoulders of giants |
| --------------------------------- |
| |
| Another way of saying this is: "Avoid reinventing the wheel". |
| |
| If there is (acceptably licensed and maintained) code out available out there |
| that could be used to accomplish a task, consider using it. |
| |
| External Dependencies |
| --------------------- |
| |
| Upstream code changes over time, and you should design your projects to be able |
| to deal with this change. |
| |
| |
| Lifecycle |
| """"""""" |
| |
| Testing against new versions |
| '''''''''''''''''''''''''''' |
| |
| You should embrace tools that allow you to test against upgraded dependencies. |
| |
| One example of a tool that lets you do this easily is ``tox``, which can handle |
| running a unit test suite against multiple versions of the Python language. |