機能は追加すればいいというものではない
みなさん、新機能は好きですか。ソフトウェアへの機能追加は、ユーザ目線で単純に考えると「できることが増えていくのでよい」という響きを帯びています。しかし実際は、長く使われるソフトウェアであればあるほど、新機能を追加すべきかどうかはものすごく気を使って決めるものであって、やればいいというものではないのです。この記事の目的は、新機能の追加には細心の注意が必要だとわかってもらうことです。おもな対象読者はソフトウェアを長期間メンテしたことがないかたがたです。 みなさんが使っているOSSに新機能を追加するPRを送った場合を考えてみましょう。ここで重要なのは、PRが送られてきたメンテナやコミッタといわれるコア開発者たちの立場になって考えることです。彼らの役割は、自分たちを含むユーザがそのソフトウェアを使い続けられるようにメンテし続けることです。このメンテのコストに注目すると、機能追加は基本的にコストを上
ヘタクソなコードを書いてもいい - 覚書
プログラミング言語のお作法から外れたコードやメンテ性が悪いコードを書くのはダメとよくいわれます。わたしは学生の頃、そういう意見を過剰に気にしていました。コードを書くことそのものに慣れていないのに綺麗に書こうとして手が動かず、動かないがゆえにコーディングの練習が進まない、という悪循環になっていました。そうすると何もアウトプットしないまま知識だけが増えていって、自分がこれくらいできそうというイメージと実際のプログラミング能力とのギャップで苦しみました。 この意識が薄れたのは、あるときものすごく手が早い人のコードを偶然見たときでした。たしかにちゃんと動くものができているんですが、そのコードの中身は当時の私の基準からいって*1おぞましいほど汚いものでした。そこで「これはわたしが書けば100倍くらい綺麗なコードを書けるんでは…」と一瞬思ったんですが、その後すぐに「あ、自分は知識はあるけど練習してない
Spring Bootアプリケーションのコードレビューポイント - Qiita
リクエストの入り口になるのはControllerになるため，初めてSpringを触る開発者の方も馴染みに深いと思うのですが，何も考えずにアプリを作っていくと，ついついControllerにビジネスロジックを実装してしまいがちです。そうすると，所謂保守性や可読性が低いFat Controllerが出来上がってしまうので，ビジネスロジックの隔離は強く意識したいポイントだと思います。 個人的にはそれぞれ以下の内容に徹するのが良いのでは？という考えです。 Controller リクエストの受付 リクエストパラメータのValidation Serviceの実行 例外処理 レスポンスの作成 Service ビジネスロジックの実行 外部サービスとの連携 Repositoryを介したデータ操作 トランザクション管理 Repository データ操作 Controllerの中で複数種類のServiceを呼び
6年間におけるGoのベストプラクティス | POSTD
（本稿は、QCon London 2016で行った講演の内容に基づいています。スライドとビデオは近日中に掲載予定です） 2014年に開催された最初のGopherConで、私は「 Best Practices in Production Environments（本番環境でのベストプラクティス） 」と題した講演を行いました。 SoundCloud の私たちはGoのアーリーアダプターで、その時点までに既に2年近く、本番環境向けの様々なGoコードを書き、実行し、メンテナンスしていました。そして私たちはいくつかのことを学んだので、その教訓をまとめ、多くの人に伝えたいと思ったのです。 それ以来、私はフルタイムでGoを使う仕事を続けています。SoundCloudではその後の活動やインフラチームで、そして現在は Weaveworks で Weave Scope や Weave Mesh の開発に使ってい
ソシャゲエンジニアの自分がコードレビュー時に重視する箇所33選 【随時追加】 - Qiita
コードレビューで土日に安寧を ソーシャルゲームは、ユーザアクセス集中と、それに伴うユーザデータ増加によって劇的に負荷が上がり、（主に土日に）サービスに影響を与えがちです。 問題があるコードは、たとえ負荷テストを行っても、作成したシナリオによっては見つけられない可能性もあります。 そういった見えない不安を払拭するという意味でも、コードレビューは重要だと思っています。 【ステキポイント】 ・ ソースを見ることにより、時限爆弾が土日に爆発するのを解除 ・ スキル共有によってメンバーがレベルアップすることにより、土日に爆発する時限爆弾の設置確率低下 まぁまとめると これに尽きます（4歳の息子談） 今は、gitのプルリクエストという強力なレビューツールもあり、敷居がかなり低くなったのでオススメです！ チェックするポイントは5つ コードレビューを行うにあたり、「どんなところをチェックすればいいのか分か
Rebuild: 126: Anti-Democratic Product Management (higepon)
Taro Minowa さんをゲストに迎えて、テックリード、プロダクトマネジメントなどについて話しました。 Show Notes Nguyen Tech Lead（TL/テックリード）の役割 honcho Good Tech Lead, Bad Tech Lead What are the job responsibilities of a Technical Product Manager? Rebuild: 98: Superhumans Wanted (Naoya Ito) Rebuild: 123: The Grail Dialogue (Naoya Ito) Bad Boss vs. Good Leader Image Microservices Google’s product strategy: Make two of everything Product Manager の
コードレビューのベストプラクティス | POSTD
Wiredrive では、私たちはかなりの数のコードレビューを行います。しかし、ここで働き始める前には私はコードレビューなどしたことがありませんでした。今回は、私がコードレビューをする時に何に注目するようにしているかや、私の考え出したベストなコードレビューのやり方をお話したいと思います。 コードレビューとは、簡単に言うと2人以上の開発者で問題を引き起こしそうなコードの修正について話し合うことです。コードレビューをすることのメリットについては多くの記事で語られており、知識を共有できること、コードのクオリティが上がること、開発者が成長できることなどが挙げられています。しかし、レビューを行う上で、どのように進めていくかという具体的なことについてはあまり多く語られてないように私は思いました。 レビューで何に注目するか アーキテクチャ/デザイン 単一責任原則 : 1つのクラスは変更する理由が2つ以上
テンプレートをDRYにするのは慎重にやったほうがいいですよねというお話 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
社内でレビューおじさん業してて書いた内容ですけど守秘する必要ない情報なんでちょっと内容書き換えてオープンアンドシェアーします。 本文 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品（些細な変更されることが多い部品）なので、「同じような部品だから共通化しちゃおう」ってやると失敗することが多いです。 特に気をつけるべきなのは、たとえばコンテンツをランキング形式でテーブルで表示する画面と、新着から順にテーブルで表示する画面があって、このふたつのテーブル部分は一緒だからパーシャルにしちゃおう、みたいなやつです。 見た目とかUIというのはソフトウェアの中でめちゃめちゃ柔らかい部品、というのがここで効いてきて、「新着とランキングは基本的に同じ表示なんですけど、ランキングのほうではランクがアップしたかダウンしたかのアイコンを表示してほしいんですよね〜」とか言われたり、「今見てるページ
Q. StoryboardとXIBはどう使い分ければいいんだろうか？ - Qiita
storyboardについて調べていたところ、StoryboardLintの作者の考えが興味深かったので該当のstackoverflowのエントリを抄訳した。訳はニュアンスが伝わればいいくらいの適当さです。 When to use Storyboard and when to use XIBs どういうときにstoryboardを使って、どういうときにXIBを使えばいいか、何かガイドラインはあるかな。それぞれの長所と短所はなんだろう。どういう状況でそれぞれを使えばいいんだろう。 動的にUI要素を組み立てる場合にstoryboardを使えないってのは知ってるんだけど。 (Asked by affian at 2012/2/22) Answer by henning77 at 2012/3/1 ぼくはXIBを使い込んだし、storyboardを使ったプロジェクトを二つ完成させたことがある。そこ
これであなたもテスト駆動開発マスター！？和田卓人さんがテスト駆動開発問題を解答コード使いながら解説します～現在時刻が関わるテストから、テスト容易性設計を学ぶ #tdd｜CodeIQ MAGAZINE
和田卓人さんによるテスト駆動開発問題解説の寄稿です！ バグのないよいコードを書くには、よいテスト設計が重要です。今回は現在時刻に関する問題と、その問題で提出された実際の解答コードを紹介しながら、どのようにテスト設計し開発していくのかを解説していきます。 ゲスト解答による解答コードも公開中！ by CodeIQ運営事務局 はじめに こんにちは、和田(@t_wada)です。今日は先日出題させていただいたTDDに関する問題の総評を行いつつ、テスト容易性設計について考えてみたいと思います。 問題文 私が出した問題は、以下のようなものでした。 問1. 下記の仕様をテスティングフレームワークを使ってテストコードを書きながら実装してください。 【仕様1】 「現在時刻」に応じて、挨拶の内容を下記のようにそれぞれ返す機能を作成したい。 (タイムゾーンはAsia/Tokyoとする) 朝(05:00:00以上
プログラミングはそれ自体が目的であっていい - mizchi log
これ読んで思ったこと。 プログラミングを勉強したい人が勉強する前にすべきこと - もとまか日記 http://d.hatena.ne.jp/moto_maka/20130512/1368308092 僕がプログラミングをはじめたとき、何を思ってプログラミングをはじめたか思い出してみようとしたけど、よく思い出せなかった。 ただ漠然と感じていたのは、プログラミングは個人が現実的にこの世界に直接手を加えることができる手段の1つであり、それをやらないのは勿体無い、といったことだったと思う。たぶん。 というわけで、最初にやったのはFirefoxのユーザースクリプトを書くことだったし、それはそれでよい経験だった。なんとなくゲームとかウェブアプリとか作りてーなー、と思って色んなライブラリを動かすだけ動かして満足した。プログラミング覚えて初めて最初の一年で10以上の言語のHelloWorldだけやったと思
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふつうのRailsアプリケーション開発