Technological Due Diligence
Foreign keys are essential to all non-trivial database schemas, yet their performance aspects are often overlooked. In this article, we’ll shed more light on the subject.
The static view encompasses all artifacts created during the development process. That includes production code, test code, documentation, and other assets.
Documentation, when present, is a great starting point for understanding what the system is about.
Third-party code in form of depencencies is a critical aspect of every software project. They enable development progress without having to reinvent the wheel but come with several risks that must be identified and addressed.
An issue overlooked by the majority of engineers is licensing. It’s so easy to add another dependency to a project that most don’t event think about legal implications of doing so. The benefit is obvious and immediate. The risk is distant and uncertain. However, even a single dependency with an appropriately crafted license could spell doom to the project. What would you do if the license required you to give access to the source code to the license holder (in that case the library author)? To make matters more complicated, dependencies can have their own dependencies. You must ensure proper licensing of direct and indirect licenses.
The other important aspect of dependencies is security. No code is perfect so all dependencies have security vulnerabilities discovered from time to time. It’s important to update them prompty or, if the dependency is unmaintained, mitigate the issue differently. That aspect is also easy to neglect but its importance warrants constant monitoring.
My first step when learning a new app is to look at the datamodel. It’s much easier to understand the code when you understand what kind of data it operates upon. You should look at the database schema and preferrably make an entity-relationship diagram for more visual comprehension. That phase can also be broken down into steps.
First, you need to understand what kind of data is stored and where. For example, if there are tables
invoices and there’s a foreign key from the latter to the former then you know invoices somewhat belong to organizations (e.g. they’re sent or received by them). It’s usually helpful to break the database schema down into subschemas. For example, a document sharing system may have a subschemas for user accounts, documents, and permissions. You should also be able to identify tables related to the core value of the app.
Second, you should have a closer look at individual tables, especially those deemed important, and understand column definitions. Look for default values, enum types, and constraints like foreign keys,
NOT NULL, and others. In the
invoices example above, if the
state column can assume values like
void then it tells you quite a lot about XXX.
After understanding the schema, we can turn our attention to the test suite. In an ideal world, it should be able to teach us a lot about the expected product behavior. Unfortunately, in the real world it’s often quite unhelpful if you lack that understanding – a test case entitled
invoice payments work correctly don’t tell you much what “correctly” actually means. If that’s the case then I recommend you go to production code first and look at the test suite second. Otherwise, read on.
Copyright © 2019-2022 Greg Navis. All rights reserved.