何かをコーディングする方法がわからないときに使用するヒントやテクニックは？[閉まっている]

UIデザイナーとしての経歴があります。そして、私はロジックの一部を書くのが少し難しいことに気づきました。たまにうまくいくこともありますが、たいていの場合、ハッキングされてしまいます（通常は時間がかかります）。そして、私はプログラミングが好きではないということではありません。実際、私はそれがデザインと同じくらい好きになり始めています。数字や論理よりも、色や形の方が得意だと思うことが時々あります（しかし、それを変更したいのですが）。

私が通常行うことは、インターネットでソリューションを検索し、例をコピーしてアプリに挿入することです（これはあまり良い習慣ではないことを知っています）。

1つのヒントは、実際のコードを書く前に、コメントとしてロジックを一般的な英語で書くことだったと聞きました。

他に使用できるヒントやテクニックはありますか？

赤ちゃんのステップ。

大きな問題を小さな問題に分割します。次に、小さな問題を解決します。

自動化された単体テストでソリューションを小さな問題にバックアップできる場合のボーナスポイント。

私は通常、物事をじっくり考えながら紙に書き留めます。こうすることで、疑似コードを記述したり、描画（通常は両方）を実行したりできます。描画ソフトウェアの制限やコメントに何が収まるかについて心配する必要はありません。

少なくとも少し複雑なことをしている場合は、まず紙に書いておく必要があります。そうしないと、あなたが言ったように、何かハックになってしまいます。

私が何かハックになってしまった場合、それはほとんどの場合うまくいきます。時々私はそれが最終的に機能するまでそれをハックすることができます。紙の上で時間をかけて考えてみると、問題なく動作することがよくあります。

あなたはあなた自身の質問にある程度答えたと思います、そして私はそれを悪い意味で意味しているのではありません-それはコーディングする方法を学ぶ最良の方法は単にコーディングすることであるという一般的なアドバイスです。個人的には、ソースからコードを直接コピーしないようにします。何が起こっているのかが明確でない限り（つまり、何かを行うための別の良い方法があるとは限りません）、これらの種類の問題の多くは構文的です。時間をかけて何が起こっているのかを理解し、あなた（または誰か）がそれをどのように実装しているかが最も重要です。

開発方法の学習に費やしている間に、MVCテクノロジーを使用することは、Rails（現在使用しているもの）やiOS / Cocoa Touchなどの設計方法を理解するための優れた方法であることがわかりました。このようなオブジェクト指向の設計環境で作業しているので、モデルとそのロジックがビューから分離されている（コントローラーはそれらを結合する接着剤である）と考え始めると、その方法についても考え始めるオブジェクトを論理的に抽象化したままにすることができますが、（うまくいけば！）複雑ではありません。

もちろん、これは私自身の経験に基づいていますが、あなたの質問に対する私の考えが何らかの助けになることを願っています。

すでに与えられた答えに加えて、ジャンプスタートを始めるための最良の方法の1つは、シンプルでソースコードが利用可能なアプリケーションから学ぶことです。

これは、Githubのようなソーシャルリポジトリが優れている点です。例を参照するのに最適な場所。そして、それを見つけたら、それを自分のものとしてすぐにフォークして、アプリケーションにやりたいことを行うことができます。

• あなたはそれを実行できます
• あちこちで微調整して、物事がどのように変化するかを見てください
• より快適になるにつれて、より大きな変更を加えます
• あなたはすぐに本当に勉強していることに気づくでしょう

別のオプションは、非常に多くの異なる場所で文書化されている古典的なサンプルリファレンス実装を使用することです。たとえば、JavaのSpringフレームワークは、由緒ある「Pet Store」の例を使用しています。その例はGithubでも見つかると思います。

他のフレームワーク/ GroovyのGrailフレームワークなどのテクノロジーは、ブックや著者などを永続化して表示するために、ブックアプリケーションなどの他のクラシックを使用します。

私が試した最後のオプションは、優れたプログラミングブックに従って、例を手作業で入力し、Githubのようなリポジトリに配置することです。これには少なくとも2つの利点があります。1）覚えやすい方法でかっこいいことを思い出すのに役立つ独自のメモ付きのリファレンスがあります。2）難しい場所に入ると、友人や同僚に簡単に連絡をとることができます。コードを確認し、アドバイスを添えてください。

科学、特にプログラミングは、実際には他人の経験に基づいています。比喩的に言えば、理解するまでコピー/貼り付けしてから微調整することが、開発者がエンジニアになるのに役立つものです。

あなたの問題について誰かに報告しなければならないことを想像してみてください。
問題を分析します。できるだけ明確に定式化してください。疑似コードを書き、図を描きます。
問題を引き起こしている可能性があるものと、アプローチが間違っている理由について考えてください。
あなたの問題を見ることができる他の見方があるかどうか自問してください。
ただそれを頭の中で行うのではなく、紙（またはコンピュータ上の文書）に書いてください。

それでもすぐに役に立たない場合は、しばらくの間問題について考えないようにしてください。おやすみなさい。まだ解決策はありませんか？問題をグーグルで検索するか、SOを検索して解決策を探してください。

他のすべてが失敗した場合は、SO（または、特定の質問により適切な場合はSEプログラマー）に質問してください。質問するときは、実際に「レポート」（またはその重要な部分）を必ず含めてください。
答えが出たら、自分のアプローチがうまくいかなかった理由と、自分で解決策にたどり着くことができた理由を考えてください。同様のアプローチを必要とする将来発生する問題の解決策を見つけるのに役立つ場合があります。

紙で考えることに同意します。原則として、最初に、必要なすべての情報項目とその取得元を特定します。エレガントである必要はなく、正確である必要があります。ビジネスロジックの質問と設計戦略は、通常、このプロセス中に発生します。

それを踏まえて、アプリケーションでエンドツーエンドで作業するJava開発者として、物事を層（プレゼンテーション、Web、ビジネスロジック、データアクセス層）でさらに分割します。時間があるときは、通常、この部分でクラス名を書きます。

最後に、コードを記述する前に、常にバックエンドのテストを実行するように努めています。すべてをエレガントに接続できますが、バックエンド（データベースやWebサービスなど）にアクセスできない場合は機能しません。

ここでは、テスト駆動開発のいくつかの原則が役立ちます。

複雑な問題を解決する最良の方法の1つは、特定のユースケースでそれを解決してから、一般化を発見することです。TDDを使用すると、まさにそれが促進されます。単純なテストケースを作成して機能させ、次に別のテストケースを作成して機能させます。最後に、同じロジックで両方のテストケースを処理できるようにする一般化があるかどうかを確認します。可能であれば、おそらく他の多くのテストケースも処理します。すべてのテストケースをいつでも実行できるため、何かを壊すことを心配することなく、ロジックを自由に改善できます。このように、ハッキングされたソリューションはハッキングされたままである必要はありません。

テスト駆動開発も促進します

• 大きな問題を小さな問題に分割するので、適切なテストカバレッジを取得しやすくなります。
• 実装の詳細に行き詰まる前に、本当に達成したいことについて前もって考えます。
• 可能な限り簡単な方法でテストに合格しようとすることにより、過剰なエンジニアリングを回避します。通常、簡単なソリューションが最適です。

実際にその質問に正確に答える本があります：

プログラムの設計方法– Matthias Felleisen、Robert Bruce Findler、Matthew Flatt、Shriram Krishnamurthiによるプログラミングとコンピューティングの概要

彼らは現在第2版​​に取り組んでおり、その後、第2巻（コンポーネントの設計方法）に取り組んでいます。

この本の本当にすばらしいところは、プログラムを設計するための一連のレシピを提供することです。言い換えれば、プログラムを設計するために（半）無意識に従うことができるステップバイステップの指示を提供します。

または、別の言い方をすると、プログラムを作成するための一連のプログラムが含まれているため、プログラムの作成方法を理解する必要はありません。作成者がプログラムを理解しました。

上記の回答に加えて、ロジック自体を知ることではなく、作業しているフレームワークと言語を知ることも時々あります。すべてのフレームワークまたは言語には独自の特性があり、それに慣れるのに非常に役立ちます。