私がコードレビューの際に気をつけているコメントの書き方 - BASEプロダクトチームブログ
こんにちは、BASE株式会社 ランニング部部長の元木です。 日々、社員に運動不足解消を促す傍ら、Owners Marketingというチームでバックエンドエンジニアをしています。 さて、弊社ではソースコードを変更した際に必ずメンバー間でコードレビューを行ない、OKが出たコードだけをデプロイすることになっております。 今ではほとんどの開発現場でコードレビューを取り入れていると思いますが、読者の中には 「レビューのコメントって、どう書いたらいいのか分からない」 「こんな事を言って嫌な顔をされたり、喧嘩にならないか心配」 などと、苦手意識を持っている人もいるのではないでしょうか？ そこで、今回は私がコードレビューの際に気をつけているコメントの書き方をご紹介したいと思います。 気を付けているポイントとレビューコメントの書き方の例 私は、レビューで指摘事項をコメントする際のポイントは 「いかに分かり
「UNIXという考え方」を読んだ - えいのうにっき
以前に、kabuという半分ネタのCLIツールを作ったことがあった。Goの手習いに、という目的もあったのだけど。 blog.a-know.me 今でも月に一度は使うくらいの（自分にとっての）便利ツールなのだけど、このコマンドについて、「コマンドとしてあるべき姿」といった観点で、同僚からいくつか指摘をもらうことができたことがあった（「ネタにマジレスだけど......」と前置きしつつとても丁寧に添削してくれた :pray: ）。 引数がない場合は標準入力から取ると良い いま標準出力に出してるようなメッセージは、標準エラー出力に出すと良い。そうすると他ツールとの連携がしやすくなる -verbose オプションを設け、それがonのときだけ出す、などとする 候補が見つからなかったときは、non zero exit statusで終わるのが綺麗 こうした指摘は大変ありがたい一方で、「そういう感性みたいな
文系でもプログラマになれるのか - そーだいなるらくがき帳
ブログについたコメントに対する自分なりの考えを書く。 soudai.hatenablog.com 私は文系の大学生ですが、プログラミング興味を持ちプログラマになりたいと考えています。 とても難しい事は理解していますが、プログラマに就職するのは やはり難しいでしょうか？ もし可能性があるとしたら、就職先の探しかたや見分け方などの ことを教えてください？ お願いします。 文系でもプログラマを始めとするソフトウェアエンジニアになれるか？の答えは なれる。 例えば自分の周りでも id:daiksy さんとか @shinpei0213 さんは文系出身のソフトウェアエンジニアだしプログラミングしている。 もっと言えば自分自身、高卒エンジニアなので学歴がネックでプログラマになれないということは無い。 だがソフトウェアサイエンスをしっかりと学んだ人からするとスタートラインは後ろである、という事実はあるし、
プログラミング経験がない経営者のためのソフトウェア開発 11の事実 | Social Change!
今やどんなビジネスでもITが関係している。ITを支えているのはソフトウェアだ。あらゆるものがソフトウェアで実現される時代になった。そんな事業や生活に密接に関わるソフトウェアだが、その開発について知られていないことも多い。 とくに経営者がプログラミング経験がないことで、ソフトウェア開発のリーダーシップをとるときに的外れなマネジメントをしてしまうことがある。あまねく経営者がプログラミング経験があれば良いのかもしれないが、それは現実的ではない。 プログラミング経験がなくても、せめてソフトウェア開発の特性について知っておくと良さそうなこともあると思い、なるべく専門用語を使わずに本稿を書いた。 プログラミングは製造ではなく、設計である いまだにソフトウェア開発を、ビルや家屋の建築に喩える人がいるし、工場でモノを製造するようにプログラムが作られると思っている人もいる。 ここが間違いのもとだ。ハードウェ
エンジニアみんなで本棚を作った話と、メンバーのおすすめ本N冊 | Kurashicom Tech Blog
こんにちは。エンジニアの佐々木です。 去年の10月に入社してから退勤後に時間ができて、本をよく読むようになりました。入社してから読んだのは15冊ほどで、読んだ感想を残すために読書メーターでの記録もし始めています。 最近は「ベタープログラマ」、「なっとく！アルゴリズム」、「サピエンス全史(洋書版)」、「お金2.0」を並行して、時間と場所に応じて読んでいるところ。「サピエンス全史」に関しては通勤中に電車で読みたいと思いKindleで買ったんですが、やはり紙の本の方が好きだなぁ…と改めて感じています。 先月読んだ「人生にゆとりを生み出す 知の整理術」に紙のメタ情報について書いてあったんですが、紙特有のにおいとか手触りとか、そういったメタ情報を紙から得られるのが好きな理由かもと思ってます。 さて、ここまでは僕個人の読書習慣について書きましたが、ここからはクラシコムエンジニアの読書環境についてスポッ
二度目の挑戦こそが難しい
失敗を恐るな。挑戦しよう。 ・・・そうは言っても、失敗は怖い。特に、リカバリーが出来なくなるような失敗、不可逆性の高い挑戦を恐れるのは当たり前だ。 それでも、ある程度のリスクを取らないと、ある程度のリターンは得られない。それもわかっているから、挑戦しようと言うのだろう。 さて、本当に難しいのは、失敗をしてからのことだ。いまどきは、特に仕事なら挑戦をしたからといって、死ぬほどのことはない。生きるか死ぬかまでのリスクを負って挑戦する場面は中々ないだろう。 失敗を恐れず挑戦することよりも、本当に難しいのは、一度や二度の失敗をしても、へこたれずに、まだ挑戦し続けることだ。 なにかチャレンジを一回やってみるのも、もちろん怖いことかもしれないけれど、うまくいかなかった傷も癒えぬうちに、次の挑戦をすることの方が怖い。失敗のつらさを知ってなお挑戦できるか。 なにも恐れは失敗からだけではない。たとえ何かに成
仕事と遊びの逆転
餃子を皮から作った。わりと簡単に餃子の皮は作れると知って、皮から作ってみたくなったのだ。 スーパーに行って材料を買って、家になかった生地を伸ばすための麺棒も買って。「餃子の皮 レシピ」でググると沢山の情報がインターネットには溢れてる。詳細はどれも違うが、大体は同じだ。 薄力粉を混ぜ、捏ねて、寝かせる。それを伸ばして、切って、丸めて、円に伸ばして皮ができる。不恰好だが、それもまた良し。焼いて食べれば同じだ。自分で作ったことで、２割り増しで美味しく感じる。 自分で作ってみると、プロの人が作るのはやっぱりすごいな、と感じる。同時に自分には、これを毎日やって腕を磨くのはやれないな、とも思う。 材料費だけではなく、稼働する時間も考えれば、コストパフォーマンスで考えると、市販の皮を買ってきた方が早く安いし、なんだったら出来合いのものを買ってくる方が安い。 だけど、わざわざ皮から作ったのは、どちらかとい
"Shape Of Life" を抱いて - WETな備忘録
「理系ですか？文系ですか？」みたいなの聞かれたとき（そんな質問もアレだけれど）僕は「体育会系です」と言う。大学は農学部であったが、ロクに講義に出席せずに、アメリカンフットボールばかりしていた。賛否はあるだろうが、僕としては、そういう時間でしか得られないものをたくさん得たと思う。 僕が就活をしたのはもう何年も前になるけれど、何を狂ったか、プログラマーになった。知識も経験も無いまま、Web業界のプログラマーになった。 きっと何者にもなれない 優秀な同期の友人がたくさんできた。もう何度も転職しているが、今でも交流がある友人が多い。いい友人に恵まれ、嘘偽り無く、僕は幸せだと思う。 一方で、思い起こせば、入社してしばらくは、当然彼らよりも「プログラミング」「ソフトウェアエンジニアリング」ができない自分を、焦り、呪った。自分が情報科学に一切触れていない過去を悔やみ、自分の選択、プログラミングを生業とす
8つのSIer退職エントリから学ぶ、日本のSIerの実態 - #がみぶろ
この記事は、しがないラジオAdventCalender8日目の記事です。 私は、「SIerのSEからWeb系エンジニアに転職したんだが楽しくて仕方がないラジオ」という、全国のSIerを敵に回すようなタイトルのポッドキャストをやっています。 タイトルを決めた理由の1つとして、よく「SIer退職エントリ」がはてなのホットエントリーに入っているのを知っていたことがあります。 SIやばいよ、SIやめたよ、みたいな話は、界隈で興味や関心を得やすいのだなあという感覚もあってのタイトルです。 そこで改めて、富士通の退職者の1人として、「SIer退職エントリ」をまとめてみます。 ざっと探して見つかったものに限るので、偏りがあるかもしれません。 また、SIerの営業職/コーポレート部門などについては、本エントリのスコープから外しています。 ネガティブ寄り まずは、SIerに対してネガティブな感情が滲みでてい
『ZERO BUGS』を読んだ - r7kamura - Medium
Amazonでケイト・トンプソン, 酒匂 寛, 小田 朋宏の{ProductTitle}。アマゾンならポイント還元本が多数。一度購入いただいた電子書籍は、KindleおよびFire端末、スマートフォンやタブレットなど、様々な端末でもお楽… 全体が78個の物語によって構成されており、それぞれの物語において教訓が紹介される。ZERO BUGS というタイトルの通り、どの物語もソフトウェアの不具合をテーマにしている。文章の内容は平易で、プログラマ初心者にもわかりやすく、しかしながら示唆に富んでおり、経験が浅いプログラマであれば「なるほど」、経験が深いプログラマであれば「あるある」とどちらも頷きながら読み進めていけるはず。 それぞれの物語は2ページ程度でとても短く、何かの合間にも少しずつ読み進めていける。出来る限りコンパクトに話を収めようという気持ちで書かれていることが文面から伝わり、とても好感が
プログラマをクソコードで殴り続けると死ぬ - megamouthの葬列
ここにクソコードがある。 誰が作ったかはわからぬ。それが、どのような経緯でクソコードとなったのか、 あるいは、最初からクソコードであったのか、それらは全てクソコード自身が知るのみである。 ファーストコンタクト ある日、営業からシステム案件を打診されたので見積もりして欲しい。というメールが来る。 とある企業の既存システムに機能を追加する簡単な案件ですが、なななんとソースや仕様書をご支給いただけます！ と、それはサンタにプレゼントが貰えると信じて疑わぬ子供のような真っ直ぐなメールである。 ソースコードが入った圧縮ファイルを受け取ったプログラマは、早速、コードを読んでみる。 そのシステムが本当にいいコードで書かれているかを判断するには時間がかかるが、 クソコードであるかはおおよそ30分でわかる。 インデントがタブとスペースどちらかに統一されていないとか、フレームワークの誤用があるとか、またはフレ
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
ある文系プログラマがテックリードを任されるまでに学んだこと ── 最前線で生き延びる4つの戦略 コンピュータサイエンスの専門教育を受けず、20代半ばで本格的なプログラミングを始めた文系エンジニアが、いかに学び、考え、生き延びてきたのかを伝えます。 こんにちは。白山（@fushiroyama）と申します。現在は新聞社のデジタル事業部署で、モバイルアプリ開発のテックリードをしています。 自分のエンジニア人生を振り返ると、これまでの道のりは決して平坦ではありませんでした。コンピュータサイエンスの専門教育を受けず、本格的にプログラミングを始めた年齢も23、4歳と決して早くありません。 そんな自分が、いかにして開発チームのリーダーを任せてもらえるまでになったか？ 考えてみると、次の4つの戦略で生き延びてきたようです。 自分だけの居場所を見つける 必要な知識を効率的に取捨選択する 他のエンジニアに差を
なぜプログラマはあなたの事が嫌いなのか - megamouthの葬列
営業やマネージャーにとって、現場にいるプログラマというのは扱いづらい存在である。 飲み会などで、普段の彼らを観察してみると。同じエンジニア同士で固まってボソボソとよくわからない話をして、控えめな声で笑っており、総じて温厚で、扱いやすそうな人々に見える。 ところが、仕事になると、彼らはなんやかんのと理由をつけて、スケジュールに文句を言い、プロジェクト途中のリクエストには素直に答えてくれず、あげくには遠回しな嫌味を言ってきたり、極端な場合には、その温厚な仮面を投げ捨てて、攻撃的な暴言さえ吐く事がある。 どうも彼らは我々の事が嫌いらしい、と感じている営業・マネジメント職の人もいるのではないだろうか？ 彼らの人格や価値観に問題がある可能性も否定しないが、このような感情的な齟齬は、多くの場合、あなた自身が彼らの「自尊心」を傷つけていることに気づいていないことが多い。 プログラマの自尊心 プログラミン
「ゲームエンジン」と「極め本」の教育活用における落とし穴を避けるには
Unreal Engine 4（以降、UE4）、Unityをはじめとするゲームエンジンは、今やゲーム開発に欠かせない優れたソフトウェアだ。加えて、ゲーム開発に関する多くの学びが得られる格好の教材でもある。一方で、ゲームエンジンとの距離感を間違えると『ゲームエンジンのオペレーター』程度のスキルしかない学生を『ゲームデザイナー』、あるいは『プログラマ』と称して、世の中に送り出すことになりかねない。学生たちの5年先、10年先までのキャリアパスを思えば、一歩引いた視点でゲーム開発の現状や今後を把握し、筋肉質な人材を育て上げるカリキュラムを組む必要があるだろう......と、書籍『Unreal Engine 4で極めるゲーム開発』（2015）の著者で、Ubisoft Osakaのプログラマでもある湊 和久氏は語る。そんな湊氏による教職員向けセミナー『「ゲームエンジン」と「極め本」の教育活用における落
量産型プログラマを撲滅したい
プログラマの生産性の差は、出来る人と出来ない人で10倍とも100倍とも言われる。そんな馬鹿な、と思われるかもしれないが、事実だ。 むしろ、一緒に働かせると、出来るプログラマが、下手に作られたプログラムの修正をしなければいけなくて、全体の生産性を落とすことになる。 つまり、出来ないプログラマはチームで働くと、生産性をマイナスにするのだ。厳しいことを言えば、いない方がマシなのである。 ソフトウェア開発に猫の手はいらないのだ。 では、出来ないプログラマとはどんな人たちか。 コピペで書くプログラマだ。他で動いているプログラムをコピペして、なんとなく直して書いているプログラマだ。 なぜプログラムが動くのか、どう書けば動くのか、わかっていない。 ただ沢山のプログラムを書くだけの量産型プログラマだ。こういう人のプログラミングは、デバッグさせてみて、横で見てるとすぐにわかる。 まず、エラーメッセージを見な
システム障害と僕達はいかにして戦えば良いのか、障害対応について考えた - Qiita
IT界隈でエンジニアしていると、よく出くわすのが障害対応です。できれば会いたくないという人が多いと思うんですが、僕はけっこう好きです。障害対応。どこに原因があるのか調査をして、バランス良くベターな対応をしたときの楽しさは、プログラミングとはまた違ったものがあります。探偵っぽい感じが面白いですよね。もちろん、障害が発生しない状況を作るのが一番です 弊社では数多くのWebサービス／アプリを運営しているので、過去様々な障害対応をしてきました。その際に、解決までどんな道筋を僕がたどるのかを振り返ってまとめてみました。これが大正解なんてことはなく、人や事象によって違うとは思いますが。 なお、障害検知手法とか、サーバのコマンドとか、コードのデバッグ手法とか、具体的なことは一切出てきません。手続きと思考プロセス的な話です。 障害対応フローチャート 一般的な感じだと思いますが、障害報告から対応完了までのフ
クソコード、あるいは技術的負債 - 時計を壊せ
クソコードについてここ数日で考えたことを書いてみる。 技術的負債まわりのえらいひとたちの議論を眺めてて、技術的負債って言うとなんかプロっぽいけど、クソコードって言ったほうが示したいモノを素直に表してるし分かりやすいきがしてきた。 クソコードを書くなとは思わないけど、クソコードをいつまでも放置するのはやめようって思う。 クソコードは次なるクソコードを生み出すし、バグを隠蔽するし、メンテナンスコスト増大の悪循環のキッカケになるし、新人の教育上良くないので無くて済むならもちろんないほうがいい。 ただ、ギークな人たちを除いて、さらっと60点*1のコードなんて書けない。僕を含め大多数のエンジニアは自分自身が書いたクソコードをリファクタリングして60点以上のコードを目指すための時間が必要になる。 そのうえ、そういうコードを書いてもだいたい時間経過に伴って事情が変わって、60点のコードの挙動を壊さないよ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
NOOK
エンジニアtype 技術者のキャリアを考えるWebマガジン - 転職＠type
著名なOSSコミッタを年収400万円で雇おうとしたら無理だったお話
