タグ

programmingとcommunicationに関するvanbraamのブックマーク (5)

  • コードレビューで心がけている3つのこと【PHPカンファレンス協賛記念ブログ!】 - コネヒト開発者ブログ

    こんにちは!エンジニアの @fortkle です。 あの伝説のゲーム「メダロット」のスマホゲームのリリース日がついに 2020年1月23日と発表がありました!*1 いまからワクワクしてきましたね!リリースしたらぜひロボトルしましょう! さて、今回の記事は「コードレビュー」についてです。コネヒトに入社してから早4年、数百のPRをレビューしてきてだんだんと自分の中でコードレビューに対する接し方が定まってきました。今日は私がコードレビューで心がけていることについてご紹介できればと思います。 レビュワーとして ① "既存コード" の 歴史的経緯を素早く紐解く コードレビューは様々な目的で行われますが、「欠陥・バグを検出すること」「コードの改善」に期待をしていることが多いかと思います。 これらの目的を達成するためには、既存・変更後のコードの実装意図や背景を理解することがとても重要になります。特に長年

    コードレビューで心がけている3つのこと【PHPカンファレンス協賛記念ブログ!】 - コネヒト開発者ブログ
    vanbraam
    vanbraam 2019/12/01
    いい話.本当にwhy大事; 動かすのも大事.ローカルだけで動くものなら動かすし,動かすのが難しいものでもテストは走らせる
  • RESTはオワコンか、クエリ言語は「GraphQL」の時代へ

    ゆっくりとだが、ある興味深い変化がデータセンター全体に浸透しつつある。それは、運用の管理にREST(Representational State Transfer)を使うという動きだ。これによりデータセンターアーキテクチャのモデルが使いやすくなり、自動化とオーケストレーションの機会が広がる。RESTは、コンピュータが普遍的なHTTPプロトコルを使って簡単に通信する方法として2000年に初めて導入された。RESTにより、さまざまなシステムを疎結合して情報を交換することが可能になった。 ただし最近、データセンターの軸足はRESTからGraphQLへとややシフトしている。 GraphQLとRESTの違い RESTの中心にあるのは「全てが1つのリソース」という考え方だ。当初は、この考え方が優れたソリューションだった。だが、このアーキテクチャは幾つか大きな問題に直面している。RESTのリソースは1つ

    RESTはオワコンか、クエリ言語は「GraphQL」の時代へ
    vanbraam
    vanbraam 2019/10/31
    ここで"REST"と書かれているのは正確にはRESTfulと呼ばれるべきもので,REpresentational State Transferの1つの実現に過ぎない.その意味ではGraphQLをRESTの別の実現と見る事も可能だが,使い方を間違えるとRESTの思想から外れるので要注意
  • コードレビューが好きになるプログラミングの原則 - Speaker Deck

    Web Developers Meetup Gotanda ~ MC Open Lab. #6 ~で利用した資料です。 https://memberscareer.connpass.com/event/106254/

    コードレビューが好きになるプログラミングの原則 - Speaker Deck
    vanbraam
    vanbraam 2018/11/27
    OCP:拡張に対してopenで,修正に対してclosed;KISS:Keep It Simple, Stupidがオリジナル;冪等性を求める理由は"操作の順序を意識しなくて良い"の方が適切では?;そもそも理由を示さないレビューはダメだと思う
  • 開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ~手段から準備、実施時期まで徹底解説~|ハイクラス転職・求人情報サイト AMBI(アンビ)

    開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ~手段から準備、実施時期まで徹底解説~ コードレビューによって解決される問題とは?そして、実際にチームでコードレビューを実施する上で気をつけるべきこととは?ソニックガーデンの取締役プログラマー西見公宏さんが、コードレビューのポイントを、実践に基づき解説します。 ITを活用して事業の課題を解決するサービス「納品のない受託開発」を提供する会社、ソニックガーデンの西見公宏(にしみ・まさひろ/@mah_lab)です。お客様の「バーチャルCTO」として、サービスの企画からシステムの開発・運用まで、日夜幅広く関わらせていただいております。 皆さんは普段、ソースコードをどのくらい読んでいるでしょうか? 普段からソフトウェア開発をしている人であれば、何か問題が起こったときの原因調査のために他の人が書いたコードを読んだり、はたまた自分の書いたコードを読

    開発現場に学ぶ、円滑なコードレビューに必要な8つの手法 ~手段から準備、実施時期まで徹底解説~|ハイクラス転職・求人情報サイト AMBI(アンビ)
    vanbraam
    vanbraam 2018/04/05
    "若手もレビュー"は同意しかない;8項目に新鮮味はないが,重要点が網羅されてて素晴らしい;"設計レベルの指摘"を対面でやる際に"話した内容"を"リアルタイムにプルリクのコメントに書き込んで"議事代わりにするの凄く良い
  • コードレビューにこそ、コーチングのアプローチを適用するべきかも - little hands' lab

    3つのコミュニケーションパターン 会社でコーチング研修があり、(主に部下と1on1を想定して)コミュニケーションパターンが以下の3つに分けられるという話がありました。 コーチング: 「答え」は相手の中にある 相手の話を聞く/問いかける/人となりを認める ティーチング: 「答え」はこちらにある 知識ややり方を教える/相手が理解してないことを説明する フィードバック: 成長を促すために、周りからどう見えているか、思われているかを伝える ポイントは 「いつもティーチングで自分が思うことばかり言ってしまってないか?アプローチには種類があることを認識し、適切に使い分けていこう」 という話でした。 これだけでもとても面白い話だったのですが、「これ、コードレビューでも同じではないか?」と思ったのです。 レビューにおけるティーチングとコーチング ティーチング ティーチングはいわゆる「指摘」です。 プルリク

    コードレビューにこそ、コーチングのアプローチを適用するべきかも - little hands' lab
    vanbraam
    vanbraam 2018/01/16
    "××にしてください"というコメントはしないようにしている.する時も必ず"○○なので"という理由を書く.また変に感じたコードでも,必ず"なぜそのような書き方をしたのか聞く".自分が間違っている可能性もあるので
  • 1