僕が考える「良いコード」 - give IT a try
こんなコードだとわかりやすい 僕が考える良いコードの特徴（条件）を挙げてみると、 ぱっと見たら、だいたい何をやっているのかがわかるメソッド名 ぱっと見たら、だいたい中身が何なのか想像がつく変数名 ぱっと見たら、だいたい何をやっているのかが把握できるメソッドの内の処理フロー 驚きが少ないメソッド 副作用が少ないメソッド（責務が1つしかないメソッド） DRY原則を守っているコード だいたいこんな感じ。 つまり「すんなり読めて、すんなりわかるコード」が理想。 プログラムが小さいうちや、一人で開発しているうちは「汚くてわかりにくいコード」であっても「自分さえわかればOK」で済んじゃうけど、プログラムの規模が大きくなったり、複数人で開発するようになると、「汚くてわかりにくいコード」は絶望的に開発効率を下げる。 こんなコードはわかりにくい たとえば上の反対で、 メソッド名だけ見ても何をやっているのか想
悪しきコードの痛みを知り、設計スキルを高める方法を学ぶ 全17章からなる『良いコード/悪いコードで学ぶ設計入門』
4/30発売の『良いコード/悪いコードで学ぶ設計入門』を紹介する「『良いコード/悪いコードで学ぶ設計入門』著者トーク」。ここで著者の仙塲大也氏が登壇。続いて、各章の概要について話します。前回はこちらから。 第1章：悪しきコードの弊害から痛みを知る 仙塲大也氏（以下、仙塲）：ここからは各章の紹介です。本書は1章から17章までの全400ページあります。第1章「悪しき構造の弊害を知覚する」。1章と2は、新卒さん向けの章です。「設計なんかぜんぜん知らないですよ」という方向けの章です。 そもそも設計って、「設計しなきゃ」という危機意識が必要なわけですね。その危機意識の醸成には、悪しきコードによる弊害を知覚する必要がありますよ。悪しきコードの弊害を数例用いてダイジェスト的に紹介して、痛みを知ってもらおうという章です。 第2章：「設計とは？」を学ぶ 第2章「設計の初歩」。本格的な設計は3章の「クラス設計
100万行の大規模なJavaScript製システムをTypeScriptに移行するためにやったこと | CyberAgent Developers Blog
現在ピグ事業部の主力サービスである「ピグパーティ」でサーバーサイドエンジニアをしております新卒2年目の川口です。普段はSRE関連の業務を主とし、サーバーサイドの業務効率改善や、システムの運用保守、時には機能の開発や修正なども担当しております。 ピグパーティは、2015年にiOS/Androidでリリースされたアバターコミュニティアプリで、サーバーサイドはNode.js(JavaScript)+MongoDBを採用しています。 ピグパーティではこれまでにプライベートクラウドからGCPへの移設、Kubernetes(GKE)の採用など、技術的負債の排除や新技術の採用などを積極的に行ってまいりました。今回は、サーバーサイド開発時の大きなボトルネックになっていた、型がわからないことに起因する複数の問題を解決するために、TypeScriptを導入することにしました。その結果、システム規模に対して少な
技術的負債は開発者体験を悪化させる - mtx2s’s blog
ソフトウェアエンジニアにとって、技術的負債が増え続けるソフトウェアプロダクト開発現場に身を置くことがどれほど苦痛なことであるか。エンジニアリング組織のマネジメントを長年担ってきて、それは強く感じるところだ。 中途採用の選考プロセスに面接官として参加し、これまで数多くの退職理由を見聞きしてきた。その中で、レガシーシステムをリファクタリング・リアーキテクティング・リライトできないことへの不満を理由として挙げるエンジニアは多かったように思う。裏を返せば、自社のソフトウェアプロダクトが技術的負債にまみれたまま放置されているなら、優秀な人材が他社に流出するリスクがあると認識すべきだ。 本稿では、技術的負債と開発者体験の関係について紐解くとともに、それに対してソフトウェアエンジニアリング組織を預かるマネージャーが取るべき行動について考えてみたい。 ※これは、Engineering Manager Ad
良いコードとは何か - エンジニア新卒研修 スライド公開｜CyberZ Developer
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
食べログの大規模なレガシーシステムを段階的に改善していく取り組み - Qiita
こんにちは、食べログシステム本部長の京和です。 今年の4月から本部長になりました。さらに4月に娘が生まれました 本エントリでは食べログで1年を通じて取り組んだ、大規模なレガシーシステムの段階的な改善について紹介します。[翻訳] Shopifyにおけるモジュラモノリスへの移行 に続いて2記事目のアドベントカレンダーになります。 どのように段階的に進めるか 食べログは今年で15年目のサービスで、Railsになってからは13年が経過しています。これだけ歴史があればあちこちにガタが来ているのは当然で、無数にある課題に対してどこからどのように取り組んでいくかを最初に決める必要がありました。 まず最初の前提として以下のように考えました。 既存のビジネスや開発を止めるような悪影響を与えない。むしろなるべく早くポジティブな影響を与えていきたい。 これだけ歴史のあるシステムを改善していくのは長い時間がかかる
ガチャを1から作り直した話 ─規模の拡大につれて開発速度を落とさないための取り組みについて─
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
Androidアプリを長く開発し続けるために気をつけている9個のルール - ZOZO TECH BLOG
Androidエンジニアの @nissiy です。Androidが発表されてからもうすぐ10年になろうとしています。長いですね。 実はAndroid版IQON、今年の4月でリリースしてから丸5年を迎えます。ここまで長くサービスを続けられて、かつ3年連続でベストアプリをいただけたのは、使ってくれているユーザーの方々のおかげであると日々感謝しています。 この5年で様々な追加機能の開発を行ってきました。新機能を1つ追加する度に、古い機能を1つ削除することを徹底して開発を進めてきたものの、長く開発を続けているのでそれなりに巨大なアプリになっています。 今回はAndroid版IQONを長く開発し続けるためにチーム内で徹底しているルールをいくつか紹介したいと思います。 当たり前な話ばかりですが、大きくOSのアップデートを繰り返すAndroidのアプリ開発に取っては大事な話ばかりですので、少しでも参考に
GoでとあるAPIサーバを実装し直した話 | メルカリエンジニアリング
サーバサイドエンジニアの @b4b4r07 です。この記事は Go Advent Calendar 2016 の 19 日目です。今回は Go (Revel フレームワーク) で書かれていた API サーバをフルスクラッチで書き直したお話をします。 Revel とは A high productivity, full-stack web framework for the Go language 公式の説明にあるように、Revel は高機能でフルスタックな Web フレームワークです。 複雑なルーティングや、パラメータのパーシング、テンプレート機能など、Web アプリケーションを作ろうとなったときに必要な手段はたいてい兼ね揃えているようです。公式ドキュメントに詳しく書かれています。 Revel 以外にも Go 製の Web フレームワークは多数あり、有名どころだと以下のようなものが挙げられ
技術的負債の返済 – レガシーコードをリファクタリングで救うには | プログラミング | POSTD
レガシーコードをうまく手なずけて、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。レガシーコードをうまく手なずけて 、もう一歩成熟させるにはどうすればいいのでしょう？この投稿では、大規模なレガシーウェブアプリケーションと格闘してきた私が学んだことを紹介します。 レガシーコードはリファクタリングで救出可能 耳寄りなお知らせがあります！ リスたちは毎年何千本もの木を植えてくれています 。まあ自分たちが隠したドングリのありかを忘れてしまった結果ですけどね。そしてもうひとつ。 あなたのプロジェクトも救出できる のです。 ボスから任されたプロジェクトが どんなに醜い泥まみれのレガシーコードだったとしても 、そこには 必ず 道があります。道は曲がりくねっていて、木陰にはモンスターが待ち構えていることでしょう。
レガシーコード改善勉強会の資料まとめ - エンタープライズギークス (Enterprise Geeks)
以前告知した通り、昨日ヤフーさんと共催で「レガシーコード改善勉強会」を実施した。 共催とは言っても、会場および告知サイトの提供、当日の運営など、ほとんどをヤフーさんにやっていただいた。 こういうイベントを開催するヤフーさんの心意気に改めて感謝したい。 当日の様子はこちらからどうぞ。 ヤフーさんの開催レポートも出ています。 セッション資料 以下、アップされた資料を当日のセッション順にまとめておく。 1. 「レガシーコード改善のススメ」（平澤 章＠ウルシステムズ） レガシーコード改善のススメ from ahirasawa 2. 「テスト、リファクタリングに関する深い方法論」（きょんさん） テストとリファクタリングに関する深い方法論 #wewlc_jp from Kyon Mm 3. 「レガシーコードとの付き合い方とテストでの話」（井芹 洋輝さん） レガシーコードとの付き合い方とテストでの話
もっともっと良いコーディングをするための勘所８つ - 病みつきエンジニアブログ
先日とあるコードレビューを拝見することがあったのですが、それにインスパイアされて記事を書いてみます。レビュワーの方が言ったことも含んでいますが、それと必ずしも一致するものでもありません。 Objective-Cのコードで書いていることが多いですが、わりと一般論だと思います。 photo by Hugo-photography 命名規則は言語の「普通」に任せる 例えば、Objective-Cだと変数にはcamelCaseを使うことが多いです。逆にRubyではsnake_caseを使ったりします。もしくは、略語を使うとか使わないとか、そういう違いもあります。 変数名に対してどういう書き方をするかというのは、個人の好みではなく、言語の慣習に任せるのがいいのではないかと思います。 言語の慣習の調べ方は、Githubで「stars:>100」と検索して、言語を絞るといいでしょう。(参考：Rubyの例
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
技術的負債は開発者体験を悪化させる / Technical Debt and Developer Experience
CSSの技術的負債との向き合い方 / How to Deal with Technical Debt of CSS (ja)
良いコードとは
IBM Developer