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
0
57
エンジニアのための消す技術〜何かを生み出すエンジニアが消すことに向き合ってみよう〜
kawahara kenta
October 15, 2024
Tweet
Share
More Decks by kawahara kenta
See All by kawahara kenta
無理しない、着実にやりきるCDK移行術
kenpi13
5
770
AWS CDKを始める際に コミュニティの知見が大いに役立った話
kenpi13
1
89
Amazon Bedrock Flows使ってみた ローコードでお手軽生成AIフロー作成!
kenpi13
0
110
Step Functions冬休み復習! 直近アップデートと生成AIとの組み合わせ検証
kenpi13
1
85
AWS認定試験12種取得して感じたこと
kenpi13
0
410
Other Decks in Programming
See All in Programming
Fundamentals of Software Engineering In the Age of AI
therealdanvega
0
150
RAGでハマりがちな"Excelの罠"を、データの構造化で突破する
harumiweb
9
2.5k
コーディングルールの鮮度を保ちたい / keep-fresh-go-internal-conventions
handlename
0
150
Swift ConcurrencyでよりSwiftyに
yuukiw00w
0
240
社内規程RAGの精度を73.3% → 100%に改善した話
oharu121
13
7.5k
new(1.26) ← これすき / kamakura.go #8
utgwkk
0
1.6k
AIとペアプロして処理時間を97%削減した話 #pyconshizu
kashewnuts
1
200
Takumiから考えるSecurity_Maturity_Model.pdf
gessy0129
1
120
AIに仕事を丸投げしたら、本当に楽になれるのか
dip_tech
PRO
0
180
Rubyと楽しいをつくる / Creating joy with Ruby
chobishiba
0
200
JPUG勉強会 OSSデータベースの内部構造を理解しよう
oga5
2
230
SourceGeneratorのマーカー属性問題について
htkym
0
140
Featured
See All Featured
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
How to optimise 3,500 product descriptions for ecommerce in one day using ChatGPT
katarinadahlin
PRO
1
3.5k
What the history of the web can teach us about the future of AI
inesmontani
PRO
1
450
A Tale of Four Properties
chriscoyier
162
24k
How To Speak Unicorn (iThemes Webinar)
marktimemedia
1
400
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
250
A designer walks into a library…
pauljervisheath
210
24k
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.1k
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.1k
Making the Leap to Tech Lead
cromwellryan
135
9.8k
Agile Actions for Facilitating Distributed Teams - ADO2019
mkilby
0
140
Game over? The fight for quality and originality in the time of robots
wayneb77
1
130
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