...
LearningBuilder is a large, but reasonably well-organized, monolith consisting of a handful of core assemblies plus the web project. Our long-term vision is less monolithic and more a federation of independent services working together. We haven't fully adopted a SPA framework yet but are starting to leverage Vue.js in newer parts of the app.
We use:
- ASP.NET MVC
- Vue.js
- SQL Server 20142016+
- SQL Server Service Broker / RabbitMQ, for messaging
- ElasticSearch, for publicly-available search features
- SASS, to take some pain out of CSS
- Ruby and Powershell, to automate our development process
...
All database schema changes are fully scripted (using a homegrown utility) and are source-controlled like everything else. We maintain a shared database snapshot in a known good state so that you're only ever one command-line tool away from restoring a local database with staged data.
Most of our Our legacy features use an ORM called NHibernate to interact with the database. Queries are typically expressed using the NH LINQ provider, but when necessary we'll hand-roll a query to optimize performance. Newer features use Vue.js.
We also work with stored procedures a decent amount; LearningBuilder is a very configurable product, and sprocs are often used as a way of injecting client-specific business logic into pre-defined "hooks" in the app.
...
We have invested heavily in a library of "data helpers" that assist with setting up test data, ensuring that it remains fairly easy to write new automated tests even as the product complexity continues to grow.
Source Control / CI
Currently we use SVN. We're hoping to switch to Git or Bitbucket soonWe use Git and Bitbucket.
Our general pattern is that most tasks are performed in feature branches and then merged into trunk once they are stable and are code-reviewed. We maintain release branches so that critical changes can be merged across multiple lines of development if needed.
...
In addition to the core corporate values (outlined below), the technical team believes in the following:
- "Go slow to go fast". We are interested in long-term stable velocity over time. We achieve that by paying attention to fundamentals, writing clean code, and sweating the details.
- Diversity of thought / consistency of output. We value different ideas and problem solving strategies, but the code shouldn't suffer from multiple-personality disorder.
Product features should be thin wrappers of business logic around a rich application framework. This means we prefer reusable components and patterns over feature-specific "stuff"believe that consistently-applied patterns helps us manage complexity. - Always Build Components. We like to build product features on top of reusable components, patterns and frameworks that minimize and clarify the feature-specific code. We invest in helpers, wrappers, utilities, etc to eliminate as much boilerplate and repetition as possible.
- Automate all the things - ain't nobody got time to be doing repetitive tasks by hand!
- Innovate deliberately and intentionally. We all love shiny new stuff, but not every task is the right time to introduce brand new ways of doing things. But when it is the right time, then look for the evolutionary leaps and not the incremental shifts.
- "It's better to build half a feature than a half-assed feature." (See "go slow to go fast")
- Scope is negotiable; cleanliness is not. Nothing is more important than writing clean code, that clearly expresses its intent, and is as simple as it can be, because that is the foundation upon which all future progress will be made. (See "go slow to go fast")
...