https://fortee.jp/phpcon-2021/proposal/5d39aa6d-aef2-4bed-8747-60b6d2f6adfe PHPカンファレンス2021の登壇スライドです
![【IMO】コードレビューって難しいよね.pdf](https://cdn-ak-scissors.b.st-hatena.com/image/square/a41b422783f8d2273aaa86e7bd28c97d69130eaa/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F7c3a309863a34619b4f6e1eac9954b7b%2Fslide_0.jpg%3F19179809)
結城です。 2021年9月13日から14日にかけて、東京都立大学の大学院生向け特別講義として「リーダブルコード演習」を実施しました。 演習の内容は、当社でこれまでにも行ってきているリーダブルコードワークショップを、プログラミング経験が比較的浅い・プログラミングの量がまだそれほど多くない方向けに調整した内容としました。 この記事では、実施した演習の概要と、今回意識した点を紹介します。 本文が長いため、目次を用意してみました。 発端 演習の構成 座学パート リーダブルなコードを書く意義について リーダブルコードを実践するためにまず取り組むべきこと 実際の現場での「コードがリーダブルでなくなってしまった」「リーダブルになるよう改めた」実践例 最初の実装 リーダブルでなくなった実装 リーダブルさを取り戻すための改修 コードがリーダブルでなくなっていってしまう要因 壊すのが怖くて、見て見ぬフリ 恐怖
DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット(といいつつほぼ忘れかけている)なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用(採用できているとは言っていない)しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい
チームにいると頼りになるソフトウェアエンジニアのメモです。自分のロールモデルでもあります。私のキャリアはほぼウェブブラウザ開発一筋なので、その辺に生息している人たちを思い浮かべながら書いてます。思いついたら随時更新します。 コードマニア コードやドキュメントを読むのが好きで、暇があれば適当なレビューに飛び入り参加したり、自分のプロジェクトとは関係ないコンポーネントもひたすら探検している。不穏なコードを見つけるとなんとリファクタリングもしてくれる。コードサーチがお友達。 やたらコードに詳しいので、何か分からないときはとりあえず聞きに行く。チームに一人いるとレビューが捗るし、コードベースも綺麗になる。コードマニアはコードベースを広く熟知している上に未知のコードに対する耐性も高いので、プロジェクトを移動してもすぐに活躍できる。 コードマニアの亜種にスペックマニアもいる。こちらはウェブやネットワー
CyberZ CTO室のメンバーの森 (@at_sushi_at) です。 先日、株式会社サイバーエージェントの2021年度 エンジニア新卒研修でコードの品質に関する講義を行いました。 そこで話した内容とスライドを完全公開します。 45分の内容のため、かなり長いですが、個人的にぜひ一読して欲しい内容になっています。 はじめに こんにちは、森 篤史と言います。2019年度入社で今年で3年目になります。株式会社CyberZのOPENREC.tvというプロダクトでAndroidアプリチームのリーダをやっています。 最近はプログラムを書く仕事以外に、次世代マネジメント室という全社横断組織でDevelopers Blogの改善プロジェクトを実行したり、CyberZ CTO室で組織活性化に取り組んでいます。 あと、2019年度の未踏スーパークリエータにも認定されました。 メインの仕事としては、入社して
Twitterからリアルタイムに情報を得たい人が使っているツールとして、よく挙がるのが公式クライアント「TweetDeck」だ。サードパーティークライアントがリアルタイム更新を実装するのに必要だったAPI「User Streams」(ユーザーストリーム)の提供は2018年に終了してしまったため、そうした機能を使いたいなら事実上TweetDeckを使うしかない。 ただ、TweetDeckはPCのWebブラウザから見ることを前提に作られているため、スマートフォンからも閲覧自体はできるものの、UIの最適化はされていない。JavaScriptを使ってUIをスマホに合わせたAndroidアプリ「TJDeck」もあったが、現在開発は止まっている。 こんな中、20年末に現れたのが「MarinDeck」だ。TweetDeckのカラムをスマホの表示幅に合わせるだけでなく、スワイプでのカラム切り替えや独自の設
この記事は古くなっており、今後更新されません。新しい React 日本語ドキュメントである ja.react.dev をご利用ください。 新しくなったチュートリアルでは最新の React の使い方がライブサンプル付きで学べます。 このチュートリアルは React の事前知識ゼロでも読み進められます。 チュートリアルを始める前に このチュートリアルでは小さなゲームを作成します。自分はゲームを作りたいのではないから、と飛ばしたくなるかもしれませんが、是非目を通してみてください。このチュートリアルで学ぶ技法はどのような React のアプリにおいても基本的なものであり、マスターすることで React への深い理解が得られます。 ヒント このチュートリアルは実際に手を動かして学びたい人向けに構成されています。コンセプトを順番に学んでいきたい人は一段階ずつ学べるガイドを参照してください。このチュート
はじめに この記事は Laravel #2 Advent Calendar 2018 の14日目の記事です。 内容 今回はLaravelでテストコードを書く際に、普段使っている処理をまとめてみました。 LaravelにはHTTPリクエストのテストとして、Featureテストがあります。 Laravel is a PHP web application framework with expressive, elegant syntax. We’ve already laid the foundation — freeing you to create without sweating the small... 自分はFeatureテストから書き始めることが多いため、この記事の内容がFeatureテスト関連寄りになっているかもしれませんが、テスト周りで何か思いついたら更新していきたいと思います
この記事について。 2030 年 「エンジニアです。コードは書けません。」|__shinji__| note 自分はそもそもビジュアルプログラミングやオーサリングに興味があり、ノーコードは興味の範疇でありつつも、現状のもの、現状の「コード抜きで作れる」ような謳い文句は厳しいと思っています。それを、RPG ツクールを例に説明します。 はじめに、ノーコードを分類する 本記事では、「専用の管理画面で編集し、出力のためにコードを書かない、もしくはコピペ程度」のものをノーコードとして扱います。 その中でさらに種類ごとに分類してみます。このような定義があるわけではなく、自分の主観的で暫定的な分類です。 タイプ 1: データベースから自動的にフォームを生成 Google App Sheet MS Power Apps タイプ 2: 高水準 API のパイプライン Zapier IFTTT 古の Yaho
リファクタリングの際に注意すべきこと著者: Rajith Attapattu 私達プログラマには必ず、既存のコードの「リファクタリング」が必要になる時がやってきます。ただ、リファクタリングをする前にいくつか考えてほしいことがあります。次に書くようなことに注意すれば、自分を含め、開発に関わる全ての人の時間と労力を大幅に節約できるでしょう。 リファクタリングするにあたってはじめにすべきことは、既存のコードベースと、そのコードに対して書かれたテストコードの洗い直しです。具体的に、現状での良い点、悪い点、強み、弱みを1つずつ確認していきます。これは、良い点、強みを残しながら、悪い点、弱みを克服することにつながります。既存のシステムに手を加えれば、必ず元より良い物になるはずと考えがちですが、実は何も良くならないこともあるし、もとより悪くなることもあり得るのです。既存のコード、テストを十分に検証しなけ
The document discusses PHP performance and dives into the internals of how PHP works, including details on the Zend engine, compilation process involving lexing, parsing and compiling to opcodes, and execution through opcode interpretation by the virtual machine. It provides examples and tips on optimizing performance by reducing compilation overhead through opcode caching, profiling execution to
みなさんこんにちは。@ryuzeeです。 2019年10月4日に行われたAWS DevDayの「レガシーコードからの脱却」のセッション資料を公開します。 内容は、9月に発売になった同名書籍『レガシーコードからの脱却』の全体像と一部のプラクティスの紹介という形になっています。 時間の関係で紹介できたのはごく一部の内容になっていますので、スライドを見て内容に興味をお持ち頂いた方はぜひ書籍をお読み頂ければと思います。 なお、現在Amazonの在庫が高額な値付けの転売商品?だけになってしまっているので、オライリーの直販か電子書籍(PDF、epub)をご利用ください。 45分という短い時間の中で何をお話するかは結構迷いました。本書はレガシーコードを「どうやって直すか」ではなく「どうやって作らないようにするか」に軸足を置いていて、そのためのプラクティスとして以下の9つを提唱しています。 やり方より先に
私はウンザリしています。 「○○対応」は曖昧なのでやめてください。「○○を修正した」の方が直接的です。 こんな指摘を新人が入ってくるたびにコードレビューやドキュメントレビューで繰り返しています。どうも、プログラマー(と言うか理系?)には独特の言語文化があり、みんな同じような分かりにくい表現をしてしまうようです。 「レビューを依頼する前にこれを読んどいて!」と言える記事なり本なりがあれば良かったのですが、良いものが見つけられなかった(ご存知なら教えてください)ので、とりあえずレビューでよく指摘する日本語の文章の問題点や変な表現ポイントを列挙しました。 なお「コメントは必要十分な量を書く」「チケット番号やWikiのURLを書く」といった、良く知られた・日本語に限定されない話題は省略しています。 (※コメント欄などの指摘を受け「補足」を追加) (※タイトル変更。「コードレビュー前に直して欲しい日
最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え?そこは問題ないと思いますよ?」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは
Githubの検索を使いこなせてない 常日頃お世話になっているGitHub。ただリポジトリを管理するだけじゃもったいない!と思い立って、Alfreadで手軽に検索できるように設定φ(..) が、コードが大量にありすぎていまいち欲しい情報にたどり着けない! ということで、GitHubに大量にあるコードから自分が欲しい情報を手に入れるためGitHub Helpに書いてある検索のコマンドを抜粋してまとめてみた。 Searching code - User Documentation 前提として GitHub Helpにある注意書き サインインしていないとすべてのパブリックなリポジトリを検索できません フォークしたリポジトリはフォーク元よりスターを獲得していないとインデックスされない もし検索したいときは fork:true or fork:only デフォルトのブランチのみがインデックスされる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く