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
49
エンジニアのための消す技術〜何かを生み出すエンジニアが消すことに向き合ってみよう〜
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
46
Step Functions冬休み復習! 直近アップデートと生成AIとの組み合わせ検証
kenpi13
1
71
AWS認定試験12種取得して感じたこと
kenpi13
0
370
Other Decks in Programming
See All in Programming
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
690
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
910
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
730
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
1
10k
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
170
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
5.8k
システム成長を止めない!本番無停止テーブル移行の全貌
sakawe_ee
1
200
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
780
0626 Findy Product Manager LT Night_高田スライド_speaker deck用
mana_takada
0
170
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
110
10 Costly Database Performance Mistakes (And How To Fix Them)
andyatkinson
0
340
A full stack side project webapp all in Kotlin (KotlinConf 2025)
dankim
0
120
Featured
See All Featured
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
4 Signs Your Business is Dying
shpigford
184
22k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
2.9k
Speed Design
sergeychernyshev
32
1k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
GitHub's CSS Performance
jonrohan
1031
460k
Being A Developer After 40
akosma
90
590k
Six Lessons from altMBA
skipperchong
28
3.9k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
281
13k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
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