はてなブックマーク

はじめに エンジニアになってから1年がたち、4月からは新人の方たちも入ってきました。 新人のコードをレビューしていると「うわ〜これ自分もやっちゃってたな〜...」と思うことが度々あるので、新人のあなたが同じ過ちを犯さないで済むようにこの記事で紹介していきたいと思います。 ベテランのあなたは読まなくて大丈夫です。 書かなくてもいいコメントを「（自分が）分かりやすいから」と残しがち 結構あるあるなんじゃないでしょうか？ そもそもコメントは少ない方がいいですが、必要に応じて残す場合もありますよね。最初はこの「必要に応じて」がどのくらいのレベル感なのか掴めず、不要なコメントを量産している人は少なくないはず。 私もかつてはゴミコメント生産機でした。こんな具合に。 とは言っても最初はコメントを残すべきかどうかの判断がなかなか難しいかもしれません。 とりあえず、処理の内容をそのまま書いたようなコメントは

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに 私の開発チームでは、毎週おこなう振り返りの中でチームのパフォーマンス向上や問題点の改善を目的とした「トライ」という取り組みを考え、次の1週間でそれを実践するようにしています。 この記事では、これまでに試してきたトライの中で特に印象的だったものをいくつか紹介していきたいと思います。 みなさんの職場でも取り入れられそうなものがあれば、ぜひ参考にしてみてください。 18時〜翌朝6時は仕事禁止 言葉の通り、夕方18時から翌朝6時までの間に仕事をしてはダメ、というものです。 ねらい リミットがあることで仕事に集中できる 18時になったら

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? この記事を書こうと思ったきっかけ ペアプロをディスったQiitaをわざわざ書くくらいには複数人開発を嫌っていた私ですが、最近ペアプロをしている時に「あれ、なんか楽しいかも」と思ったので記事にしてみることにしました。 息抜きのお供にどうぞ。 ペアプロが嫌いだった理由 「何もわからない新人と2,3年目の先輩」という組み合わせで開発をすると、どうしても先輩が新人に教える構図が出来上がります。当たり前なんですけどね。 分からないことがあればすぐに質問でき、適切な答えが返ってくる。最高ですね。 これは逆にいえば、「分からなければすぐに質問しなけれ