エディターを開くのを恐れていませんか？

ある時点で、最適で論理的で読みやすいコードを書いていることに気づき始めましたが、ゆっくりと書いていました。 少なくとも、15年前よりずっと遅い。 はい、あなたは涙せずに古いコードを見ることはありません。すべてをより最適に、そして少なくとも読みやすくすることができます。 しかし、コードはすぐに書かれました。



問題は制御されています。 私はコードを制御するのが難しくなり、深くなりました...この制御にあまりにも多くのリソースを費やし始めました。



基本原則は簡単です。 ケースの10〜20％が制御の対象である場合、制御は... 0％のリソースを費やす必要があります。 バグと書き換えは引き続き行われます。 ただし、コーディングとデバッグを分離し、コーディング中にエラーをまったく忘れることをお勧めします。

少しの理論と類推

優れた心理学者レフ・セメノビッチ・ヴィゴツキーは、人間の行動が反復的であることを示しました。 そして、それらは、アクション、このアクションの制御、およびエラーの修正で構成されます。



たとえば。 子供が手でおもちゃに手を伸ばすとき、これはいくつかの反復で起こります：

• 手を前に出す
• おもちゃまでの距離を推定する
• 押し進める
• 触覚接触を確認する
• 指にコマンドを与えて近づきます。
• 等

大人の場合の例は、マウスの動きです。 リンクに「突く」と、最初の素早い動きでカーソルをリンク領域に移動し、カーソルの位置を評価して動きを終わらせます。 追加のクイックジャーク、または動きの開始時よりも少し遅く、よりスムーズに。 動きが非常に速くて馴染みのあることがわかったので、動きは団結しているようです。



自動化の蓄積は、制御の切断です。 または、それをより最適な潜在意識の形に変換します。

1. 基準点による制御-マウスを使用した例。 カーソルの動きを常に制御するのではなく、ターゲットの隣の1つの制御点で制御します。 これは非常に迅速かつ自動的に行われるため、ムーブメントは統一されているように見えます。
2. 潜在意識のコントロール。 刺激に対する標準的な反応がある場合、潜在意識反応がすぐに生成されます。 リンクを見逃した場合、「誰が責任を負い、何をすべきか」を分析し始めません。 潜在意識は、バックグラウンドでの動きの最終段階を計算する（そしてすぐに実行する）のに十分な情報を持っています。
3. 割り込み制御。 動きが「自動化に満ちている」場合、何か問題が発生した場合に制御がオンになります。 たとえば、マウスドライバーまたはコンピューターがシャットダウンしました。 軌道計算は複雑になりました。 この場合、スピーチ装置をオンにして感情を「排出」し、いくつかの意識的な反復で、マウスを持ってきます。 ドライバーがバギーになることはめったにありません（また、ゴミが巻き付いている車輪はほとんど歴史があるため）、制御が必要になることはほとんどありません。

そして最も重要なことは、私たちはリンクを見逃すことさえできないと思います。 （モバイルブラウザを思い出させないでください）。

発行価格

スボーロフ・レズン水族館は、特殊部隊とサーカスのパフォーマーの訓練の違いに言及しています。



「私はすでに読み書きができ、底なしの奈落の底を電信線で歩くことができることを理解しています。 それはすべて心理的な硬化です。 人は何も悪いことが起こらないことを確信しなければならず、そうすればすべてがうまくいきます。 サーカスのアーティストは基本的なことに何年も費やします。 彼らは間違っています。 科学的なアプローチはありません。 彼らは、心理学に十分な注意を払わずに、身体運動に基づいてトレーニングを行っています。 彼らはたくさん訓練しますが、彼らは死が好きではありません、彼らはそれを恐れています...」





著者は誇張しています。 しかし、意味は明確です-コマンドは制御を放棄し（私は倒れません）、サーカスは完全に制御を発達させます（私は倒れますが、ほとんどいつでも状況を修正することができるので、私はほとんどいつでも制御しなければなりません）



平衡を維持する技術は単純です（特定の動きのあるワイヤ上でなくても、たとえば狭いボード上で）。 あなたは、明確な足で一定の速度で行く必要があります。 足の設定や体のずれの小さな間違いはひどいものではありません。 その修正はひどいです。 失われたと思われるバランスを回復しようとすると共鳴が生じ、それぞれの新しい試みがさらに揺れます。 ボードが高ければ高いほど、エラーの価格が高くなり、早期の制御がオンになります。 そしてそれで、致命的な「間違いに取り組む」。



したがって、2つのことが必要です。 わずかな逸脱には対応しないでください。 前進運動自体がそれらを滑らかにします。 そして、共鳴することなく、明確に大きな間違いを修正することができます。



特殊部隊は毎日奈落の底を通過するのではなく、特別な機会に（少なくとも保険なしで）行きます。 したがって、高所での間違いを恐れず、したがって、高さ自体を恐れないように教えるだけで十分です。 ミスに関する作業の不足（または限られたオプション-突風に対する反作用）は、あまりにもまれに死亡します（訓練を受けた人はめったに致命的なミスを犯さず、保険もかかります）。 そして、あらゆる可能性のあるケースについて「反反射」を開発するのに何年も費やすべきではありません。



サーカスにとって、そのようなパラダイムは文字通り致命的です。 多くの場合、彼らは歩くだけでなく、しばしば保険なしで、彼らはワイヤーに沿って歩きます。 ダンス、ジャグリング、ジャンプ。緊急事態の可能性を高めます。 エラーの制御と作業が得られない場合、いつの日かそれほど美しくなく、子供たちはサーカスで泣き、アーティストはこれを見ません。

これをすべて知っているコードを書く方法は？

理論的な部分は終わりました。 リラックスせずに練習しましょう。



私たちが進めなければならない主なことは、私たちが思うよりも私たちのコードに少ないエラーがあるということです。 少なくとも、コードを書いている間はそれを信じるべきです。 理想的には、私たちは原則として誤解することはできません。



ナンセンスと言って？ そして、コードが最初の試行で機能した場合、私たちの反応は何ですか：WTF？!!! 私は何を間違えていますか？!!!



年齢の経験により、私たちは間違っているべきだとますます確信しています。 そして、私たちは事前にこれを待っています。 3行書きましたか？ （！）間違いがあるかもしれません。 確認する必要があります。 間違いない？ これはなんとなく疑わしいです。 喫煙して考える必要があります。



はい、できますし、間違えますが、パラノイアの母が統治すべきテストとデバッグ中にのみこれに注目する価値があります。 事前に失敗を予測して、それらに頼るべきではありません。 疑いは、制御するリソースのタイミングの悪いリダイレクトです。



心配しないで、デバッグするのに十分な時間を取っておきます。 そして、それが多すぎることが判明した場合は、明確な良心をもってHabrを読んでください。

免責事項

これらの推奨事項は、経験豊富なプログラマに適用されます。



キャリアを始めたばかりの場合は、どのような場合でもコントロールを怠ってはいけません。



慎重に自分自身を制御すればするほど、より迅速な自動化が得られます。 実際、制御が必要なのはまさにこのためです...自動化のより効率的な生産のために。 開発のどの段階でも。



さらに、理解できないイディオムや行動に遭遇した場合、それが何を意味しているのかを理解するのが面倒ではありません。 行動を理解し、何がいつ起こるのかを理解するために、時間をかけて実験してください。 あなたの自動化が失敗し始め、すべてのステップでチェックしたいタスクに到達したら...この記事を覚えておいてください。 おそらく役に立つでしょう。



だから...

大きな反復で作業する

作成、チェック、およびデバッグのフェーズを分離します。 コードを間違えていないことを考慮してください。 少なくともそれを書いている間、あなたは間違ってはいけません。 一般的に。



停止せずに可能な限り多くのコードを書き、少なくとも機能ブロックを終了するようにします（更新：ただし、今日は昼食前（大きな休憩の前）にテスト/デバッグを終了する時間を残し、長時間延期せずに延期しないでください） 。 コードのチェックとデバッグの停止は、リソースが浪費され、リズムが迷子になるコンテキストを切り替えることです。 コード検証は、デバッグの前に別のフェーズで実行できます。 そして、「上から下へ」デバッグを開始します。 これを開始すると、コードがすぐに、または構文エラーを修正した直後に機能する頻度に驚くでしょう。 （更新：試してみて、この記事を書いたのでとても驚いた）。



とりわけ、チェックのために停止しないでください。 大まかに表現する場合、ディレクトリ内の関数呼び出しへの引数の順序を確認する必要はありません。 これは後で行うことができます（おそらく必要はありません）。 （更新：ASSERTを使用していて、すぐに条件を見つけられない場合は、コードにラベルを付けて先に進みます。厳密な方法論を使用する場合は、_ASSERT（false）を記述し、レビュー/デバッグの前にこの場所を忘れてください。）



小さなコードのチェックを停止しないでください。 彼らがなじみのないイディオムを使ったり、「ひどいデザインを盛り上げた」としても。 コードが機能していると仮定して先に進みます。



同じタイプの複数のブロックを使用する必要がある場合（およびそれらが機能していることを確信できない場合）、通常のように最初のブロックをチェックする必要はありません。 自分に合った方法を書くか、ブロックを関数に入れてください。 結果としていくつかのブロックを修正することは、ペースと思考を失うよりも有益です。



更新：大量のコードは、コードの品質を理由なく犠牲にしなければならないという意味ではありません。 最初にコメントを書き、次にブロックしてからコードを書きます。 ヒッチが発生しないように、このプロセスをよく理解してください。



はい、簡潔さと読みやすさのためにパフォーマンスを犠牲にする価値がある場合があります。 より正確には、必要なしにパフォーマンスを気にしないでください。



はい、時にはいデザインを残す価値があります。 彼女の変更が私たちを遅らせ、私たちが全速力で急ぐ準備ができている場合。 このような場合、コメントにタグを入れてください。 TODOとHACKを使用します。 それらは最終レビューの前に大いに役立ちます（当然、マークしたコードのように、もはやアルファであるべきではありません）。

デバッグする前に確認する

大量のコードを実行する前に、「実行」してください。 最初に、イディオムの正しいスペルまたは関数/メソッドの呼び出しを確認できます。 少なくとも、ディレクトリに登らなければならない場所を覚えておいてください。 第二に、明らかなエラーはすぐにあなたの目を引きます、そして、それらは熱心な追跡で迅速かつ無痛に修正されることができます。 第三に、私たちはもう一度決定を見直し、よりよく覚え、テストする必要がある問題領域をすぐに書き留めます。 第四に、私たちはまだそれをしなければなりません。なぜ時間を無駄にしますか？



ただし、すべてが正しく記述されていることが確実な場合は、すぐにコードを実行して実行する必要があります。 前述したように、最初の試行で意図したとおりに機能する頻度に驚くでしょう。 より多くのコントロール-より多くの不確実性と間違っている可能性が高くなります。



しかし、何かがうまくいかなかった場合は...

デバッガーで急ぐな

ヒューストン、問題があります。



コードに実行時にブレークポイントまたはデバッグ出力を貼り付けますか？ やめて！



それは私たちに何を与えますか？ 2つのオプションがあります。 まず、ここにエラーがないことを確認し、別の場所のチェックを開始します。 次に、エラーがここにあることを確認し、喜んで修復します。 素晴らしい方法。 明確な良心をもって「効果的に」労働時間を過ごすことができます。 ハブに座っているのではなく、デバッグしています。



実際、デバッグするポイントを選択したとき、作業の60％を行いました。 私たちはそのように彼女を選んだだけではありませんでした（そうだと思います）。 残りの40％を実行しましょう。 まあ、または少なくとも30％、10％はエピックフェイルの確率を残します。



必要なのは、一歩後退することです。 コードで戻る。 この場所で問題が発生することが予想されます。 なぜ正確にここに？ ここで何が間違っているのでしょうか？ 多くの場合、コードを見てそれを見るのに十分です。



しかし、何らかの理由で、このコードが機能しないことを確認する必要があります。 そして、これが機能しない場合は不要です。 Dr. Houseを思い出し、不必要な検査なしですぐに患者を手術に引きずりました。



そして、「注視法」を使用して何かを見つけられなかった場合はどうなりますか？ ええと...まだこの場所にベンチマークを置く必要があると確信していますか？



問題を診断するポイントが必要な場合は、少なくともバイナリ除算を使用するのが効率的です。 ファンクションブロックの途中でエラーが発生した場合、すぐに確認しましょう。 コードを半分に分割し、ベンチマークを設定しました。



いいえ、まだ最初から踊りたいです。 わかった しかし、ここに問題があります。 最初のフラグメントにエラーがある場合、「より深く掘り下げる」ことができますか？ つまり、エラーをより明確に特定できるようなデバッグ出力を作成します。 しますか？ すぐに書きましょう。 プログラムを2回実行する理由。 おそらく、これにたどり着くこともありません。必要な追加情報を考えるだけで、プラグの場所がすぐにわかります。



同じロジックで、一度にさらにいくつかの参照ポイントをチェックすることは理にかなっています。 エラーの80％は信号（アクション、結果）の欠如であり、歪みではありません。 さらに、結果の歪みは、ほとんどの場合、前の段階では存在していません。 いくつかの基準点を配置して、私たちはプログラムをもう一度見ていきます。 そして、デバッガーを起動する前に「魔法のように」エラーを見つけます。



疑わしい障害のある場所の上のコードを調べることを恐れないでください。多くの場合、すでに「私はここにいます！」というサインがあります。 待って！ あなたの間違い。」

事前に問題を考えないでください

非常にアグレッシブなゲームで有名な有名な（おそらく最も有名な）ポーカープレーヤーDoyle Brunsonは、次のように述べています（引用の信authentic性を保証することはできません）。 彼は最初にレイズします。 そして、後でそれについて考えます。」



問題が解決されておらず、その理由を知っている専門家が仕事を始めることさえ拒否したときの「素人コンプレックス」を思い出しましょう。 そのような知識を持っていない初心者が仕事を始め、...します。



実際、これは頻繁に発生することはなく、非常に頻繁に発生することもありません。 専門家は、たとえば必要な400行から300行のコードを書いた後、問題に遭遇することを知っています。 そして、彼はどれを知っています。 彼はコードを書き始めませんが、将来の問題の解決策をすぐに見つけようとします。 解決策を見つけます（プロがSTFWでなければ、彼はプロではありませんよね？）、しかし、この解決策は不完全であり、欠陥があることがわかりました。 この問題領域の解決策を見つけたら修正できます...そしてそのような解決策は、今だけです...ニュアンスがあります...



ご想像のとおり、これはうつ病への直接の道です。 Habr、bash、ジョーク、ニュース、LJ、さらにはポルノサイトでさえ政治的な議論をしています。 うつ病は確実に後退しますが、その仕事には価値があります。 どうする？



ジャンプする。 ジャンプする必要があります。 つまり、問題のないコードの部分を記述します。 私たちの経験により、事前に気づいた恐ろしい問題に到達すると...簡単な方法で解決されるか、回避されるか、またはそのような機能が不要になることが判明する場合があります。



たとえば、多くの場合、問題の発明は人間工学に関連しています。 「すぐに」できるように、このような便利なコントロールを作成したいと思います。 すぐに森に。 一部のプログラマーは、ユーザーが地獄で燃やすべきだと提案しています。 だから彼らはすぐに苦しみ始めます。 不快なインターフェースから。



他のすべてが時計のように機能する場合、インターフェイスの専門家やこのタスクに失敗したインターフェイスの専門家を雇っていない上司が地獄で燃え尽きます。



フォレストにはパフォーマンスの問題もあります。 私はどういうわけか、1000回の反復のループをより最適に書き換えようとしていることに気付きました。 それは良いことのようです。 しかし、その前に、メモリ内のメガバイトJSONファイルを解析します。 一時ハッシュのネストをレベルごとに減らすことを誰が気にしているのか。 ユーザーは1秒間待機します。 彼らは彼に20ミリ秒の天気を与えますか？



はい、生産性も森の中にあり、森は火室の中にあります当然、合理的な限界まで...現在、ユーザーが1000人いる場合、100万を要するアプリケーションを作成する必要はありません。 もちろん、1,000人のユーザーだけを対象にアプリケーションを作成するのは悪いことですが、1桁以上も再パッケージすることは最適ではありません。 「顧客」が増えるにつれて、機能とエンジンの両方を変更する必要があります。 そして、なぜ書き換えるコードの理想性を不必要に制御するのでしょうか？



はい。生産性の大きなマージンを備えたアプリケーションをすぐに作成できる場合は、まさにこれが必要です。 しかし、アプリケーションを3、2、まあ、あるいは少なくとも1000（半分は現在の）1000だけ作成できる場合は、そのようなアプリケーションだけを作成する必要があります。 そして、それをファイルで粉砕してみてください。 動作の仕組みと動作が遅い理由が明確な完成したアプリケーションのオーバークロックは、強力なエンジンをゼロから作成するよりも簡単です。 （あなたが私を信じていないなら、あなたは免責事項を読んでいない）。



座ってコードを書くだけです。 完璧ではありません。 私はあなたがそれをプロセスにもたらすと信じています。

急いで新しいシャベルを探すな

Perlの後、Pythonがどのように子供っぽく腹を立てたのか覚えています。 ドライバーは路面電車に乗らざるを得なかったようです。 はい、路面電車は速く、レールは滑らかで光沢があり、速度は同じですが、...デフォルトで意識的に使用していたところ、Pythonは例外をスローしました。 突然、ハッシュ内のそのような要素が存在しない可能性があることを知りません。 これは災害です！



彼らは私をコントロールし始め、私は怒って時間を無駄にしました。 時間を失い、怒ります。 最善の解決策はルビーであるように思えました（アヒルについての冗談を覚えていますか？）。



一方でそれは良いことです レールのある指でもそれを理解しました。 同時に、パールオオムギCatalystの仕組みをよく理解しました。 一方、私はプロジェクトを3か月間放棄し、今はPythonで書き戻しました。



実際、Pythonで「pythonic」を記述し、パール大麦のパラダイムを適用しようとしないでください。ソースの混乱-メモリの制御された混乱-出力の順序。



上記のウェルターから結論を出すことは困難です。 しかし、彼はそうです。 開発ツールまたはライブラリを急いで変更しないでください。



理想的な開発ツールはありません。 新しいシャベルでは、バヨネットはより便利な角度に曲げられます。 しかし、ここにペンがあります...非常に珍しいとあなたがヒットするように努めていますどこを知っています。



ツールを選択する際の問題は、再びうつ病への道です。 新しいツールが機能するかどうかは確実ではありません。 そして、勉強する時間を費やさなければなりません。 テストを行い、バンプを詰め込みます。 詰め込まれたバンプは、ますます小さなオペレーションにロールダウンされています。 そして、慣性と速度の損失。



更新：新しいツールを試してみる価値はあります。 そして、彼らがアイデアや期限を使い果たしたときではありません。 またはその両方。 このような状況で新しいツールを探すことは、しばしば立ち止まることです。 遅かれ早かれ、アイデアがないときにロールバックが行われ、作業全体が完了するか、それを行うほど重要ではないかのいずれかになります。 少なくとも1日14時間行います。 今回は、新しいことに専念するのに適しています。



そして、火が、ツールの間を急ぐ前に、あなたがよく知っている電流に対処するとき。 あなたは彼を十分に知っていない可能性があります。 おそらく、深く掘り下げて、必要なものを正確に理解できます。 そして、盲目的にたくさんの新しいツールを試すのに時間はかかりません。 座ってファイルでシャベルをすばやく処理するか、市場に行って必要なシャベルを正確に購入します。

投げることを恐れないでください

記事の冒頭で紹介した心理学者の名前を正確に覚えていませんでした。 混乱の中に「心理学入門」が見つからなかったら、B.Yu。 Hippenreiter、その後、この段落を単に削除して、出版を延期しないようにします。 ドラフトのエラーから記事を削除しましたが、それらの多くがありました。 感じます。 どこかしかわからない;）



しかし、記事が好きなら、エラー要因は重要ではありません。 気に入らない場合は、さらに重要ではありません。



何かをしたい場合は、すぐにそれを行います。 そしてすぐに公開します。



競合他社を恐れないでください。 何かを終えなかった場合、競合他社もおそらくそれを終えないでしょう。 そして、あなたが終わらなかったものそのもの。 彼らはあなたを市場から追い出すために急ぐ必要もあります。 そして、彼らがあなたの過ちを繰り返すとき...あなたは新しい白い馬の上に新しいバージョンを出てくるでしょう... 7本の足で。



その過程でベルベットで磨くことができます。 アップル製品があります。 価格の大部分が技術的な美学であるところ。 しかし...彼らは何か他のものを寄付しました。 たとえば、完全を期すために、最初のMacには拡張カード用のスロットがありませんでしたが、これはIBM PCの損失の要因の1つでした（少なくとも販売面では）。



はい、ジョブズは不必要なものを放棄するリスクを負いました。 そして、彼はその戦いに負けたかもしれないが、彼の強みであるデザインに焦点を合わせていたが、彼は最終的にアップルを現在のアップルにした。



引っ張っていないものや、今すぐ退出できないものを破棄します。 トリミングされたベータ版をユーザーに提供することを恐れないでください。 それらは非ロールアルファよりもはるかに優れています。



エレガントなソリューションのほとんどは、運用中です。 主なことは、それを開始することです。

送信する...

誰かがあなたの仕事は必要ない、それは不十分だ、今は誰かが来てもっとうまくやるだろうと言ったら...一般に、非建設的。



に送る...



すぐに。 インテリジェンスとあなたがちょうどそれをした理由を説明しようとする試みなしで。 もちろん、もちろん彼はあなたの上司ではありません。 この場合...私は上司を数回送る危険を冒しました。 そして最後に、特に上司が変わった場合に勝ちました。



あなたがうまくいかなかった場合、これはあなたの次の仕事をより良くするための言い訳にすぎません。 またははるかに良い。 主なものは、停止することではなく、振り返ることも見下すことでもありません。



あなたは何かをしました。 あなたは経験を積んでいます。 完了した作業（少なくとも完了）を楽しんでいました。



更新しました。 建設的な批判と見なされるものは何ですか？ これは、作業を改善する方法に関する提案です。 特に実装が簡単で合理的です。 これらは、新しいアイデアを引き出すことができる同様のプロジェクトへのリンクです。 これらは、たとえばパフォーマンスを質的に飛躍させる必要がある場合に役立つテクノロジーです（非常に新しいシャベルです）。



そして、非建設的な批評家...これは制御システムです。 10％の場合に使用されます。 したがって、必要ありません。

UPDそしてもう一度要約

私のすべての悪いアドバイスに従えば、次のことをすべきです：

-エラーの可能性に注意を払うことなく、最小限のドキュメントを使用して、機能的に完全な大きなコードを記述します。

-コンパイルの前に、コードを実行し、可能な改善点とテスト計画を概説します。

-エラーが表示された直後にデバッガーを使用しないでください。ただし、論理的に検出するようにしてください。

-過度の完璧主義に屈しないでください。

-コーディング、レビュー、デバッグを削減します。

-機能的完全性（およびもちろん安定性）に達したらすぐに運用を開始します。

-建設的な批判を歓迎し、非建設的な批判を突然停止します（すみません、コメントで行き過ぎたようです）。

-自分の強みを疑わないでください。

そして最も重要なこと

あなたがしたいこと、あなたがすべきことをして、できるだけめったに振り返らない。 再度確認する必要はありません。



すべて順調です。