1117
1
2つのワークフローでほとんど同じ処理をするものあがります。
この時、条件分岐で処理をわければ良いかと思いましたが、
先に条件分岐をしてしまうと、true のときと elseのときで中身がほとんど同じということになってしまうので都度違う処理のところだけを条件分岐にしようかと思いましたが、煩雑になってしまいベストプラクティスから遠ざかってしまうとも思いました。
・一番最初のファイルを作るところから処理が違う
・作ったファイルに対する処理はほとんど同じ
・ほとんど同じ処理の中でも違うところがところどころある
このような条件の時、皆様ならどのようにワークフローを作りますか?
@1117 様
こういう処理のベストプラクティスは私も気になります。
①一番最初のファイルを作るところから処理が違う
②作ったファイルに対する処理はほとんど同じ
③ほとんど同じ処理の中でも違うところがところどころある
だとすると、まずフローチャート上に
①ファイルを作るフローを作成しStartから繋げます
②その後作成したファイルへの処理フローを作り繋げます
③に関しては条件分岐で分けていいのかなと思います。
以上で、先に条件分岐してしまうと、true のときと elseのときで中身がほとんど同じという問題は
解決できると思います。
各フローの中についてはどのぐらいの分岐があるか分からないので何とも言えませんが、、
他の方の考えも知りたいですね。
2 Likes
@1117 さん
先ず、 ほとんど同じ処理があっても、別々業務なら、
メンテナンスと二次開発などのために、
そのまま、別々にしてもよいと思います。
同じ処理がある場合の一般的なベストプラクティスは、
子ワークフローを抽出して、
複数な場所に導入することです。
ところどころある違い場所に対して、引数より分岐にします。
2 Likes
先に条件分岐で2処理に分けた場合のメリットは、互いに独立しているので個別の仕様変更に対応しやすい(個別に処理が分かれているのでプログラムが見やすい)。デメリットは共通的な変更も2処理に記述が必要(共通ルーチンにできれば行数は減るが)。
大きな処理の中に各個条件を入れる場合は、上記の逆となる。
この部分全体の処理が小さいなら、どちらでもかまわない(何か理由が思いつけばそちらを選択)。
処理全体が大きくなってくると、後者は処理を追うのが困難になってくる。頻繁にスクロールしたり、関係のある処理を抜粋しながら見たりと。
なので、大きな処理になる(なりそう)と予測されるなら前者をお勧めします。
(ほぼ同じ処理が続くと予想されるなら後者もあり)
結局は将来的な仕様追加変更予想とメリット、デメリットから判断となるのですが。
1 Like