If the Bible story happens today

    This is a common question any team/project will have to address — how to structure the knowledge we know of a project so that we are not missing things? Each project/application, of course, is different. But the overall is actually quite common. Here is a structure I'm proposing that is applicable not only during initial learning phase, but can guide the design and development as well.

    Take an example that we are building a portal, which has frontend and backend — the backend is showing more levels than the frontend, the idea is the same:

    Portal
      Frontend
        Design
        Build/packaging
        Dev breakdown (incl. unit tests)
        Tests
    
      Backend
        Design
          Logical view => components
                       => key technology stack
          Components
            REST API
            web portal
            another..
            another..
    
    
        Build/packaging
          for dev
          for production => CICD integration   
    
    
        Dev breakdown (incl. unit tests)
          component A
          component B
          ....
    
    
        Tests
          all non-dev covered tests => QA
            code static analysis (LINT, style check, best practice)
            scenario tests (incl. "integration" tests)
          machinary => CICD integration
    

    The key is to compose a design/component view so that we can categorize work into component, which also speaks of key technology/implementation. Until this is identified, we can say for sure we don't have 100% coverage of this code base yet.

    — by Feng Xia

    Related:

      2019-07-03
    ECMAScript

    Isn't this confusing — ECMAScript, ES2015, ES6, Javascript,

      2019-04-30
    Pandoc workflow

    Pandoc is awesome. I have been using it for the last six months now writing a reference architecture document for work. Here is some...