これを読みました。
で気になった部分のメモです。
・問題解決のための指示、ヘルプテキストなどは、問題が起きているまさにその箇所に表示されないと意味がありません。ユーザの視野が狭くなっているので、ヘルプメニューよりもツールチップの方が有用なのです。
・ユーザが求めているものを正しく知るには、言葉を聞くよりも、彼らの行動を観察するのがいいのです。彼らの求めるものを頭で考えて1日過ごすより、わずか1時間でも観察した方が得るものは多いのです。
・コードの整形処理をビルドプロセスに含めてしまう。
・モジュールをチェックインする際には、必ずチェックアウトする時よりも美しくする
・他人よりまず自分を疑う
・コードレビューの目的は、ただコードの誤りを修正するだけではありません。重要なのは、チーム全員に同じ知識を共有させること、またコーディングにおいて全員が守るべきガイドラインを確立することです。
・カプセルかとは結局のところ、インターフェースを狭くするということである。
・書くのに苦労したコードは、読むのにも苦労する
・入念に計画された訓練では得意なことに取り組むのではない。自分を鍛え、少なくともまだ得意でないことに取り組むのである。楽しいとは限らない。
・コードに何かテキストを入力する時は--コメントであれ、あるいはログ、ダイアログ、テストデータであれ--常に「これがもし公になったとして問題にならないか」と自問せよ。
・自分が知らない仕事、自分の直接関わっていない仕事をしている人を尊重するということが大事です。
・APIを提供するときは、API自身のテストだけでなく、必ずそのAPIを利用するコードのユニットテストも書く
・プロはただ、がむしゃらに働けばいいというものではありません。プロの仕事には、入念な準備と効率化のための努力、そして日々の反省と絶え間ない変化が必要なのです。
・優秀なプログラマはプログラミング言語を巧みに操るだけでなく、自然言語も非常にうまく使うことができます。
・ソフトウェア見積もりの主目的は、プロジェクトの結果を予言することではない。見積もりを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである
・正しい使い方を簡単に、誤った使い方を困難に
・他人の書いたコードを読むのが辛いのは、他人が書いたコードがひどいからではなく、思考や問題解決の方法が自分と違っているからです。しかし他人の書いたコードを読むことは自分の成長につながるのです。
・プログラミングにおける「再利用」を重視する人は多いですが、いつ、何を、どのように再利用すべきかがわからなければ、良い結果になりません。それをわかるためには、問題領域について、またアルゴリズムとデータ構造について、十分な知識が必要なのです。
・いつも「このコードは生涯、自分がサポートし続けなくてはならない」と思ってコードを書く。
・コードを見る人のためにテストを書く
・良いテストはドキュメントのようなはたらきをします。テスト対象となるコードについて知るのに役立つのです。「このコードはどう動くのか」を教えてくれるのが良いテストです。
・プロジェクトが始まったらコードネームを決めましょう。
・プログラマが持っておくべきスキルをあえて3つあげるとすれば、(1)コードを読むスキル、(2)テストをするスキル、(3)デバッグをするスキル、だと考えます。
0 件のコメント:
コメントを投稿