I was recently viewing the Pluralsight course Making the Business Case For Best Practices by Erik Dietrich, and I really found this to be an excellent slide. This is Erik's view of the common best practices in software development today, and in my descriptions below I'll try to explain how these ideas can be applied to Angular front-end development.
Agile - often an overused buzzword and seems to mean different things to different people, I prefer the XP style of agile that emphasizes pair programming and unit testing. I also like stand-up meetings and kanban boards.
Automated Testing - This is where Angular really shines. It was built with testing in mind, and the dependency injection really makes it nice to pull in different pieces individually as you need them. Karma and Protractor are stable reliable, and just awesome command line tools for running unit tests and e2e tests, respectively.
TDD - Test driven development is the art of writing the unit tests as you write the production code. It prescribes a test-first philosophy which is an interesting method for "testing your tests". I highly recommend this for advanced programmers as it can lead so high quality, border-line bulletproof code. The only downside is that it can be tough to learn and requires advanced knowledge of both the specific language framework you are programming in and unit testing in general.
Continuous Integration - This is all about having unit tests (and e2e) tests that are run against code as it is pushed to the repository. This can be excellent for large teams, live web apps, and for running more intense automated tests than when developing locally (for example, running the e2e tests against every possible browser).
Design Patterns - "Clean code and clean tests" is what we're after, and clean code means structure your files (and directories) in a sensible manner that separates concerns, is maintainable, and is understandable to a dev with reasonable experience looking at your project for the first time. Luckily, the Angular 1 syntax guides us towards the best practices for designing your Angular code.
Code Reviews - This is more of a culture thing in your company. The senior developers need to know what's going on and what other programmers are doing. Reading some else's code and understanding what they were thinking can be difficult (especially if it's not exactly well-written code). Having code reviews helps to improve the reviewer's efficiency, teaches the developer being reviewed where he or she can make improvements, and just gets everyone on the same page and speaking the same ubiquitous language.
Pair Programming - This is an activity I really love doing. Honestly, I wish there was a bar / lounge area where you could go in and pair program with other people who just showed up and wanted to pair program also. Being able to bounce ideas off someone else, to see things from a different perspective, and just to have your typos / mistakes quickly spotted makes programming incredibly faster, more effective, and more fun.
Automated Builds - You definitely don't want to be manually prepping your files for deployment. For most of us, such an idea seems crazy because we are spoiled by our tasks runners. For Angular 1 projects I use gulp (usually scaffolded from the Gulp-Angular generator) to build the finished project. For me the build step is the default gulp task so I just run gulp and dist directory is created with all of the compiled, pre-processed, and minified files ready to be uploaded onto a server.
The posts on this site are written and maintained by Jim Lynch. About Jim...