俺好きか・妻の返事は・好きだった
・・・オレも・・・
どうすればより効率よくプログラムを組み上げられるのか
◆1：ソフトウェア開発について
・コードを書く前に要件を決めること
・一つ一つの動作をコメントに残すこと
・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」”を使えばコミットするファイルを選択できる
・プロジェクトをデータタイプごとに整理する
多くのプロジェクトでは左のように機能別にフォルダ分けを行いますが
右のようにデータごとに整理した方が小さいプロジェクトへの分割がはるかに簡単に
・必要に応じてライブラリを作成すること
・システムの監視方法を学ぶべき
・コマンドラインオプションの代わりに設定ファイルを利用すると便利
・複数のアプリを扱う場合でも最初は適当で良い
アプリケーション間で通信する方法を学ぶのは難しいかもしれませんが
最初はファイルを利用するなど原始的な方法でいい
直接通信するのはネットワークについて学んでからでも遅くない
・最適化はコンパイラに任せること
◆2：チーム・仕事について
・コードレビューではスタイルではなく設計を確認するべき
・formatterを利用する
・プロジェクトのコードスタイルに従うこと
・C/C++はK&R、PythonはPEP8を利用すること
・暗黙のものより明示的な方が良い
たとえば”sleep()」”では引数の単位が秒なのかミリ秒なのか分かりませんが”sleepForSecs”や”sleepForMs”とすることで分かりやすく
・多数の言語を触っておくと長期的には役に立つ
・ユーザーのプライバシーを守ること
・ユーザーデータを守る最善の方法はユーザーデータを集めないこと
・しょうもないミスで1時間以上無駄にした時は記録を残すこと
・自分のコンピューターで実行できない場合は生産性が落ちてしまう
クラウドの機能を利用している場合など、特殊な環境でしか動作しないコードを書く場合は生産性が落ちる
ローカルで実行する方法を探すべき
◆3：個人的なことについて
・コードを書くべきではない時もある
体調不良の時はヤらない
・プロジェクトの行動規範は利用者を守るもの
新しい言語やライブラリ、フレームワークを利用する際にはまずそのプロジェクトの行動規範を読むべき
動規範を読むことで、何が起きているのか理解できずに不快な思いをすることを避けられる
・NOと言うべき時もある
・自分の書いたコードの利用に責任を持つ
・完成していないのに「完成した」と言ってはいけない
何かバグの予兆を感じているのに、疲れているからと言ってコードが完成したことにしてみても
最初のユーザーがすぐにバグ報告を上げてくるだけ
・コードやアーキテクチャに文句を付ける人は注目してくれている
・トラブルを無視するのではなく、トラブルから学ぶ
・人々の反応に注意する
・口が悪い人からは距離を置くべき
・無意識であっても差別的な言動をする人からは距離を置くのが良い
・ヒーロープロジェクトを行わなければいけない日が来る
ヒーロープロジェクトとは
「その時点に存在するプロジェクトの様々な問題点を解決する」
と自分が個人的に考えている大きな変更のためのプロジェクト
例えばアーキテクチャを一新したり新しいフレームワークを導入したり
時には言語を変更したりというもの
もちろん、調査の結果現状の方が良いという結論になることも
・・・これが分からないんだな～
ヘタにヤると思わぬトコに・・・
・辞める決断をするべき時を学ぶ
・ITの世界は狭い
IT業界は、何回か転職を重ねた後で元の同僚と同じ職場になるかもしれないというレベルには狭い世界
ふるまいには十分気を付けるべき
・紙のメモはなんだかんだ役に立つ
・Trelloはかっこ良いものの、ポストイットの方が使える
・馬鹿げたやり方をブログに残すのは何もしないよりは良い
・……でもコメントはオフにしておいた方が良い
・「分からないこと」のリストを作成する
物理学者のリチャード・ファインマンは
「Things I Don’t Know(私の知らない物事)」というタイトルのノートを付けていました
・・・同僚の金庫を開けまくった方
何かかっこよくてもっと知りたいものが見つかれば、それをタイトルにしたファイルやノートを作成することでより詳しくなる
・・・要は後で自分・他人が見て分かるように
作ってる時は、こうするのはアタリマエと思ってても
後で見たら
俺は何をヤってたんだ？
なんてのは、よくあるパターン
判断させる場合、簡単なものでも
パラメーター？なんかを記述の中に埋め込まないで
めんどうでもデータにして呼び出すかたちに
あとで修正・機能追加が楽
今日は～
シダ？
なんかいいカンジ
0 件のコメント:
コメントを投稿