Memo

日々流れ行く情報の中から有用なものをピックアップ

ソフトウェア開発について

投稿日: 投稿者: jsaito
  • ソフトウェア開発について
    • コードを書く前に要件を決めること
    • 一つ一つの動作をコメントに残すこと
    • Gherkinは期待された動作を理解する良い助けになる
      Gherkinはテストのための記法の1つで、「こういう状態のとき、こういう動作を行えば、こうなることが期待される」という形式で記述していくものです。ビアソンさんは「たとえ実際にテストでは使わなくとも、Gherkinを書くことでアプリがどういう動作を期待されているのか理解しやすくなる」と述べています。
    • ユニットテスト、統合テストをするべき
    • テストはAPIをより良いものにしてくれる
    • テストはコマンドラインで行える方が良い
      テストを自動で行ったり、CIツールにおいても利用したりできるためとのこと。
    • コードを捨てる覚悟を持つこと
      特にテスト駆動開発は「コードを捨てるようにデザインされている」とビアソンさんは述べています。コードを書いた時間は失ってしまっても、その分だけ課題への理解が深まっているため全てが無駄というわけではありません。
    • 良い言語はテストを内蔵している
    • 将来の問題を考えるのは時間の無駄
    • ドキュメントは将来の自分へのラブレター
      ドキュメントを書くことは非常に面倒なことですが、関数を書いたときに何を考えていたのかを理解させてくれ、将来の自分を助けてくれるものとなります。
    • 関数のドキュメントは契約である
    • 関数の説明に「and」が出てくることはない
      もし「and」でつなぐ必要がある場合、その関数は2つに分けるべきものであるとのこと。
    • 真偽値を関数のパラメーターに利用してはいけない
      関数を設計する際に、引数にフラグとして真偽値を設定したくなることがあります。……が、真偽値を利用するとその関数が利用されている部分のコードが「getData(dataId, true)」というようになり、読んだだけでは「true」が何を意味しているのか分かりません。ビアソンさんは真偽値を利用するのではなく、別の関数を作るようアドバイスしています。
    • 関数のリネームに注意
      ライブラリとして他人に公開している場合、関数名を変更することは多くの人に影響を与えてしまいます。まずは元の関数に非推奨という警告を表示し、時間をおいてから消すのが良いそうです。
    • 良い言語はドキュメントを内蔵している
    • 言語選択は周辺環境も含めて考えるべき
    • エラーを握りつぶすよりはクラッシュさせた方が良い場合もある
    • もちろん適切にエラーを処理できるならそうするべき
    • 型はメモリの値をどう読むべきかを指南するもの
    • データが構造を持っている場合、できる限り構造を保持する
    • カーゴ・カルトの精神を持つ
      カーゴ・カルトは「誰かができたことは自分もできるはず」という考えのことで、データの保存方法を決めたりする時、ほとんどの場合には他人と同じやり方をするのが一番早いとビアソンさんは述べています。
    • 「最適な言語」論争は不毛
      「タスクに最適な言語・フレームワークがあり、そちらに移行するべきだ」という議論はたいてい自分のお気に入りの言語・フレームワークを発表するだけになるとのこと。
    • 「最適な言語」は意外と明白
      言語処理をしたい場合に言語処理が得意な言語であるPerlを選択するのは自然なことですが、もしプロジェクトメンバーがCを得意とする人ばかりであり、さらにプロジェクトが重要で失敗できないものであればCを選択する方が賢明です。
    • プロジェクト外部のものに手を出さないこと
      時折、適切な拡張機能を利用するのではなく、WordPressやDjangoといった外部ライブラリ・フレームワークに直接手を加えたくなることがあります。しかし、外部ライブラリがアップデートされるたびに変更を取り込む必要が出てくるため、プロジェクトのメンテナンスコストを激増させてしまいます。
    • コード内でどのようにデータが流れるかを理解すればより良いコードが書ける
    • デザインパターンに固執するべきではない
    • 関数型プログラミングの基礎はほかの場所でも役に立つ
    • 認知的不協和がコードを読みにくくしてしまう
      認知的不協和とは矛盾する認知を同時に抱えた際に不快感を抱く現象を表す言葉で、例えば「sum()」という名前の関数の動作が「リストの数字を全て足す」ではなく「リストのtrueの個数を数える」であるなどという一般的ではない関数名の使い方は読み手を混乱させてしまうとのこと。
    • 関数のネストを浅くする
      関数内で関数を呼び出し、その呼び出した関数内でまた別の関数を呼び出し……と関数をネストしていくと動作の理解が難しくなってしまうため、毎回返り値を受け取って改めて別の関数に渡す実装が好ましいそうです。
    • 簡単に書ける記法を利用する場合は正式な記法も学んでおくべき
    • 「簡単」の誘惑に抵抗する
      統合開発環境(IDE)を使えば簡単にプロジェクトを構築できますが、どのようにビルドシステムが構築されているのかやIDEなしで実行する方法を知らないままでは行き詰りやすくなってしまいます。
    • 日付や時刻を扱う際には必ずタイムゾーンを記入する
    • 常にUTF-8を利用する
    • ユーザーへのメッセージをログで伝えない
    • デバッガは過剰評価されている
      デバッガが悪いわけではありませんが、実際にはログの方が役に立つとのこと。
    • 必ずバージョンコントロールシステムを利用する
    • 変更ごとにコミットを行う
      「git add -p」を使えばコミットするファイルを選択できる
    • プロジェクトをデータタイプごとに整理する
      多くのプロジェクトでは左のように機能別にフォルダ分けを行いますが、右のようにデータごとに整理した方が小さいプロジェクトへの分割がはるかに簡単になります。
    • 必要に応じてライブラリを作成すること
    • システムの監視方法を学ぶべき
    • コマンドラインオプションの代わりに設定ファイルを利用すると便利
    • 複数のアプリを扱う場合でも最初は適当で良い
      アプリケーション間で通信する方法を学ぶのは難しいかもしれませんが、最初はファイルを利用するなど原始的な方法で問題ありません。直接通信するのはネットワークについて学んでからでも遅くないとビアソンさんは述べています。
    • 最適化はコンパイラに任せること
  • チーム・仕事について
    • コードレビューではスタイルではなく設計を確認するべき
    • formatterを利用する
    • プロジェクトのコードスタイルに従うこと
    • C/C++はK&R、PythonはPEP8を利用すること
    • 暗黙のものより明示的な方が良い
      たとえば「sleep()」では引数の単位が秒なのかミリ秒なのか分かりませんが、「sleepForSecs」や「sleepForMs」とすることで分かりやすくなります。
    • 多数の言語を触っておくと長期的には役に立つ
    • ユーザーのプライバシーを守ること
    • ユーザーデータを守る最善の方法はユーザーデータを集めないことである
    • しょうもないミスで1時間以上無駄にした時は記録を残すこと
    • 自分のコンピューターで実行できない場合は生産性が落ちてしまう
      クラウドの機能を利用している場合など、特殊な環境でしか動作しないコードを書く場合は生産性が落ちてしまいます。ローカルで実行する方法を探すべきだとビアソンさんは述べています。
  • 個人的なことについて
    • コードを書くべきではない時もある
      ビアソンさんは風邪を引いている時にコードを書いてみたこともあったそうですが、その時に書かれたコードは風邪が直ってから見てみるとほとんど書き直さなければいけないものだったそうです。
    • プロジェクトの行動規範は利用者を守るもの
      新しい言語やライブラリ、フレームワークを利用する際にはまずそのプロジェクトの行動規範を読むべきです。行動規範を読むことで、何が起きているのか理解できずに不快な思いをすることを避けられるとのこと。
    • NOと言うべき時もある
    • 自分の書いたコードの利用に責任を持つ
    • 完成していないのに「完成した」と言ってはいけない
      何かバグの予兆を感じているのに、疲れているからと言ってコードが完成したことにしてみても、最初のユーザーがすぐにバグ報告を上げてくるだけです。
    • コードやアーキテクチャに文句を付ける人は注目してくれている
    • トラブルを無視するのではなく、トラブルから学ぶ
    • 人々の反応に注意する
    • 口が悪い人からは距離を置くべき
    • 無意識であっても差別的な言動をする人からは距離を置くのが良い
      ビアソンさんは「これは個人的な意見」だと前置きした上で、「自分は差別的な言動だと感じても発言者にとっては自然なものであり、言うだけ無駄である」と述べています。
    • ヒーロープロジェクトを行わなければいけない日が来る
      ヒーロープロジェクトとは、「その時点に存在するプロジェクトの様々な問題点を解決する」と自分が個人的に考えている大きな変更のためのプロジェクトで、例えばアーキテクチャを一新したり新しいフレームワークを導入したり、時には言語を変更したりというもの。もちろん、調査の結果現状の方が良いという結論になることもあります。
    • 辞める決断をするべき時を学ぶ
    • ITの世界は狭い
      IT業界は、何回か転職を重ねた後で元の同僚と同じ職場になるかもしれないというレベルには狭い世界だそうです。ふるまいには十分気を付けるべきとのこと。
    • 紙のメモはなんだかんだ役に立つ
      Trelloはかっこ良いものの、ポストイットの方が使える
    • 馬鹿げたやり方をブログに残すのは何もしないよりは良い
    • ……でもコメントはオフにしておいた方が良い
    • 「分からないこと」のリストを作成する

引用元：http://gigazine.net/news/20190621-things-i-learnt-the-hard-way/