プログラマーの十大技術の悩み
4528 ワード
10.注釈—「how」だけを説明したのに「why」は説明しなかった
入門レベルのプログラミングコースでは、コードを書く前にコメントを書くように教育され、できるだけ多くのコメントをしなければなりません.このような教育の出発点は、「多くの注釈は少ない注釈よりもよく、少ない注釈はないよりもよい」ということだ.残念なことに、多くのプログラマーはこれをタスクとして、各行のコードに注釈しています.
このような注釈を経て、このコードが何をしているのか分かりましたか?確かに、私にもわかりませんでした.問題は、多くの注釈があるが、コードが何をしているのかを説明しているだけで、コードがなぜこのように書かれているのかを説明していないことだ.
次に、同じコードの注釈を別の方法で説明します.
これでだいぶよくなった!このコードの役割はまだ完全に理解できないかもしれませんが、少なくとも少し方向があります.
注釈は読者がコードを理解するのに役立ち、文法を説明するために使われるものではありません.読者はforサイクルの動作原理を知っていると大胆に考えることができます.「//顧客リストにforループ操作を行う」というコメントを書く必要はありません.読者が分からないのは、あなたのコードが何に使われているのか、なぜこのような方法で実現しているのかということです.
9.干渉
まばたきの間にアクティビティからプログラミングの状態に変換できるプログラマーは少ない.通常、私たちは突然加速できるファラリーではなく、ゆっくりと起動する列車に似ています.私たちは一定の時間を必要として仕事の状態に入ることができて、いったん私たちが安定して有効な仕事の状態に入ると、私たちの仕事の効果と産出はとても豊かになります.残念なことに、お客様、マネージャー、同僚に考えが絶えず中断されると、あなたの脳はプログラミングの状態に入ることができません.
私达が1件の事をする时、多すぎる些细な事は私达が心の中に置く必要があって、私达は先にこの事を置いて、あの人の事を処理して、后でまたこの事をして、まだ间违いがあってはいけません.これらの妨害は私たちの考えを中断し、考えを再整理するのに多くの時間を費やすことになります.これは悔しいです.これほど人を落胆させ、挫折感を与える過程はありません.
8.範囲クリープ(Scope creep)
スコープクリープ(Scope creep)(フォーカスクリープ(focus creep)とも呼ばれ、需要クリープ(requirement creep)、機能クリープ(feature creep)、その他のめちゃくちゃな進化語)は、プロジェクト管理におけるプロジェクトの需要変更の暴走を指す.この現象は、プロジェクトの範囲が明確に定義されておらず、ドキュメント化されておらず、制御されていない場合に発生します.これは一般的にマイナスの影響があると考えられており、できるだけ避けるべきだ.
範囲クリープは通常、簡単な需要を複雑で驚くべき時間を必要とする巨大な無覇に変える.調査を担当する奴らは罪のないキーボードを数回叩くだけでこんなことになる.
◆バージョン1:この地域の地図を表示
◆バージョン2:この地域の地図を表示するには、3 D立体的な
◆バージョン3:この地域の地図を表示するには、3次元立体的で、飛行ナビゲーション図として使用することができます.
本来30分で完成できる任務は、数百人/日で完成できる超複雑なシステムになった.さらに悪いことに、多くの場合、需要変更は開発段階で発生します.そうすると、コードを書き直し、戻って、先日開発したコードを削除する必要があります.
7.管理者—プログラミングが全く分からない
管理は簡単な仕事ではありません.人は嫌な動物です.私たちは変わりやすく、喜怒無常で、私たちは天下第一だと思っています.このような人々に満足と団結を感じさせるには、山のような大きな努力が必要です.しかし、これは、管理者が部下の仕事を理解せずに管理できるという意味ではありません.管理者が私たちの仕事について少しも知識概念を持っていない場合、結果は需要が頻繁に変動し、現実的ではない工期、普遍的な挫折感(管理者と開発者)になるだけです.プログラマーたちの不満はかなり普遍的で、これも争いの根源だ.
6.文書を書く
このエントリを話す前に、私たちは確かに多くのドキュメント生成ツールを持っていることを認めますが、私の経験によると、これらのツールはAPIドキュメントを生成するのに適しており、他のプログラマーの参考になります.もしあなたが開発したソフトウェアが普段人々が毎日使うなら、素人(例えばあなたの実施、カスタマーサービスなど)が理解できるドキュメントマニュアルを書かなければなりません.
プログラマーたちがやりたくないことが簡単にわかります.すべてのオープンソースプロジェクトを簡単に振り返ることができます.人々はこれらのプロジェクトに対して何を求めているのか:ドキュメント.どこにいても、少なくとも半分のプログラマーがドキュメントを書くように要求すると、「他の人に書かせてはいけないの?」と保証書を打つことができます.
5.プログラム-ドキュメントがありません
私たちプログラマーは一連の人を言っているとは言っていません.プログラマーたちはよく彼らのプロジェクトで第三者のクラスライブラリとアプリケーションを使います.そこで、ドキュメントが必要です.残念ですが、私が6条で言ったように、プログラマーたちはドキュメントを書くことを憎んでいます.この劇的なことは私たち自身に起こります.
サードパーティ製クラスライブラリを使用する必要がある場合、少なくとも半分のAPIが何をしているのか分からないことがわかります.これほど人に打撃を与えることはありません.関数poorlyNamedFunctionA()と関数poorlyButSimilarlyNamedFunctionB()どんな違いがありますか?PropertyXプロパティを使用する前にnull値かどうかをテストする必要がありますか?自分のテストとエラーを報告してこそ明らかになると思います!
4.ハードウェア
データベース・サーバ上の奇妙なダウンタイム現象をデバッグしたり、RAIDドライブが正しく動作しない問題を解決するために呼び出されたりしたプログラマーは、ハードウェアの問題であることに気づいたとき、苦しんでいます.プログラマーはコンピュータをやっているという一般的な誤解があります.彼らはコンピュータの修理方法を知っているに違いありません.シーケンサは確かに全才ですが、ほとんどのプログラマーは知らないか、プログラムがマシンコードにコンパイルされた後にどのように働いているのか全然気にしていません.私たちは作ったものが需要のドキュメントに合っているかどうかだけに関心を持っています.そうすれば、私たちはこの上層部の任務に集中することができます.
3.あいまい
「Webサイトがダウンタイムしました」.「XX機能が正しく機能していません」.曖昧なタスクを処理するのは苦痛です.プログラマー以外が彼らが直面した問題を再現するように要求されるたびに、怒りに驚きました.彼らはよく分からないようで、「ダウンタイム、修復しました!」という言葉だけでは、私たちが仕事を始めることはできません.私たちはもっと多くの情報が必要です.
ソフトウェアの実行は(ほとんどの場合)追跡可能である.私たちもこれを喜んでいます.簡単に「修復」と言うのではなく、どの段階で、どのような状況で問題が発生したのかを指摘してください.
2.その他のプログラマー
プログラマーはよく他のプログラマーと合わないことがあります.驚きましたか.しかし、これは本当です.この方面のことは簡単に10つの項目をリストすることができて、細かいことを話して単独でブログを書くことができます.だから、ここではよくある、他の同僚を悩ませるプログラマーの特徴をいくつかリストします.
◆気性が荒く、態度が極めて友好的ではない.
◆システムのアーキテクチャをいつ議論すべきか、いつ手を出すべきか分からない.
◆効果的なコミュニケーションができず、誤解しやすい専門用語を使う.
◆自分のことがうまくいかない.
◆やるべき手順やプロジェクトに興味がない.
では、この最後ですが、最悪ではありません.シーケンス番号1のプログラマーたちを悩ませています.
1.自分で書いたコード—6ヶ月後の
Don’t sneeze, I think I see a bug.
自分が以前書いたコードを振り返ってみると、困った顔をしていたのではないでしょうか.その時はどうしてこんなに愚かだったのか.どうしてこんなものに書くことができたのか.焼く!火の中に捨てる!
現実は、ソフトウェア技術界は絶えず変化する世界である.今日が最善の方法と見なされ、明日は時代遅れになるかもしれない.私たちは完璧なコードを書くことはできない.私たちのプログラムの良し悪しを判断する基準が日進月歩しているからだ.これは不快だ.あなたの作品は、今日はそんなに完璧に見えるが、やがて嘲笑される対象になるかもしれない.最新の最高の開発ツール、設計、フレームワーク、開発方法をどのように努力して勉強しても、私たちはいつも最新の技術の発展傾向より遅くなっています.私にとって、これはプログラマーにとって最も悩んでいることです.私たちは絶えず技術をアップグレードして、ソフトウェアをもっとよくするためですが、思わず感じてしまいます.砂毛布(sand-painting)を作る和尚さん.
入門レベルのプログラミングコースでは、コードを書く前にコメントを書くように教育され、できるだけ多くのコメントをしなければなりません.このような教育の出発点は、「多くの注釈は少ない注釈よりもよく、少ない注釈はないよりもよい」ということだ.残念なことに、多くのプログラマーはこれをタスクとして、各行のコードに注釈しています.
r = n / 2; // r n 2
// r - (n/r) t
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) ); // r r + (n/r)
}
このような注釈を経て、このコードが何をしているのか分かりましたか?確かに、私にもわかりませんでした.問題は、多くの注釈があるが、コードが何をしているのかを説明しているだけで、コードがなぜこのように書かれているのかを説明していないことだ.
次に、同じコードの注釈を別の方法で説明します.
// -Raphson n
r = n / 2;
while ( abs( r - (n/r) ) > t ) {
r = 0.5 * ( r + (n/r) );
} これでだいぶよくなった!このコードの役割はまだ完全に理解できないかもしれませんが、少なくとも少し方向があります.
注釈は読者がコードを理解するのに役立ち、文法を説明するために使われるものではありません.読者はforサイクルの動作原理を知っていると大胆に考えることができます.「//顧客リストにforループ操作を行う」というコメントを書く必要はありません.読者が分からないのは、あなたのコードが何に使われているのか、なぜこのような方法で実現しているのかということです.
9.干渉
まばたきの間にアクティビティからプログラミングの状態に変換できるプログラマーは少ない.通常、私たちは突然加速できるファラリーではなく、ゆっくりと起動する列車に似ています.私たちは一定の時間を必要として仕事の状態に入ることができて、いったん私たちが安定して有効な仕事の状態に入ると、私たちの仕事の効果と産出はとても豊かになります.残念なことに、お客様、マネージャー、同僚に考えが絶えず中断されると、あなたの脳はプログラミングの状態に入ることができません.
私达が1件の事をする时、多すぎる些细な事は私达が心の中に置く必要があって、私达は先にこの事を置いて、あの人の事を処理して、后でまたこの事をして、まだ间违いがあってはいけません.これらの妨害は私たちの考えを中断し、考えを再整理するのに多くの時間を費やすことになります.これは悔しいです.これほど人を落胆させ、挫折感を与える過程はありません.
8.範囲クリープ(Scope creep)
スコープクリープ(Scope creep)(フォーカスクリープ(focus creep)とも呼ばれ、需要クリープ(requirement creep)、機能クリープ(feature creep)、その他のめちゃくちゃな進化語)は、プロジェクト管理におけるプロジェクトの需要変更の暴走を指す.この現象は、プロジェクトの範囲が明確に定義されておらず、ドキュメント化されておらず、制御されていない場合に発生します.これは一般的にマイナスの影響があると考えられており、できるだけ避けるべきだ.
範囲クリープは通常、簡単な需要を複雑で驚くべき時間を必要とする巨大な無覇に変える.調査を担当する奴らは罪のないキーボードを数回叩くだけでこんなことになる.
◆バージョン1:この地域の地図を表示
◆バージョン2:この地域の地図を表示するには、3 D立体的な
◆バージョン3:この地域の地図を表示するには、3次元立体的で、飛行ナビゲーション図として使用することができます.
本来30分で完成できる任務は、数百人/日で完成できる超複雑なシステムになった.さらに悪いことに、多くの場合、需要変更は開発段階で発生します.そうすると、コードを書き直し、戻って、先日開発したコードを削除する必要があります.
7.管理者—プログラミングが全く分からない
管理は簡単な仕事ではありません.人は嫌な動物です.私たちは変わりやすく、喜怒無常で、私たちは天下第一だと思っています.このような人々に満足と団結を感じさせるには、山のような大きな努力が必要です.しかし、これは、管理者が部下の仕事を理解せずに管理できるという意味ではありません.管理者が私たちの仕事について少しも知識概念を持っていない場合、結果は需要が頻繁に変動し、現実的ではない工期、普遍的な挫折感(管理者と開発者)になるだけです.プログラマーたちの不満はかなり普遍的で、これも争いの根源だ.
6.文書を書く
このエントリを話す前に、私たちは確かに多くのドキュメント生成ツールを持っていることを認めますが、私の経験によると、これらのツールはAPIドキュメントを生成するのに適しており、他のプログラマーの参考になります.もしあなたが開発したソフトウェアが普段人々が毎日使うなら、素人(例えばあなたの実施、カスタマーサービスなど)が理解できるドキュメントマニュアルを書かなければなりません.
プログラマーたちがやりたくないことが簡単にわかります.すべてのオープンソースプロジェクトを簡単に振り返ることができます.人々はこれらのプロジェクトに対して何を求めているのか:ドキュメント.どこにいても、少なくとも半分のプログラマーがドキュメントを書くように要求すると、「他の人に書かせてはいけないの?」と保証書を打つことができます.
5.プログラム-ドキュメントがありません
私たちプログラマーは一連の人を言っているとは言っていません.プログラマーたちはよく彼らのプロジェクトで第三者のクラスライブラリとアプリケーションを使います.そこで、ドキュメントが必要です.残念ですが、私が6条で言ったように、プログラマーたちはドキュメントを書くことを憎んでいます.この劇的なことは私たち自身に起こります.
サードパーティ製クラスライブラリを使用する必要がある場合、少なくとも半分のAPIが何をしているのか分からないことがわかります.これほど人に打撃を与えることはありません.関数poorlyNamedFunctionA()と関数poorlyButSimilarlyNamedFunctionB()どんな違いがありますか?PropertyXプロパティを使用する前にnull値かどうかをテストする必要がありますか?自分のテストとエラーを報告してこそ明らかになると思います!
4.ハードウェア
データベース・サーバ上の奇妙なダウンタイム現象をデバッグしたり、RAIDドライブが正しく動作しない問題を解決するために呼び出されたりしたプログラマーは、ハードウェアの問題であることに気づいたとき、苦しんでいます.プログラマーはコンピュータをやっているという一般的な誤解があります.彼らはコンピュータの修理方法を知っているに違いありません.シーケンサは確かに全才ですが、ほとんどのプログラマーは知らないか、プログラムがマシンコードにコンパイルされた後にどのように働いているのか全然気にしていません.私たちは作ったものが需要のドキュメントに合っているかどうかだけに関心を持っています.そうすれば、私たちはこの上層部の任務に集中することができます.
3.あいまい
「Webサイトがダウンタイムしました」.「XX機能が正しく機能していません」.曖昧なタスクを処理するのは苦痛です.プログラマー以外が彼らが直面した問題を再現するように要求されるたびに、怒りに驚きました.彼らはよく分からないようで、「ダウンタイム、修復しました!」という言葉だけでは、私たちが仕事を始めることはできません.私たちはもっと多くの情報が必要です.
ソフトウェアの実行は(ほとんどの場合)追跡可能である.私たちもこれを喜んでいます.簡単に「修復」と言うのではなく、どの段階で、どのような状況で問題が発生したのかを指摘してください.
2.その他のプログラマー
プログラマーはよく他のプログラマーと合わないことがあります.驚きましたか.しかし、これは本当です.この方面のことは簡単に10つの項目をリストすることができて、細かいことを話して単独でブログを書くことができます.だから、ここではよくある、他の同僚を悩ませるプログラマーの特徴をいくつかリストします.
◆気性が荒く、態度が極めて友好的ではない.
◆システムのアーキテクチャをいつ議論すべきか、いつ手を出すべきか分からない.
◆効果的なコミュニケーションができず、誤解しやすい専門用語を使う.
◆自分のことがうまくいかない.
◆やるべき手順やプロジェクトに興味がない.
では、この最後ですが、最悪ではありません.シーケンス番号1のプログラマーたちを悩ませています.
1.自分で書いたコード—6ヶ月後の
Don’t sneeze, I think I see a bug.
自分が以前書いたコードを振り返ってみると、困った顔をしていたのではないでしょうか.その時はどうしてこんなに愚かだったのか.どうしてこんなものに書くことができたのか.焼く!火の中に捨てる!
現実は、ソフトウェア技術界は絶えず変化する世界である.今日が最善の方法と見なされ、明日は時代遅れになるかもしれない.私たちは完璧なコードを書くことはできない.私たちのプログラムの良し悪しを判断する基準が日進月歩しているからだ.これは不快だ.あなたの作品は、今日はそんなに完璧に見えるが、やがて嘲笑される対象になるかもしれない.最新の最高の開発ツール、設計、フレームワーク、開発方法をどのように努力して勉強しても、私たちはいつも最新の技術の発展傾向より遅くなっています.私にとって、これはプログラマーにとって最も悩んでいることです.私たちは絶えず技術をアップグレードして、ソフトウェアをもっとよくするためですが、思わず感じてしまいます.砂毛布(sand-painting)を作る和尚さん.