rules - チームのプログラミングマインドセットのルールをまとめています。

Question

私はしばらくの間、プログラミングアプローチの理由と、何かを行う方法と同様に考えたことを共有するのに役立つリストの作成に取り組んできました。

このために、次のようなもののリストを作成したいと思いました。

ベストプラクティス、
最善の考え、
最善のアプローチ...

最も効果的な方法で分析、思考、アプローチ、解決、および実装するプログラマーの能力を支援します。

スタックオーバーフロー全体の質問で非常に貴重なコメントを何十も見てきましたが、それらをまとめておく場所を見つけることができませんでした。Stack Overflow については、最も物議を醸す意見があります。ただし、共有してチームを助けることができる賢明な洞察を探しているだけであり、より良いプログラミングを通じて問題にアプローチし、解決することができます。

願わくば、これが、簡潔で深遠で、簡単に共有、繰り返し、レビューできる 1 つまたは 2 つのライナーを集めるための 1 つの場所になることを願っています。回答ごとに 1 つのルールにしておくと、賛成/反対の投票が最も簡単になる可能性があります。

最初から始めます。

DRY - 自分自身を繰り返さないでください - コード、コメント、またはドキュメントで。

score 52 · Accepted Answer

52

コードは、見つけたときよりも少しだけ良くしておきましょう。

于 2009-02-05T00:08:23.383 に答える

score 52 · Accepted Answer

52

コードは、バージョン管理システムに入力されるまで存在しません。

于 2009-02-05T00:10:08.157 に答える

score 32 · Accepted Answer

KISS - シンプルに、ばかにしてください。 機能
する最も簡単なソリューションを選択してください。必要になる前に物事を (あまりにも) 複雑にしないでください。誰もが複雑なフレームワークを使用して問題を解決しているからといって、あなたがそうしなければならないわけではありません。

score 27 · Accepted Answer

他の誰かがそれを修正しません。

問題が発生した場合は、何らかの方法で確実に対処できるように、十分に長く所有権を持ってください。

score 23 · Accepted Answer

要件を収集しないでください -- 掘り下げてください

要件が表面にあることはめったにありません。仮説、誤解、政治の層の奥深くに埋もれている

実用的なプログラマー経由

score 16 · Accepted Answer

16

ベストプラクティス:頭を使う

于 2009-02-05T07:58:32.080 に答える

score 16 · Accepted Answer

「The Zen of Python」にリストされているほとんどすべてが、すべての「Rules of Programming Mindset」リストに当てはまると思います。「python -c "import this"」で開始します。

Python の禅、Tim Peters 著

美しいことは醜いことよりも優れています。
明示的は暗黙的よりも優れています。
シンプルは複雑よりも優れています。
複雑は複雑よりも優れています。
フラットはネストよりも優れています。
疎は密よりも優れています。
読みやすさが重要です。
特別なケースは、ルールを破るほど特別なものではありません。
実用性は純粋さに勝りますが。
エラーは黙って通過するべきではありません。
明示的に黙らせない限り。
あいまいさに直面しても、推測する誘惑を断ってください。
それを行う明白な方法が 1 つ (できれば 1 つだけ) ある必要があります。
あなたがオランダ人でない限り、その方法は最初は明白ではないかもしれませんが.
今は決してないよりはましです。
多くの場合、今よりも良くなることはありませんが。
実装を説明するのが難しい場合、それは悪い考えです。
実装が説明しやすい場合は、良い考えかもしれません。
名前空間は素晴らしいアイデアの 1 つです。もっと多くのことをしましょう!

score 15 · Accepted Answer

15

あなたがあなたの同僚に尋ねて彼のコーディングを中断する前にグーグル。

于 2009-02-05T08:29:07.587 に答える

score 13 · Accepted Answer

怠惰なコーダーの習慣

何かをするように求められたら、最初にそれを実行します (正しい)。

二度目に頼まれたときは、それを自動的に行うツールを作ってください。

3 回目は、ツールがうまくいかない場合は、さらに多くのツールを生成するためのドメイン固有言語を設計します。

（あまり深刻に捉えないでください）

score 10 · Accepted Answer

変化の触媒になる

人に変化を強制することはできません。代わりに、将来がどのようになるかを示し、その作成に参加できるようにします。

実用的なプログラマー経由

score 10 · Accepted Answer

デバッグ時にパニックにならない

深呼吸して考えてみてください！バグの原因について。

実用的なプログラマー経由

score 10 · Accepted Answer

コピーして貼り付けて機能させることはできますが、そのままにしておくことはできません。

複製されたコードは中間段階であり、最終製品ではありません。

score 9 · Accepted Answer

それはあなたが言うこととあなたがそれを言う方法の両方です

優れたアイデアがあっても、それを効果的に伝えなければ意味がありません。

実用的なプログラマー経由

score 9 · Accepted Answer

あなたのコードを保守することになる人は、あなたがどこに住んでいるかを知っている暴力的なサイコパスであるかのように常にコーディングしてください。

出典：コーディングホラー

score 7 · Accepted Answer

コードレビューを頻繁に実施する

コードレビューとその結果としてのリファクタリングは継続的なタスクです。私の意見では、コードレビューに関するいくつかの利点があります。

コードの品質が向上します。
再利用可能なコードを再利用可能なライブラリにリファクタリングするのに役立ちます。
それはあなたがあなたの仲間の開発者から学ぶのを助けます。
それはあなたがあなたの過ちから学び、あなたが以前に書いた天才コードについてあなたの記憶をリフレッシュするのを助けます。

score 7 · Accepted Answer

7

早めに公開し、頻繁に公開する

于 2009-02-05T00:07:17.273 に答える

score 7 · Accepted Answer

7

ビルドブレイカーは昼食を買う

于 2009-02-05T00:11:57.497 に答える

score 5 · Accepted Answer

オープンソース開発に参加する

プロジェクトでオープンソースコードを使用している場合は、バグ修正と改善をコミュニティに投稿することを忘れないでください。それ自体は開発のベストプラクティスではありませんが、努力すべきプログラマの考え方であることは間違いありません。

score 5 · Accepted Answer

使用するツールを理解する

パターンを使用する理由を理解するまで、パターンを使用しないでください。理由を知らずにツールを使用しないでください。フレームワークや言語設計者が常に自分の状況に合っていることに頼らないでください。

score 5 · Accepted Answer

設定より規約

特に慣習が強く、ある程度の柔軟性が犠牲になる可能性がある場合.

score 4 · Accepted Answer

4

あなたの仕事を義務としてではなく、工芸品として考えてください。

于 2009-02-05T02:12:08.860 に答える

score 4 · Accepted Answer

考え！あなたの仕事について

自動操縦をオフにして、制御を取りましょう。常に自分の作品を批評し、評価してください。

実用的なプログラマー経由

score 4 · Accepted Answer

一歩下がって全体像を見る

時々、コードから離れて、抽象的な言葉で何をしているかを考えるべきです。そうしないと、数日後に戻ってくる何かを見逃すことになります。

私はコードを深く掘り下げるのが大好きですが、時々、表面に戻って空気を吸う必要があります...

score 3 · Accepted Answer

オーディエンス - 私たちが構築するものはすべてオーディエンス向けであり、エンドユーザーだけでなく他のコーダーによっても使用されます。両方で使用できることを確認してください。
シンプルさ - 複雑で複雑なものを実装していることに気付いた場合は、おそらく、より効果的でシンプルなソリューションを見逃している可能性があります。
完璧ではなく品質 - 重要なことに注意を払い、時間枠内で品質を提供します。見積もりを 2 倍にした場合、完璧を提供してもお尻は救われません。

score 3 · Accepted Answer

ビジネスにすべてを話さないでください！

リファクタリングは仕事の一部であり、議論の余地はありません。必要なリファクタリングを行うために常に少し「推定」時間を追加すると、それについて不満はありません!

score 3 · Accepted Answer

行き詰まった場合は、それについて話してください (ゴム製のアヒルとしか話していない場合でも)

score 2 · Accepted Answer

ブログ投稿「実用的なプログラマークイックリファレンスガイド」を参照してください。*

score 2 · Accepted Answer

ヤグニ

あなたはそれを必要としないだろう

あなたがしていることに批判的である、別名考えてください！

score 2 · Accepted Answer

量は常に質に勝る

より多くのコーディングを行うと (たとえそれが素晴らしいものでなくても)、優れたコードがどのように見えるべきかをよりよく理解できるようになります。

score 2 · Accepted Answer

芸術である必要はありませんが、時間通りでなければなりません

私が苦労して学ばなければならなかったジャーナリズムの古いルール。

score 2 · Accepted Answer

デザインパターンはあなたの友達です

ギャング・オブ・フォーの本のコピーを参照用にどこかに置いておいてください。

score 2 · Accepted Answer

常にプロトタイプを作成します。10 回中 9 回は、かかる日/週/月の価値があります。当然の結果: プロトタイプに費やされる時間の長さは、メインプロジェクトの長さ/サイズに比例する必要があります。

score 1 · Accepted Answer

コードは非常に単純である必要があります。これを見ると、ドキュメントを読まなくてもコードの機能を理解できます。

しかし、とにかくすべてを文書化することを忘れないでください。

APIが非常に簡単に使用できない場合は、APIに問題があります。正しく使用するのに手間がかからなくなるまでリファクタリングします。

コードを作成する前に、まず調査して、フレームワークに、実行しようとしていることに対する組み込みのサポートまたは拡張可能なインターフェイスがすでにあるかどうかを確認してください。

score 1 · Accepted Answer

バグを早期にキャッチ：

静的に型付けされた言語を使用して、コンパイラーと静的分析が役立つようにします。
ユニットテスト（最初または最後）
コードレビュー
継続的インテグレーション
最後に、最も重要なこと-継続的な学習。

score 1 · Accepted Answer

データベースの場合...

可能な限り正規化します。その後、再び正規化します。

優れたデータベース (構造とデータの両方) を持つことは、プログラミングのストレスを軽減するために重要です。

score 1 · Accepted Answer

これはスティーブ・マコーネルから来ています

「コードのすべての新しい行は、デバッガーを介してシングルステップ実行する必要があります」

score 1 · Accepted Answer

赤、緑、リファクタリング！

TDD またはテスト駆動開発。

開発したい機能の一部についてテストを作成し、まだコードを作成していないためテストが失敗することを確認します。
テストに合格するために必要な最小限のコードを記述します。
効率や明確さなどのために、必要に応じてリファクタリングします。
リファクタリング後、テストがまだ合格していることを確認してください。

score 1 · Accepted Answer

思ったほど簡単ではない

これは別の回答への回答ですが、矛盾しません! どちらも従うべき貴重な原則です。

score 0 · Accepted Answer

ソフトウェアの作成は、家を建てるようなものです。

あなたは青写真、計画、経験、建築家または資格のある商人なしでそれを構築することを試みることができます。

その結果、ほとんどの場合、コストがかかり、時間がかかり、時間とお金を必要とする将来の継続的な驚きに満ちています。

誰かが青写真なしで小屋を建てることができるからといって、彼らがそうすべきだという意味ではありません。

score 0 · Accepted Answer

プログラミングのガイドラインや提案などがなかったので、最後の仕事でチームのドキュメントを作成しました...かなり大きくなり始めましたが、すべて理にかなっています。

喜んで共有させていただきます。しかし、それは1つのルールだけではなく、他の何よりも「コーディングガイドライン」でした。

これが私のドキュメントに含まれているもののサンプルアウトラインです：

        A.ソースコード
           a。フォーマット
           b。変数の命名
           c。エラー処理
           d。ロギング
           e。テキストエディタ
           f。スコープ宣言
           g。コメント/コメントブロック
           h。ドキュメンテーション
           私。API/ライブラリ開発標準

       B.ソース管理
          a。チェックインチェックアウト
          b。バージョン情報
          c。ソース管理には何が属しますか？

そして、これがセクションAの例です。

ソースコード
テキストエディタ：

テキストエディタの選択は、純粋に開発者次第です。フォントは等幅で、18以下、8以上である必要があります。これは開発者の選択ですが、ソースファイルの上部にコードコメントを表示して、エディター、フォント、フォントサイズ、および該当する場合はインデントサイズを示す必要があります。存在する必要があります。詳細については、コメント/コメントブロックを参照してください。

タブ：

タブをソースファイルに含めないでください。タブはスペースに置き換え、インデントを4にする必要があります。

行末：

行末はCRLFの形式である必要があります。ほとんどの{会社名}のソースコードはWindowsプラットフォーム上にあるため、Windowsで読みやすくするために行末をCRLFに設定する必要があります。ソースファイルで行末を混在させないでください。

行の長さ：

行の長さは、ほとんどの行で200文字を超えてはなりません。単一ステートメントソースの非常に長い行は許容されます。関数定義、または関数呼び出しは分割する（そして文書化する）必要があります。（詳細については、API /ライブラリのセクションを参照してください。）

もちろん、これは米国、MMVで機能したものであり、コーディングスタイルに一致するようにルールを調整する必要があります。

score 0 · Accepted Answer

何か（プロセス/ソフトウェア）について少しだけ知っている人は、世界で最も危険な人です。

score 0 · Accepted Answer

自明のコードを書きます (そして、それを文書化します)。

略語や特に子音のクラスターを避けた意味のある名前
実際のコードを疑似コードのように読めるようにするために導入されたばかりの関数
1つのコード単位内で抽象化のレベルを一定に保つなど。

score 0 · Accepted Answer

いくつかのことは、説明されているよりも優れています

仕様のスパイラルに陥らないでください。ある時点で、コーディングを開始する必要があります。

実用的なプログラマー経由

score 0 · Accepted Answer

常にコードのドキュメントを作成してください! 半年もすれば、その仕組みを思い出せなくなります。したがって、ドキュメントなしでコードを記述しないでください。

score 0 · Accepted Answer

0

単体テストのないコードは、定義上、壊れています。

一目瞭然。

于 2009-02-08T00:54:06.363 に答える

score 0 · Accepted Answer

0

SOLIDの原則 (またはその他の原則や方法論のセット)の意図を理解します。

于 2009-02-05T00:47:36.707 に答える

score 0 · Accepted Answer

物事を実際よりも単純にしようとしないでください。

自分が何をしているのかを知ることは、単体テストよりも望ましいことです。

テクノロジーを理解することは、テスト駆動開発よりも望ましいことです。

試行錯誤の方法論で人生を無駄にしたいのはなぜですか?

score 0 · Accepted Answer

初めては決して簡単ではありません。後で毎回行うのは簡単です。それは、初めてどこかへ車で行くときに近道を見つけようとするようなものです。GPS前。

score 0 · Accepted Answer

最小限のコードしか必要としないソリューションを見つけるように努めてください。

score 0 · Accepted Answer

「I just can't see how it can fail」は単に「It can fail, I just can't see how」という言葉を並べ替えたものです。すべてをテストしてください！

rules - チームのプログラミング マインドセットのルールをまとめています。

64 に答える 64

ソースコード

Related

Reference

rules - チームのプログラミングマインドセットのルールをまとめています。