タグ

コードに関するar1theworld98のブックマーク (6)

  • 良いコードとは何か - エンジニア新卒研修 スライド公開|CyberZ Developer

    CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して

    良いコードとは何か - エンジニア新卒研修 スライド公開|CyberZ Developer
    ar1theworld98
    ar1theworld98 2021/04/28
    “学びによる負債があることを説明しました。これは、予め学んでおくことである程度避けることができます。これからは、より良いコードとは何か、具体的な指標について話していきます”
  • コードレビューの目的と考え方 - osa_k’s diary

    まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高(大きな損失を生む問題・後からの修正が困難な問題) 優先度中 優先度低(システムに大きな影響を与えない問題・後からの修正が容易な問題) レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

    コードレビューの目的と考え方 - osa_k’s diary
  • レビューしやすいプルリクエスト | DevelopersIO

    普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 普段レビューをしていて、レビューしやすいプルリクエストに対して個人的に感じている特徴をまとめてみました。 割と大きめなソースコードに対するレビューの話が主となります。 ざっくりまとめ 記事では以下のようなトピックについて記載しています。 差分の目的が1つ レビューをしながら「私はいま何のレビューをしているのか」のコンテキストスイッチが発生しないので嬉しい 何を達成したいのかがわかる レビューの多くは「やりたいこと」と「実現方法」のすり合わせなので、前者の精度を上げたい 分割されすぎていない 他のコードとの関連性や構造についてのレビューがしやすい レビューの強弱をつけるための情報がついている 機械的な変換の差分だったりした場合、それが事前にわかると嬉しい 検証結果が書いてある コードだ

    レビューしやすいプルリクエスト | DevelopersIO
  • 良いコードを書くための8つの習慣

    成功者がどのようにNew Relicを使用してKubernetesのパフォーマンスを4倍に向上させ、拡張性とスループットを改善したかをご覧ください。

    良いコードを書くための8つの習慣
  • やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手

    2019/10/31(金)に開催されたEngineering Organization Festival 2019 で @t_wada さんの「質とスピード」という講演を聞き、とても感銘を受けたのでメモ。 品質とスピードはトレード・オフの関係にある。どちらを優先するか?要バランスだ。 そう思っていた時期が私にもありました。 けど、そんなことはなかった! ■追記 個人的な捉え方としては、 プロダクトを漸進的に成長させ、仮説検証ループするスピード上げようとすると、犠牲にした保守性があとで(意外とはやく1ヶ月後には)足枷になる。 保守性(テスト容易性、理解容易性、変更容易性)が低いとリードタイムが延びてスピードがどんどん落ちていくループをまわせなくなる。ってことかな、と思う。 スピードを上げようとしたのに、意外とはやくスピードが上がらなくなるジレンマ。 @t_wadaさんのスライド 素敵なグラレ

    やはり俺の「質 v.s. スピード」はまちがっている。 #eof2019 - 名前考えるの苦手
  • 一夜漬け音楽理論

    ■コードの覚え方(全15回)■ ┣1.ドレミとアルファベット ┣2.基となるコード ┣3.真ん中の音が変化する ┣4.真ん中の音がさらに変化 ┣5.ここまでのまとめ ┣6.右の音が変化する ┣7.3つの音のまとめ ┣8.音を付け足す ┣9.特殊な例 ┣10.4つの音のまとめ ┣11.さらなる音を付け足す ┣12.さらに、、、 ┣13.音を移動しちゃう ┣14.ベースの音が変わる ┗15.まとめ ■キー・スケールのお話(全6回) ■ ┣1.メジャースケール ┣2.ナチュラルマイナー ┣3.ハーモニックマイナー ┣4.スケールのまとめ ┣5.メジャーキー ┗6.マイナーキー ■コード進行のお話(全13回)■ ┣1.重要な3つのコード[1] ┣2.重要な3つのコード[2] ┣3.重要なコードのまとめ ┣4.簡単な進行 ┣5.グループ分け ┣6.カデンツ ┣7.進行においての規則 ┣8.忘れてお

  • 1