This is one a approach you can use an example development guide. The goal of this list is provide some things to think about when designing your own, and to highlight some of the components which make scaling and model development easier. Feel free to pick and choose the parts that make the most sense for your team.
All of our LookML developers must follow these rules to ensure consistency across contributors and improve interpretability of our internal models. This gives each contributor the ability to make sure that our internal model stays up-and-running while we continue to build our internal analytic capabilities and capacity.
- Add your name, date of original creation, and purpose at the top of each view you create
- Title the view with
sub-organization.viewso that the file format is:
- Add your name, date of creation, and a description for each new field
- Flag one-offs and test fields
- Organize and hide one-off explores in one-off view files
- Resolve all LookML warnings and errors before committing
- Avoid extending an already-extended object
- Establish “owners” for views, explores, and/or models
- When committing new code, tag the original creator (or owner) of that field, view, and/or explore in the pull request
- On PDTs
*Any new model / view file created will be discussed during weekly code review sessions
1. Add your name, date of original creation, and purpose at the top of each view
We want to make sure everyone knows who to go to when we inevitably start scratching our heads at certain files. When you create a new view file, please add your name, date of creation, and purpose at the top of the view file as seen in the following screenshot:
2. Title the view with
sub-organization.view so that the file format is:
This let’s us use wildcards,
include: sub-organization.*.view.lkml all of the view files for the sub-organization’s model. Some examples are:
marketing.campaigns.view.lkml - would be used for the marketing model
salesforce.leads.view.lkml - would be used for a sales model, or even more specifically the salesforce model
dcl.chat_reviews - would be used by a support model for quality control
3. Add your name, date of creation, and a description for each new field
Each LookML field must have a description no matter how trivial the field’s title and/or label is. Please add your name, date, and a description of what the field does in the field definition as follows:
If it’s a single field
If it’s a set of fields
4. Flag one-offs and test fields
_test to all one-off fields with
b. Add prefix
oo_ to all one-off derived tables
5. Organize and hide one-off explores in one-off view files
One-off explores should exist in a one-off view file created by the explore owner. If you create a one-off explore, please hide it from the wider audience, and indicate it as such in the label when you commit to production. You can use the hidden parameter to do this.
6. Resolve all LookML warnings and errors before committing
Be a good Looker Don’t commit code without making sure ALL errors and warnings are resolved. Validate and test often so it’s easy to narrow down where the error is stemming from, and so you don’t overwhelm yourself with hundreds of errors.
7. Avoid extending an already-extended object.
Extending an already extended explore view can cause a lot of debugging confusion. Don’t make your models into Escherian mazes.
8. Establish “owners” for views, explores, and/or models
Depending on the size and complexity of your views, explores, and models, designate owners. Not only are they the people to go to if you have a question, but they’re also responsible for validating and maintaining the files.
9. When committing new code, tag the original creator (or owner) of that field, view, and/or explore in the pull request
Notifying the owner of your changes makes it easier for them to clarify any points, add any suggestions, and/or review your code.
10. On PDTs
If you must build PDTs, you must consult with your lead developer on creating or adding a datagroup to your PDT. Please provide a brief description in your pull request (PR) as to why the datagroup’s creation is merited, or why you selected a specific datagroup.