不要コードを継続的に削除し、技術的負債に対抗する
paizaでWebエンジニアをやっています藤田と申します。 「今期は技術記事6本書きます」と自ら目標にしておいて、4か月ぐらい記事を滞納していた良心の呵責に耐えかねて投稿いたします。 今回の記事では、不要コードの削除に関するモチベーションをあらためて整理するとともに、以前noteで私が執筆した記事の続編として実運用について説明します。 CI/CDであまり語られない課題 -不要コード- プロダクション開発を進めるにあたり、自動テスト(ユニットテストやブラウザテスト)を書くとか、CIやlintingはほぼ常識化していると考えます。 自動テストを書けば、ある挙動が維持されていることを保証できるとともに、コードパスの検証状況(カバレッジ)を可視化できます。 実装とテストがどんどん増えていき、正常系と異常系の動作は十分に確認できたとします。 一方時の試練に耐えられず、不要となったコードはどうなるので
【追記 2023/06/26】 テックリードに求める役割と適切なチームサイズについて - pospomeのプログラミング日記
自分はDMMプラットフォーム内のマイクロサービスアーキテクトグループという組織の責任者をしているが、 最初に比べると組織がそれっぽく拡大したこともあり、 ここ最近テックリードを立てる機会が増えてきた。 一度自分がテックリードに求める役割と適切なチームサイズについてアウトプットしてみようと思う。 DMMプラットフォームのマイクロサービスアーキテクトグループとは? pospomeがテックリードに求める役割 技術領域をリードする プロジェクトマネージメント 他チームとのコミュニケーション チームメンバーの評価 なんだかんだで総合力 pospomeがテックリードに求めない役割 ピープルマネージメント よく分からない政治的なコミュニケーション 適切なチームサイズについて 新規チーム設立を考慮する場合 おまけ：テックリードに求める役割と適切なチームサイズ以外のあれこれ No.2 の重要性 立場が人を作
チャンスは待たずに自分で作る ─ ソフトウェアエンジニアが「好きな技術」で生きていくための技術とは - Findy Engineer Lab
Go Conferenceなどを運営する一般社団法人Gophers Japanで代表理事を務める上田拓也（@tenntenn）です。学生時代にGoと出会って以来、10年以上Goコミュニティの運営に関わっています。 読者のみなさんはソフトウェアエンジニアだったり、ソフトウェアエンジニアを目指している方が多いでしょう。そのため、普段使ってるプログラミング言語やエディタ、開発環境、OS、クラウドベンダーなどにはお気に入りがあるかと思います。しかし、いくらお気に入りだからといって、最初からその技術を極め、仕事にして人生を賭けようとはなかなか思わないでしょう。筆者もそうでした。 本稿では、筆者がどのように好きな技術（Go）と出会い、コミュニティ活動を行いながら、仕事として活動できるようにしてきたのかを紹介します。読者のみなさんに、ソフトウェアエンジニアとして「好きな技術を突き詰める道もあるんだな」と
Chompy創業3年間の、技術選定の成功と失敗を振り返る｜yagitatsu
こんにちは、多様な食を多様に届け、「まいにちの食事」を、おいしく笑顔にしたい @yagitatsu です。 (ちょっと長い？w) 息を吸うように仕事のことを発信できるようになりたいな、ということで仕事でも、noteを再開しようと企んでおります。 会社の近く。秋の目黒川も良きですね🍂本日はCTOらしく、今まで行ってきた技術的な意思決定について、成功と失敗について自分の言葉で語ってみようと思います。 注意点なのですが、前提として、環境やチームによって何を成功とするかは違うと思うので、「へー、こういう考え方なんだね〜」という感じで、軽い気持ちで読んでもらえればうれしいです 😃 技術選定の成功/失敗とはどういう状態かそもそも、技術選定について、成功とはどういう状態で、失敗とはどういう状態か、言語化してみようと思います。 まず、技術選定の成功とは、「この技術を選んでよかった。今後も続けていきたい
伝えたい人に届ける技術記事の書き方 - Qiita
こんにちは、リファクタリングが大好きなミノ駆動です。 この記事は READYFORアドベントカレンダー2021 、初日の記事です。 なにこれ？ 苦労して執筆した技術記事は、伝えたい人にしっかり伝えたいですよね。 また、最後まで読んでもらいたいですよね。 一方で、構成などに課題があって、伝えたい人になかなか伝わらないことがあります。 この記事は、伝わる記事の書き方について、私の個人的なノウハウを書き記したものです。 これからアドベントカレンダーの記事を執筆される皆さんにとって、少しでもお役に立てられれば幸いです。 この記事のゴール 以下の理解を得ることをゴールとします。 以下2つの要件を踏まえた記事構成を心がけること。 構成要件①：技術を紹介する上で最低限説明の必要な内容を網羅すること。 特に課題をしっかり伝えること。 構成要件②：読み手が段階的に理解しやすい順番になっていること。 告知の仕
優れたテスト容易性を実現するためのポイント - PrAha ENGINEER LAB
ソフトウェアテストはソフトウェア開発において不可欠な活動です。欠陥を検出する、品質を確認する、テスト駆動開発などで開発を導くといった、様々な用途でソフトウェアテストは活用されています。そのソフトウェア...
質の高い技術文書を書く方法 - As a Futurist...
大学や大学院で論文の書き方を鍛え上げた人たちには遠く遠く及ばないが、僕の様なはぐれもの1でも最近は Amazon 社内で文書の質が高いと評価してもらえるまでにはなった。Software Engineer として、コードでのアウトプットはもちろん大事だけど、文書のアウトプット(およびそれによって得られた実際のアウトプット)は同じだけ重要である2。今回は自分が最近どういうところに気をつけて技術文書を書いているのか、ということについて数年後の自分が忘れてないことを確かめられる様にまとめておく。 そもそも文書とは？ 英語だと document。ここで指す(技術)文書とは、人間が読む文体で書かれた技術に関連する情報、といったものだ。具体的に言うと以下の様なものを想定している: 新しいプロジェクトの骨子を説明する資料 会議の叩き台となる 1 枚ペラ 本番環境に変更を加えるにあたっての包括的な情報や具体
Web 技術の調査方法 | blog.jxck.io
Intro 「新しい API などを、どうやって調べているのか」「仕様などを調べる際に、どこから手をつければ良いのか」などといった質問をもらうことがある。 確かにどこかに明文化されていると言うよりは、普段からやっていて、ある程度慣れてきているだけなものであり、自分としても明文化していなかったため、これを機に解説してみる。 やり方は一つではない上に日々変わっていくだろうが、頻繁にこの記事を更新するつもりはない。また、筆者は実務で必要になるというよりは、ほとんどを趣味でやっているため、このやり方が合わない場面は多々有るだろう。 スコープとしては、ライブラリ、ツール、フレームワークなどではなく、 Web プラットフォーム関連の標準やブラウザの実装状況などに限定している。 Scope 従来からあり、広く認知された API については、情報も多く調査の敷居はそこまで高くないため、今回は議論が始まって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
アバター2はなぜ48コマなのか。HFR映画がもたらす視覚効果とリアリティ
暗号技術の実装と数学