Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
OutSystemsベストプラクティス紹介
Search
out-developers
January 29, 2020
Programming
1.3k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
OutSystemsベストプラクティス紹介
out-developers
January 29, 2020
More Decks by out-developers
See All by out-developers
OutSystems愛知ユーザー会#3使用 回答例
outdevelopers
0
250
Other Decks in Programming
See All in Programming
ビデオ通話が繋がる0.2秒で何が起きているのか
supurazako
2
170
torikago - Ruby::Boxで照らすモジュラモノリスの実行境界
se4weed
1
330
php-fpmのプロセスが枯渇した日-調査・対処・そして本当にやるべきだったこと-
shibuchaaaan
0
210
5分で問診!Composer セキュリティ健康診断
codmoninc
0
850
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
480
PHP Application における Kubernetes 内 gRPC 通信
ganchiku
0
580
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
530
変わらないものが、変わるものを決める — 意図駆動開発 × イベントソーシング × イミュータブル | What Doesn't Change Decides What Can — IDD × Event Sourcing × Immutability
tomohisa
0
1.2k
Go言語とトイモデルで学ぶTransformerの気持ち / fukuokago23-transformer
monochromegane
0
160
「人を評価する AI」の設計と実装
ryoyanara
0
140
【やさしく解説 設計編・中級 #4】ルールの寿命と、システムの年輪
panda728
PRO
2
180
これって Effect でできたのでは? / TSKaigi Mashup Kansai #2
susisu
0
140
Featured
See All Featured
KATA
mclloyd
PRO
35
15k
My Coaching Mixtape
mlcsv
0
190
Practical Orchestrator
shlominoach
191
12k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
66
57k
A better future with KSS
kneath
240
18k
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
560
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
480
Reality Check: Gamification 10 Years Later
codingconduct
0
2.2k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
23k
Abbi's Birthday
coloredviolet
3
9.1k
Money Talks: Using Revenue to Get Sh*t Done
nikkihalliwell
0
450
Transcript
OutSystemsベストプラクティスの紹介
はじめに ここで紹介する内容はあくまで推奨事項です 必ずそうしないとダメ ということではないので、 開発環境に合わせて調整してください
OutSystemsのホームページにあり
命名規則 誰が見ても役割を理解できるようにしよう 意味がわかりやすい言葉を使おう (例:CheckUser→IsUser) 外部キーは「id」を付けよう (例: 「CustomerId」) パスカルケースを使用する 最初の文字と単語の先頭を大文字にする表記方法 (「例:ZipCode)
コーディング規約 後から見たときにロジックなどわかりやすいようにする アクションフローは縦方向にして、整理する ハードコーディングをしない 会計=製品単価*購入数+製品単価*購入数*0.1 代わりに静的エンティティを使用する
重複した処理は部品化して再利用する ロジックで重複箇所→ユーザーアクションを使用 画面の重複箇所→WebBlockを使用して画面の一部 を再利用
クエリ(AggregateやSQL) 基本はAggregateを使用する SQLは必要なときのみに使用する 何回もAggregateを使うより SQLを1回使って求めているデータが取得ならSQL 実行する必要があるクエリの数は最小限にする
ロジック 使用していない、重複しているものは削除する 画面のPreparationを簡素化する 画面の読み込み速度を向上させるため ノード数は10まで位を目安にする 頻繁に変更する変数としてサイトプロパティを使用し ない サイトプロパティの変更は時間がかかる
アーキテクチャを見直す • 他のモジュールのEntityやWebBlockは ManageDependenciesから参照できる • 役割によってモジュールを分割して、 必要なモジュールを参照して開発していく
モジュールのアーキテクチャ • 4 layersCampasを使用 • オーケストレーション:ダッシュボード • エンドユーザ:ユーザーが使用する画面 • コア:データやビジネスロジック
• ライブラリ:外部システムのコネクタとか 他システムで使用できるもの
まとめ 誰から見ても理解しやすいようにしよう 処理の高速化のため、管理のため簡素にしよう 後から変更しやすいシステムを作ろう