* Complexity: * More functionality = more code * More interaction between pieces of code * Increase in potential code paths
* Managing all that can be difficult * How do you structure things? * How do you ensure you know where to find pieces of functionality
* How do you manage access * How do you manage collaboration and communication? * How do you stop clashes e.g. code conflicts?
* As code and practices become inconsistent it: * Different people attempting the same thing in different ways * Becomes difficult to work out where functionality is implemented * Potentially duplicate effort * Creating functionality that does more than one thing * Accessing functionality that is unrelated * CSS for one component impacting another * ex. Gmail input el string parsing being used in the email composer
* We invert the problems: * Inconsistency => Consistency * Complexity => Simplicity * Separation of concerns * presentation layer, business logic layer, data access layer, persistence layer * HTML (content + a bit of structure), CSS (styling), JavaScript (behaviour) * Code - One bit of code should do a single thing (SRP) * Tooling can take many forms e.g. * Frameworks * Toolkits * Dev tools e.g. Browser dev tools * Libraries * Workflow enablers
* It's for consistency * declarations * statements * naming conventions * comments
* Things like Object definitions
* JavaScript is a dynamic language * It's highly flexable * This is a great gift, as well as a curse * So many ways of achieving the same thing * If you allow JavaScript to be used in all possible ways your codebase will become very difficult to follow
* Consistency: * The vast majority of developers are familiar with OOP * Proven to scale in the Enterprise * This is nothing new to JavaScript, but it works * Simplicity * Human-being understand it at a conceptual level * Promotes decoupling * Single Responsibility Principle * JS is a prototype-based programming language so we use a library (Topiarist) to achieve this * `class` is coming in ECMAScript 6
* Anybody that understands OO will understand the code * Developed to solve software quality in complex systems * Modularity: Substitutability (Liskov substitution principle)
* We use classical OOP
* You want to organise your code in some way * You don't want code definitions to accidentally overwrite other definitions (global namespace) * You want to be able to share code in modules or libraries * And a way of loading / bundling files beyond manually managed includes
* We used to have a tool that would generate the namespaces in JS before any of the files were loaded based on convention - folder structure
* Borrowing from Node.js * Want to focus on writing code related to app functionality * Not writing code which works around the runtime - the browser
* The tooling add code to handle the environment
* SoC * Code - already achieved through OOP * How: app architecture * How: assets? * Loose coupling - the constituents of our architecture know as little about other components as possible * High cohesion - our constituents of our app to be grouped to provide a single well-defined piece of functionality * Divide & Conquer: Running theme of creating small pieces of decoupled functionality. * Think of this as dividing your web app into simple pieces of functionality - throughout * In order to conquer the challenges that you face when building such apps. * Our code is close to being: * S - Single responsiblity principle * O - Open/closed principle * L - Liskov substitution principle * I - Interface segregation principle * D - Dependency inversion principle SOLID wikipedia defintion
* UI Components * MVVM * Libraries * Reusable components * Useful shared functionality e.g. WHAT? * Blades - application feature * EventHub * Services * Aspects
* Assets should be grouped with the code associated with a piece of functionality within the app
* As with JS code, dependency analysis is used
* Even at that level we want SoC * How do we achieve that?
* Our components are MV* components * We follow the MVVM architectual pattern within our apps. * I'm not going to go into the details here. * Will cover under "Code Quality"
* We have SoC * High Cohesion * No sign of loose compling yet * That's an app architecture level thing
Again we have: * SoC * High Cohesion * No sign of loose compling yet * That's an app architecture level thing
* Run components/blades in isolation * Great for the development process * For building integration tests, and writing a lot of the underlying code * Stub and mock out Services * Stub and mock Event Hub interactions
* It's pretty obvious that for a JS app to scale - for it to be maintainable - it has to be well tested. * How do we go about this.
* All the things we're already doing result in it being very easy to test our code * Keeping things simple and being consistent naturally reduces the likelihood of mistakes
* Tooling & libraries are the glue to keep that complexity at bay * It helps productivity by doing things for you * It enforces constraints to ensure standards are met