タグ

コードとエンジニアに関するhigedのブックマーク (5)

  • 「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか

    「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか:10個のヒントとは? プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合はどうしたらよいだろうか。Red Hatのソフトウェアエンジニアが、コードレビューを行うに当たって念頭に置くべき10のヒントを解説した。 Red Hatでソフトウェアエンジニアを務めるデビッド・ロイド氏は2019年7月8日(米国時間)、コードレビューを行うに当たって念頭に置くべき10のヒントを同社の開発者向け公式ブログで解説した。プロジェクトメンテナーの立場にあるとき、提出されたコードが何らかの理由で気に入らない場合に役立つ指針だ。コントリビューター側としても参考になる。 これらのヒントは、客観的で的を射たレビューを行い、プロジェクトとその参加者を前進させるという観点からまとめられている。 (1)

    「気に入らないコード」をレビューする際にRed Hatのエンジニアはどうしているのか
  • エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba

    最近ちょこちょこ相談されることがあって、直接のスキルではないけど、こういうのもスキルだよなぁって思ったので、思いついた順に書いてみる。5個になった。 ## 1. 問題を切り分ける力 「これがなぜか動かない」って相談されたときって、いくつかの要素が絡んでることが多い。 なので「ここは明らかに問題ないでしょう」という一番土台のところからチェックを始める。そうすると「え?そこは問題ないと思いますよ?」って言われるので「うん、それを『問題ないと思う』じゃなくて『問題ない』って断言できるようにしようと思って」みたいな会話をよくする。 可能性をひとつずつつぶしていくと「ここだなぁ」って場所が見つかって、そしたら、もうあとはそんなに難しくない。ひとつずつ確認していくのって遠回りに見えるけど、結局その方が確実ではやいと思う。 ## 2. 想像と事実を切り分ける力 ↑と絡んで、想像や思い込みなのに、「ここは

    エンジニアが何か問題にぶつかったときにあるといい力を5個 - Mitsuyuki.Shiiba
  • エンジニアが知っておきたい法知識。ソースコード著作権&開発契約を元エンジニア弁護士に聞く! - エンジニアHub|若手Webエンジニアのキャリアを考える!

    エンジニアが知っておきたい法知識。ソースコード著作権&開発契約を元エンジニア弁護士に聞く! 法律トラブルを回避するための、エンジニアが留意すべき法律知識とは、一体どのようなものでしょうか。エンジニアの経験を持つIT弁護士・河瀬季(かわせとき)さんに話をうかがいました。 昨今、“無断転載”の線引きや引用のあり方など、インターネットと著作権の関わり、ひいては法律との関わりが注目される機会が増えてきました。そんな中、エンジニアとして働く人々はいかに法律と向き合っていけばいいのでしょうか。 企業に在籍しているエンジニアの場合、社内に法務担当者がいるかもしれませんが、法律と無関係ではいられません。使用するツールやサービスの高機能化に伴い、無償で多くのコードに触れる機会が増えています。また、自作サービスのフレームワークなどに、オープンソースソフトウェア(OSS)を利用したい方もいるでしょう。 しかし、

    エンジニアが知っておきたい法知識。ソースコード著作権&開発契約を元エンジニア弁護士に聞く! - エンジニアHub|若手Webエンジニアのキャリアを考える!
  • Twitter での6年間 #7|Satoshi Nakagawa|note

    (Twitter での6年間 6 からの続き) Apple のイベントからしばらくすると、テックリードから提案があった。ぼくがデモ用に作ったライブラリの設計もコードもきれいで見通しがいいので、そのライブラリをアプリ体に組み込んで、既存のコードを置き換えてはどうかということだった。ぼくはその提案には反対だった。既存のコードによほど大きな設計ミスがない限り、同じ要求を与えれば同じコードができあがる。ぼくの知る限り、既存のコードに大きな設計ミスはなかった。ぼくは、まずゴールとなる新アーキテクチャーを設計し、既存のコードを徐々に置き換えていくことでゴールに近づけていくインクリメンタルアプローチを提案した。既存のプロモートツイート関連のロジックを新しいコードベースに意味もなく移植したりすることで問題を起こしたくなかったのだ。マネージャーや他のエンジニアたちも同意見で、新アーキテクチャプロジェクト

    Twitter での6年間 #7|Satoshi Nakagawa|note
    higed
    higed 2018/07/02
    “...新アーキテクチャーを設計し、既存のコードを徐々に置き換えていく...インクリメンタルアプローチを提案した。...新しいコードベースに意味もなく移植したりすることで問題を起こしたくなかったのだ。”
  • Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub|Webエンジニアのキャリアを考える!

    Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 Rubyコミッター・園田裕貴(Yugui)さんが、長年の経験で体得したソースコードに書くべき「コメントの技法」を教えてくれました。 プログラミングにおいて、どんな初心者でも書けるけれど、適切に書くのは上級者でないと難しいもの。それがコメント(=ソースコードに書かれている注釈やメモ)です。 不適切なコメントをつけても、プログラムの動作には影響しません。しかし、書き方の巧拙によって、コードの可読性や理解のしやすさには雲泥の差が出ます。良質なコメントが良質なコードをつくるのです。 今回はRubyコミッターでありgrpc-gatewayの開発者でもあるSupership株式会社の園田裕貴(Yugui)さんに、優れたエンジニアがどんな観点を持ち、どんなコメントを書いているのかを聞きました。 園田 裕貴(そのだ・

    Rubyコミッター・Yuguiに学ぶ、コードに書くべき「適切なコメント」と「適切な場所」 - エンジニアHub|Webエンジニアのキャリアを考える!
    higed
    higed 2018/05/22
    一般論として最初に検討するべき候補はあります。「(1)事前条件」「(2)事後条件」「(3)不変条件」「(4)入力の意味」「(5)出力の意味」「(6)副作用」「(7)計算量」です。
  • 1