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
エンジニアのための消す技術〜何かを生み出すエンジニアが消すことに向き合ってみよう〜
Search
kawahara kenta
October 15, 2024
Programming
0
47
エンジニアのための消す技術〜何かを生み出すエンジニアが消すことに向き合ってみよう〜
kawahara kenta
October 15, 2024
Tweet
Share
More Decks by kawahara kenta
See All by kawahara kenta
AWS CDKを始める際に コミュニティの知見が大いに役立った話
kenpi13
1
56
Amazon Bedrock Flows使ってみた ローコードでお手軽生成AIフロー作成!
kenpi13
0
45
Step Functions冬休み復習! 直近アップデートと生成AIとの組み合わせ検証
kenpi13
1
69
AWS認定試験12種取得して感じたこと
kenpi13
0
370
Other Decks in Programming
See All in Programming
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
540
第9回 情シス転職ミートアップ 株式会社IVRy(アイブリー)の紹介
ivry_presentationmaterials
1
240
ruby.wasmで多人数リアルタイム通信ゲームを作ろう
lnit
2
280
Team topologies and the microservice architecture: a synergistic relationship
cer
PRO
0
1.1k
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
270
なぜ適用するか、移行して理解するClean Architecture 〜構造を超えて設計を継承する〜 / Why Apply, Migrate and Understand Clean Architecture - Inherit Design Beyond Structure
seike460
PRO
1
700
Create a website using Spatial Web
akkeylab
0
310
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
140
関数型まつりレポート for JuliaTokai #22
antimon2
0
160
Enterprise Web App. Development (2): Version Control Tool Training Ver. 5.1
knakagawa
1
120
XP, Testing and ninja testing
m_seki
3
210
LINEヤフー データグループ紹介
lycorp_recruit_jp
0
1k
Featured
See All Featured
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Why You Should Never Use an ORM
jnunemaker
PRO
57
9.4k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
252
21k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
490
Producing Creativity
orderedlist
PRO
346
40k
Building Applications with DynamoDB
mza
95
6.5k
Building an army of robots
kneath
306
45k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
We Have a Design System, Now What?
morganepeng
53
7.7k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Transcript
エンジニアのための消す技術 何かを生み出すエンジニアが消すことに向き合ってみよう
自己紹介 名前:川原 健太 kawahara kenta 所属:KDDIアジャイル開発センター(KAG) 福岡オフィス オフィス長 / ソフトウェアエンジニア
経歴:西日本鉄道 → チームラボ → KAG 資格:AWS / JSTQB etc.. 好き:写真・旅行・珈琲 X: kenpi1313
Agenda ・はじめに〜身の回りの「消す」 ・消すことを前提に作り出す ・おわりに〜Deletable
なぜ、消すことをテーマにしたのか
エンジニアの仕事は 作り出すこと(0→1 / 1→100)
それだけなのか..?
消すこと
消さないと、増え続ける ・コード ・ブランチ・Pull Request ・チケット ・ドキュメント ・提供しているサービス・機能 ・データ・ログ ・会議
消さないと、増え続ける ・コード ・ブランチ・Pull Request ・チケット ・ドキュメント ・提供しているサービス・機能 ・データ・ログ ・会議 認知負荷
ビルド・読み込み速度 量増大→料金増大 作業時間の圧迫
閑話〜プラクティス
ボーイスカウト・ルール 来たときよりも、美しく (例)コード修正の際に、触るファイルで不要なコードがないか、見回 す。もし発見したら、機能修正とともに、不要コードを削除する。 (別のPull Requestにするとレビューしやすい💡)
消すことを前提に作り出す
消すことから考えて選ぶ(実生活の例) ・大型家具(不要になったら粗大ゴミ) ・家電(業者引取 / リサイクル法) ・インターネット契約(違約金) ・サービス契約(解約導線 電話 or ネット)
消しづらい例① 〜スマホアプリ〜 person = { name: “kenta”, age: 31, nickName:
“kenpi” } person = { name: “kenta”, age: 31, nickName: “kenpi” } 不要になったので消したい 必須項目
アプリのリリース時にバック エンドもリリースするぞ!
エラー・クラッシュ
スマホアプリでは常に互換性を意識する必要がある ・リリースしたアプリがユーザー全員に自動反映されるわ けではない ・ユーザーが自分のタイミングでStoreで更新する ・バックエンドからの返却値が不要になったアプリと、必須 のままなアプリが混在している
特定のバージョン以前のアプリを使えなくし たい(消したい)
強制アップデート 強制的にストアに飛ばしてアップデートを促す 指定したバージョン以降のアプリのみ使われている状態 に”強制”できる 開発初期から、この機能を組み込んでおくことが必要
消しづらい例② 〜新機能が不安定〜 新しく作ろうとしている機能で、利用する外部APIが安定 しておらず、不安要素がある。 機能を消すには、該当コード全体をコメントアウトして再 デプロイする必要がある。
やっぱり挙動がおかしいぞ、フロ ントから消したい...
コード削除対象範囲はどこからどこまでだ・・? 箇所が多いな・・・ デプロイ時間がかかるぞ・・・
シンプルな手順で簡単に消したい
フィーチャーフラグ ``` const flag = true; if (flag === true)
// サービスをON else ``` ``` const flag = false; if (flag === true) else // サービスをOFF ``` ON/OFF
フィーチャーフラグ ・コードの中にtrue, falseのフラグを持っておいて、再デプロイ ・AWS APIGateway ステージ変数の書き換え ・AWS CloudWatch EvidentlyでON/OFFをスケジュール化 →A/Bテスト
最初にフィーチャーフラグの機構を取り入れておく
それはDeletableか? 何かを作り出すときに Deletableかどうか?を意識する
Deletableではないもの ・機能A + 機能B + 機能C が合体したPR・リリース → 機能Bだけリバートしたい・切り戻したい ・削除のための確認事項が不明瞭なもの
→ 存在意図が不明 / 作成者が不明・手順が煩雑 ・削除要件が定まっていないもの → 削除するタイミング・条件が決まっていない
Deletableなもの ・機能A + 機能B + 機能C が分離したPR・リリース → 単体で扱うことができ、単純な作業になる ・削除のための確認事項が明瞭なもの・自動化
IaaC → 消していい理由が分かる・手順が均一 ・削除要件が定まっているもの → ズルズル維持し続ける状態を避けられる
消さないと、増え続けるもの → Deletableですか? ・コード → ・ブランチ・Pull Request → ・チケット →
・ドキュメント → ・提供しているサービス・機能 → 利用率◯%・利益率◯% ・データ・ログ → ・会議 → 〇〇な状態になったら止める・抜ける
Fin