ci kb How to Make Apps Faster as Developer

Avoid Repeating Yourself

  1. Make your code readable.
    • Avoid spaghetti code. Code that is hard to read and maintain leads to inefficient and duplicate code because it is easier to add new, duplicate code than to figure out how to elegantly integrate new code into the existing spaghetti code.
  2. Put one-time variable assignments into the ScriptInitialization subroutine that is called once at the beginning of app execution lifetime. This includes…
    • Constants.
    • Default value retrieval.
    • Dataset loads. (For example, lists of reason codes or freight codes.)
  3. Avoid downloading from the same table more than once.
    • If you need to set a variable(s) from a download, look to see if the table has already been downloaded earlier in the code (with appropriate criteria).
  4. Replace multiple sequential API calls with a wrapper API.
    • Avoid premature optimization …make sure it is necessary for the specific performance case before creating a wrapper.
  5. Cache values.
    • Rather than downloading and updating a dataset for each app cycle, if possible, consider doing a download once that will be needed multiple times if the data will not change during app execution lifetime.  This data can be refreshed each time the app is loaded.
    • Then just work on the original downloaded dataset if the data will not change during processing / during app execution lifetime.
    • For example, a list of cartons to be picked by one picker.

Working with Datasets

  1. Avoid processing of large datasets. Especially when updates are necessary.
  2. Avoid using unnecessary mobile client (internal) tables.
    • Mobile client tables are great. They can be necessary when:
      • Merging/combining data from multiple sources.
      • Collecting data for delayed processing. For example:
        • User input
        • Error details accumulation

Function Calls

  1. Call functions asynchronously, as appropriate.
    • For example, for print label or print document calls (because the absence of the printed label or document is its own indication of an error).
  2. Do not log transaction to the transaction log.
    • This saves the (very small) hit required to insert and update the transaction to the DSI Transaction Log table.  The DSI system tracks the transaction in memory.
    • Do this for functions and SQL transactions the history is not required for.
      • For example, GetAuditInfo and ConvertDateToJulian.
    • Note: You could include a config element to switch writing to the Transaction Log on or off.