👋Learning to code? Check out ourCoding Fundamentalscourse for beginners!
Exercism
👋Learning to code? Check out ourCoding Fundamentalscourse for beginners!
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書く - $shibayu36->blog;
先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう
仕様や実装方針の相談をPullRequestで行う取り組み - $shibayu36->blog;
これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな
いつ突然会社をやめても問題ないという基準でコードやドキュメントを書くテクニック - $shibayu36->blog;
blog.shibayu36.org 上の記事が思ったより読まれていたので、自分がこの基準を満たせるようにやっているテクニックも箇条書きで書いておく。 PullRequestを作ったら必ず自分でコードレビューをする コードを書いているとき、その一部一部はこれで完璧と思ってるけど、実は全体を見直すと分かりにくかったりする 1日寝てから見直す 1日経つとちょっと忘れて新鮮な気持ちで見れる 1週間後にもう一回見てみる 1週間くらい経つともうだいぶ忘れて、穴が見えてくる 穴があったら別PullRequestで直す もう一度同じところを担当することがあればチャンス。自分でもこれどういうことだっけってググり始めたら基準を満たせていない 自分が全く関わっていない部分のところを触りだしたらかなりチャンス。本当にまっさらな頭で基準を満たすか見れる。他人がやったことだからとか思わずにちゃんとその時に直す やっ
GitHub「完璧なプルリクの書き方を教えるぜ」 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? はじめに この記事は How to write the perfect pull request - GitHub を和訳というか、意訳した記事です。 ご指摘などありましたら大歓迎です！ 良いプルリクエストを書くには (原題 : How to write the perfect pull request) 会社が成長していくと、人もプロジェクトも様変わりしていきます。GitHubの中に私達が望む文化を育んでいくためには、我々が何を自覚してコミュニケーションするべきなのか分かってきました。私達のチームが最強であり続けるために、最近以下のよ
「イシューからはじめよ」を読んだ - $shibayu36->blog;
最近やることがたくさんあってどうしたら良いか分からなかったので、同僚の薦めもあって「イシューからはじめよ」を読んだ。結構面白かった。 イシューからはじめよ──知的生産の「シンプルな本質」 作者:安宅和人英治出版Amazon この本には、やるべきことがたくさんあった時に、タスクをやる効率をどんどん上げていくという方向にまず走るのではなく、その中で重要なイシューを見極めてそれを重点的に取り組むべきである、というようなことが書かれていた。とにかくやるのではなく、まずやることを見極めよみたいな感じ。確かに忙しい時はとにかくやるとなりがちだけど、とにかくやっててもあんまり成果が上がらないことがあるので、まず見極めないといけないと思った。 この本の中で 悩まずに考える 「これは何に答えを出すものなのか」を明確にしてから問題に取り組む 一次情報を死守 という言葉が印象に残ったので、それについて書く。 悩
つかまらない上司にならないために - 1分間マネジャーの時間管理を読んだ - $shibayu36->blog;
1分間マネジャーの時間管理 パンローリング株式会社Amazon 「1分間マネジャーの時間管理」を読んだ。非常に面白く、勉強になることが多かった。 この本は、マネジャーが時間に追われている状況をどう解決するかについて教えてくれる。この本においてプロジェクトにおける「次の対応」はサルと表現され、マネジャーが時間を作るためにはこのサルの管理をうまくしなければならないというような話で、時間に追われている状況の改善方法について説明している。書き方自体も時間に追われたマネジャーを主人公として物語風に進んでいくので、非常に読みやすく面白かった。 上に書いた通りの話なので、マネジャーになってなぜか忙しくなったと思う人は是非読んでみると良さそう。確かにそれで忙しくなってるわーみたいなことがいろいろ書かれているので参考になると思う。 この本の中でメインとなるポイントは オンケン流サル管理の心得 三つの時間をや
Hubotを導入したらレビューの敷居が下がった話 - yo_waka's blog
ウチの会社ではHipchatとGitHubを開発のコミュニケーションの中心にしている。 だんだん人も増えてくると、以前よりプルリクの数がそれだけ増えて、レビューで1日終わってしまう人がでてきた。 昔から仕様を知っている人にレビューが投げられがちで集中しやすいとかは他の会社でもよくある話しだと思う。 レビューは自分のタスクと同様に大事だけど、それで自分のタスクが全くできなくなったり、新しく入ってきた人がレビューする機会を失うのはあまりよくない。 というのもあって、Hubotを立ててみてプルリクのレビュアーをランダムで振れるようにしてみた。 Hubotというのはご存知Hipchatのbotとして動くプログラムで、botにコマンドを指定してリモート実行させたり、特定の文字列に反応させたりということがHipchat上でできる。 CoffeeScriptでスクリプト書けるのでとてもお手軽。 sush
Hubotレビュアーおみくじ @ githubkaigi
S3 Tables を図解でやさしくおさらい～基本から QuickSight 連携まで/s3-tables-illustrated-basics-quicksight
37signals流の考え方を楽しもう「強いチームはオフィスを捨てる」書評 - FutureInsight.info
Ruby on Railsの開発などでもお馴染みのスーパーテクノロジー企業37signalsが、リモートワークを取り入れた話をベースにリモートワークのススメをまとめた本「強いチームはオフィスを捨てる」。原題のREMOTEと比べるとちょっとださい邦題だなーとおもいつつ、このくらいの方がわかりやすいのかもしれません。 強いチームはオフィスを捨てる: 37シグナルズが考える「働き方革命」 ジェイソン・フリード Amazon.co.jpで詳細をチェック 楽天市場でこの商品を検索 どこにいても世界中の人と簡単にコミュニケーションできるのに、なぜオフィスが必要? 人生の大切な時間を通勤に費やすのはナンセンス! 優秀な人材と一緒に働きたければ、物理的距離なんて関係ない! 前作『小さなチーム、大きな仕事』で圧倒的な支持を集めたカリスマ経営者たちが、今回取り上げたのは「リモートワーク」。 世界に散らばる36
アジャイルなレビューをサポートするツールを5つ
Agile2010のリサーチセッションで、アジャイルソフトウェア開発におけるレビューをテーマに発表をしている方がいらっしゃいました（資料はこちら）。発表者はMario Bernhartさんだったと思うのですが、彼は発表の中で、Continuous Changeset-Based Review（CCBR）という言葉を使っており、開発の最後でレビューに時間をかけるのではなく、コミットごと（Changesetベース）のレビューという戦略を考え、CCBRを実践するためのツールとしてReviewClipseを紹介していました。 開発におけるレビューのコストは大きいと思います。アジャイル開発だけでなく、通常の開発もサポートする効率的なレビューツールを探してみました。 Mylyn Reviews (ReviewClipse) BernhartさんおすすめのReviewClipseはMylyn Revie
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デキるプログラマだけが知っているコードレビュー7つの秘訣（DevLove版）