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
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
kawahara kenta
October 15, 2024
Programming
59
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
エンジニアのための消す技術〜何かを生み出すエンジニアが消すことに向き合ってみよう〜
kawahara kenta
October 15, 2024
More Decks by kawahara kenta
See All by kawahara kenta
無理しない、着実にやりきるCDK移行術
kenpi13
5
880
AWS CDKを始める際に コミュニティの知見が大いに役立った話
kenpi13
1
96
Amazon Bedrock Flows使ってみた ローコードでお手軽生成AIフロー作成!
kenpi13
0
130
Step Functions冬休み復習! 直近アップデートと生成AIとの組み合わせ検証
kenpi13
1
88
AWS認定試験12種取得して感じたこと
kenpi13
0
440
Other Decks in Programming
See All in Programming
Apache Hive: そしてCloud Native Lakehouseへ
okumin
1
210
【QA Test Talk Vol.8】AI-DLC による Whole Team Approach の加速
pkshadeck
PRO
0
110
言語を使う側から、作る側へ。 自作 Lisp で得た新たな気づき。
andpad
0
150
複数の Claude Code が"放置"されてしまう問題をCLI ダッシュボードを自作して解決した話
sumihiro3
1
670
5分で問診!Composer セキュリティ健康診断
codmoninc
0
890
PostgreSQL 18で考えるUUID主キー
kazuhiro1982
0
460
jsmini JavaScript Engine を作ってみた話
yosuke_furukawa
PRO
0
290
20260722_microCMSで考える、AI時代のコンテンツ運用設計
yosh1
0
370
生成AIで帳票OCRが「簡単に」作れる時代になった?
kon_shou
0
570
ルールを書いて終わらせないハーネスエンジニアリング
yug1224
4
1.9k
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
480
GDG Korea Android: 2026 I/O Extended ~ What's new in Android development tools
pluu
0
210
Featured
See All Featured
Mobile First: as difficult as doing things right
swwweet
225
10k
Thoughts on Productivity
jonyablonski
76
5.3k
Rails Girls Zürich Keynote
gr2m
96
14k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.7k
Done Done
chrislema
186
16k
Designing for Performance
lara
611
70k
Building the Perfect Custom Keyboard
takai
2
830
Game over? The fight for quality and originality in the time of robots
wayneb77
1
240
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.4k
Effective software design: The role of men in debugging patriarchy in IT @ Voxxed Days AMS
baasie
0
470
Context Engineering - Making Every Token Count
addyosmani
9
1k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.2k
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