株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575
株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 https://note.com/cyberz_cto/n/n26f535d6c575
はじめに React.jsは現在、フロントエンド開発者に最も人気のあるJavaScriptライブラリです。Facebookが開発し、オープンソースのプロジェクトとして提供されているReactは、世界中の開発者や企業が使用しています。 Reactは、シングルページアプリケーションの構築方法を大きく変えました。その最大の特徴の1つがフックです。フックは2019年に導入されたもので、状態処理の時に、クラスコンポーネントの代わりに関数コンポーネントを使用できるようになりました。組み込みのフックに加えて、Reactは独自のカスタムフックを実装する方法を提供しています。 ここでは、アプリケーションやプロジェクトで使用できる、カスタムフックとその実装に関するお気に入りをいくつか紹介します。 1. useTimeout 宣言型アプローチでsetTimeoutを実装できます。まず、コールバックと遅延を受け取
https://fortee.jp/phperkaigi-2021/proposal/42ce8b07-6972-42bb-a2ac-96af7249cfa4 あるシステムを理解して開発を開始するとき、必要なのはInfrastructure as Codeを含むソースコードだけでは大抵の場合は不十分です。では挙動がわかるようなテストコードがあれば十分かというとそうでもありません。 いわゆる「オンボーディングの効果的な運用」「開発開始までのオーバヘッドの削減(PHPerKaigi2020で発表)」は継続的な生産性向上のためには考えなければならない要素です。 そして、上記を補完するためにしばしばドキュメントが書かれます。 私はドキュメント運用のアプローチとして「コードによる生成を含んだドキュメント運用」に興味を持っています。 私はこれを「Documentation as Code」と呼んでいま
まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高(大きな損失を生む問題・後からの修正が困難な問題) 優先度中 優先度低(システムに大きな影響を与えない問題・後からの修正が容易な問題) レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを
Ratehoki88 situs slot online yang selalu memberikan Mega hoki dan Big hoki terbesar sepanjang masa dengan menyediakan Mesin slot gacor terbaik saat ini yang selalu menurunkan scatter hitam dan Megawin terbesar di dalam permainan pragamtic play dan Pg shoft salah satunya di game online yang sangat di incar adalah Mahjong ways 1, 2 dan 3, 88 Mega 777 juta juga menyediakan pasaran togel atau situs to
レビューガイドライン(Review GuideLine) ここで述べているレビューはピアレビューについての方法です。 (作業成果物の欠陥と改善の機会を探すレビュー) 「最悪を最初に」を基本としてレビューすべき、 たとえば、仕様やアルゴリズムに欠陥があるのに、typoにこだわってもしょうがないので、なにが最悪かを考え、それを防ぐための物からレビューをします。 誤りがプロダクト全体に影響し、手戻りのコストが高くつく、あるいは失敗するようなリスクがないかを考慮にいれてレビューの対象を選択します。 たとえば、基本的な初期フェーズの要求仕様や、クリティカルな決定の基礎になる仕様、使用頻度が高いモジュールなどを重点的にレビューします。 以下に書く項目はレビュアーに負担をかけないようにするのが前提なのでレビュアーに出す前にそもそもテストしたい項目です。 参考: あなたのおっしゃるレビューってどのことかし
Google エンジニアリング・プラクティス ドキュメント このページは、Google Engineering Practices Documentation の非公式な日本語翻訳です。元のドキュメントは、クリエイティブ・コモンズの「CC-By 3.0」ライセンスで公開されています。 Google には、あらゆる言語・あらゆるプロジェクトをカバーする一般化されたエンジニアリング・プラクティスが数多く存在します。こうしたドキュメントは、私たちが長年に渡って開発してきたさまざまなベストプラクティスの経験が集結したものとなっています。オープンソース・プロジェクトやその他の組織でも、こうした知識から恩恵を受けられるかもしれません。そのため、私たちは可能な限り、この知識を公開するように努めています。 現在、以下のドキュメントが公開されています。 Google コードレビューガイドライン (Googl
Software engineering principles, from Robert C. Martin's book Clean Code, adapted for JavaScript. This is not a style guide. It's a guide to producing readable, reusable, and refactorable software in JavaScript. Not every principle herein has to be strictly followed, and even fewer will be universally agreed upon. These are guidelines and nothing more, but they are ones codified over many years of
あるエンジニアがプログラムを紡いでいく様を見てみるでしたライブコーディングで言ったことや言わなかったことを書いてみます。 意識してるのは「コードをどまんなかに」です。 speakerdeck.com ……あ、このスライドのブログ書き忘れてた。 スライド中の「えらぶ」はだいたいIDEの機能を指します。なのでライブコーディング中に使用したIDEの機能も挙げようと思います。基本的にデフォルトのつもりだけど、vimとの兼ね合いで変更してるのもあるので、そこはごめんなさい。あとMacです。今回はメソッド抽出とかクラス間移動とかダイナミックなのがなくて地味だけど、便利な子たちなので使ってあげてください。 リプレイ 今日の公開コーディングはスゴい新鮮だった🎵 コミット後のソースには、どこに悩んだのか、どこにこだわったのかは残らないのですね。 実際のコーディングを見させて頂く事で、気づかされる事が多かっ
Goでコマンドライン引数と環境変数の両方からflagを設定したい - Qiita Goで実装したプログラムでオプションをコマンドライン引数から取るには標準の `flag` パッケージを使いますが、値を環境変数からも読みたいことがあります。(特に Docker で動かす場合) htt... http://qiita.com/sfujiwara/items/f177d85e9c10f4c34fb6 実は結構簡単に出来ます。github.com/namsral/flag に依存したくない場合や github.com/namsral/flag が実は flag 互換で無かった、なんて問題が見付かった場合に使えるハックです。 オリジナルのコード package main import ( "flag" "fmt" ) func main() { var age int flag.IntVar(&ag
ソフトウェアを作るときにクオリティとスピードのバランスをとりたくて,どちらかに偏ってはいけなく,どちらもキープしないといけない.すごく雑に*1とらえると, クオリティ→正しく動き,不具合がないほうがよい スピード→(計算時間ではなく)早く作れるほうがよい ということになる. コードレビューでは,不具合を見つけて直してもらったり,動きはしてもコードの可読性に問題があって直してもらったりと,クオリティに目を向けられがちだと思う. ところで,コードレビューとスピードの関わりについて考えてみる.スピードのためにできることはいくつかあり, 早く読み始める→他のことやってても手を止めて読み始めたり,1日のうち決まった時間にレビュータイムを設けたり 速く読む→これはコツとかある*2けど精読しないといけないので難しい 不具合を見逃さない→リリース後とか,リリース直前に正しく動かないことが分かったら大きな手
JJUG CCC 2017 Spring E1 2017-05-20 10:00-10:45
ツールに任せることができないどんなことを人間は指摘できるのだろうか? 驚くほど多数の事柄があることがわかっている。この記事の残りで幅広い重要事項のリストに触れ、2つの特定の領域、パフォーマンスとセキュリティに関してはもう少し深く言及する。 設計 新しいコードは全体アーキテクチャに適合しているだろうか? コードはSOLID原則、ドメイン駆動設計、もしくはチームが採用する他の設計手法に従っているだろうか? 新しいコードでデザインパターンは使用されているだろうか?これらは適切だろうか? コードベースの標準や設計スタイルが混合されている場合は、新しいコードは現在の原則に従っているだろうか?コードは現在の方向性を引き継いでいるか、徐々に除去される古いコードの例に従っているだろうか? コードは正しい場所に配置されているだろうか?例えば、コードが注文に関係する場合は、それは注文サービスの中にあるだろうか
『JavaScript: The Good Parts』で紹介されている標準メソッドまとめ JavaScript: The Good Parts ―「良いパーツ」によるベストプラクティスは、JavaScriptの「良いパーツ」のみを厳選した、JavaScriptを書く人なら一度は読んでおきたい 良書です。したがって、ここで紹介されている標準メソッドは、積極的に取り入れるべきメソッドです。 「車輪の再発明はするな」とはよく言われることですが、標準APIに詳しくなることで普段書くJavaScriptもかなりきれいにまとまって書けるようになります。 本記事では省いているRegExpやNumberの節、または標準メソッド以外のJavaScriptの「良いパーツ」に興味が出た方は、一度本書を手にとって見てみてください。 「JavaScriptは言わばひとかたまりの大理石であり、私はその中からこの言語
Excel は滅びぬ! Excel の力こそ日本企業の夢だからだ! VBA 実装してて学んだこととかのメモ。 JavaJava してたかはあまり関係ないかも。 エディタの使い方 エディタを表示する Alt + F11 で VB エディタを表示できる。 環境設定 背景色・フォントを調整する デフォルトの白背景とか気が狂うので、暗い色にする。 「ツール」→「オプション」を選択し、「エディターの設定」タブを開く。 「コードの表示色」を選択して、「背景」の色を選択する。 ついでにフォントも見やすいやつに変更する。 これだけで開発効率が5割増しになる。 イミディエイトウィンドウ イミディエイトウィンドウを表示する いわゆるコンソールに当たるのが、イミディエイトウィンドウと呼ばれるウィンドウ。 Ctrl + G で表示される。 イミディエイトウィンドウに出力する ↓イミディエイトウィンドウに実行するプ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く