Color Coding Microflow Actions

1
We're trying to establish some kind of protocol for the team and we would like use color coding to improve the readability of our microflows. We're particularly interested in increasing our ability to spot bugs and performance issues.  I don't think it would be beneficial to color everything because a rainbow-colored microflow might actually be hard to read as well. But I could be wrong :) So I thought it would be interesting to collect some thoughts of other people on this subject.  I was thinking of the following protocol: GREEN: Commiting objects (or changing objects with commit). YELLOW: Creating or changing objects (without commit). ORANGE: Retrieving objects from Database. (Not sure if retrieves by associations are also worth marking). RED: Deleting objects. The same logic could be applied to submicroflow calls: green for submicroflows that include a commit, yellow for those that create/change objects, orange for the one that include a retrieve, red for the ones that include a delete. Thoughts?
asked
3 answers
8

Wow! Surprised to hear people loathe it. We use it extensively and I think it is really useful. Especially commits, Sub MF’s, logging and usages of non persistent entities / local variables / lists in my opinion are really helpfull in more complex applications.

Up to you what color to pick, but make sure it is not a colorfest. That indeed would make it less helpful. Keeping it to above mentioned activities will definitely not do that, so go for it :)

answered
2

I don't see a point in color coding different types of actions that can already be differentiated by icons or other indicators. For the things that you have mentioned, proper naming of microflows + using annotations is probably more useful.

a place where I found color coding useful is:

  • In a complex validation/process microflow mark actions that set an error status red or that set a valid status green
  • we've also used this in longer microflows to highlight specific actions belonging together

There are certainly other places where it makes sense to use colors, but you should use them sparingly as these things are often causing a lot more work than expected.

answered
1

I agree with Rom. Coloring seems like extra work for developers and, especially if you're using colors for things like commits, creates, etc, the modeler already has icons that make those types of activities easier to spot. One area that you mentioned where color may help is in subflows, since those icons don't necessarily roll up to the subflow call. 

I have seen customers color sections of microflows that are changed as part of a refactor or a specific enhancement where the colored activities are changed with a particular annotations, and that seemed to work well, too.

answered