Q&A
仕事で使っているツールや開発環境など、具体的に挙げていただいた方が、的確な意見が貰えると思います。
仕事でプログラミングをしていて、大した作業量でもないのに他の人の２倍くらい時間をかけてしまいます。自分ではふつうに書いているつもりなんですが、どこで差がついているのかがわかりません。
何か仕事を早くするのに役立ったツールや考え方などありましたら教えていただけないでしょうか
回答13件
0
作成するプログラムの種類や、使用する言語によっても違ってくると思いますが、幾つかのポイントがあると思います。
###1. 定型処理のパターンを覚える
どのような言語を使用して、どのようなプログラムを作成するにせよ、頻繁に登場する決まりきった処理のパターンが必ず有ります。
たとえば、ファイルの入出力処理や入力値のバリデーションなど、過去にご自分や諸先輩方が作成したプログラムを見直すと、たくさんの「よく見かけるパターン」が見つかると思います。
これらの、いわゆる決まりきった処理については、都度、一から考える必要はなく、さらに言えば、逐一コードを手入力する必要さえありません。
場合によっては自分用のテンプレート集（テキストファイルにメモを残す形で十分実用になる）を作成しておき、それをコピペして要所要所を修正することにより、コーディング時間を大幅に短縮することが出来ます。
###2. ツールをうまく活用する
Eclipseのような統合開発環境（IDE）の 補間 や スニペット 機能を活用すると、新規にコードを入力する祭にも、タイプング量を格段に減らせる上にタイポによるつまらぬトラブルを未然に防ぐことも出来ます。
IDEでなくても、最近のテキストエディタは各種言語に対応していて、仮に補間機能がないとしても予約語を見やすく色付けしてくれます。そのように「見やすさ」を工夫するだけでも、コーディングのスピードを上げる事が出来ます。
###3. コーディングスタイルを工夫する
可読性の向上は、思考のスピードやデバッグの効率に大きな影響を与えます。
また、ちょっとしたコーディングスタイルの違いによって思わぬバグを誘発してしまう場合もあるので、コーディングスピードの特に速い先輩方と自分のコーディングスタイルのちょっとした違いにも、注意深く観察して「技」を盗んでください。
###4. 直ぐにコーディングしない
（過去の個人的な経験からすると）コーディングが遅い人ほど、あまり準備しないまま「直ぐにコーディングを開始」してしまう傾向が強いようです。しかも、１行めから順番にコーディングして行く人が少なからずいます。
しかし、コーディングの速い人の作業の仕方を盗み見てみると、
- まず骨組みを作成してから細かい部分を記述する
- 細かい部品を作成してテストを済ませてから全体を組み立てる
- テストのための小道具を準備してからプログラム本体のコーディングに取り掛かる
など、随所に工夫が見られます。
こうした事柄は、いわゆる教科書からは学びにくい分野ですので、可能であればアジャイル開発における「ペアプログラミング」のようなことを、優秀な先輩と組んで数回やってみると良いです。
とは言え、職場によってはなかなか実践しにくい環境にあるので、作業を妨げないよう注意しながら、諸先輩方のプログラミングの様子を覗いてみてください。その際には、ディスプレイそのものだけでなく、先輩方の視線がディスプレイ（あるいは印刷されたプログラムソース）のどこに注がれているかにも注目してみてください。
あるいは、自身がデバッグに詰まった場合など、先輩方に相談する（助けてもらう）際には、エラーを解消すること（どこが間違っていたか）よりも、先輩が『何をどの順番にどのように確認』してバグを発見し、どこを修正し、修正後に『どこをどのように確認』してデバッグを完了させたか、という点に細心の注意を払って技を盗みましょう！
一朝一夕で身に着くことではありませんが、コツコツと努力すれば確実にコーディングが速くなります。ぜひ、頑張ってください。
投稿2016/03/16 14:50
総合スコア5936
定型処理のパターン・・・確かにもう考える必要がない部分はいっぱいありますよね。DB操作部分とかは似た書き方が多いですし、パターンを見つけてメモしていくのいですね！
ツールの活用は最近意識し始めてて、IDEのショートカットを使うようになったんですが、スニペットは全然使えてなかったです。いい使い方がないか模索はしたんですが、変数を割り当てるような使い方ができないと使いどころが思いつかなかった感じでした。。
コーディングスタイルについてはコンパイル時にスタイルチェックがかかるので最近は少し思考停止しちゃってました。。
先輩方のコーディングはすごく見てみたいです！ペアプロというんでしょうか、やったことがないですが、ちょっとできないか相談してみようかな。。
> まず骨組みを作成してから細かい部分を記述する
思い返してみると、骨組みが超ざっくりすぎて全然使えない骨組みだったことが多々ありました。。骨組みの方針が決まったら一旦確認するようにしたんですが、そこまでおんぶに抱っこ状態だと先輩に申し訳なくてやめてしまったんですが。。やはり骨組みは仕様と設計を踏まえてじっくりやらないといけなかったですね。
> 細かい部品を作成してテストを済ませてから全体を組み立てる
テストを先に書こう！というのはよく見かけていたんですが、全然実践できてませんでした。早速今日テストファーストで試してみます。
プログラム書くのって本当に職人技なんだなと思いますね。先輩の動きはどこかのタイミングでじっくり見てみたいです本当に。
ありがとうございました！
0
ベストアンサー
仕事を早くするのと、プログラミングを早くするのは、別のスキルだと思うので、
プログラミングに関してだけ、思うことを書いてみます。
１．早い、品質良い（バグが少ない、拡張性あり、保守性あり）
２．早い、品質悪い（バグが多い、拡張しようがない、本人しか直せない）
３．遅い、品質良い
４．遅い、品質悪い
プログラマーはこんな感じでタイプが決まるわけですが、
遅くても３であれば問題ないと思いますよ。
遅いの程度によると思いますが、２倍程度なら全然いいのではないでしょうか？
本当にテクニカルなプログラマーは数十倍と変わってきますので。
１の人との差は、素直に認めるべきですが、
２の人との差は気にする必要はありません。
だって「できた！」って言ってるだけでできてないんですもん。
お決まりのことを言ってしまいますが、プログラミングの早さは、
どれだけの種類のコードを読んできたか？
どれだけの種類のコードを書いてきたか？
これにつきます。
種類が重要です。
例えば同じプロジェクトにずーっといれば、誰でもある程度早くなりますが、
プロジェクトが変わった途端に遅くなるのは、身につけている種類が少ないからです。
持ってる種類が多いと、ググってる時間が減るので、当然早くなりますね。
さらにバグった経験や、修正に苦労した経験も多いので、品質もよくなります。
あとはIDEを上手に使えているかなども、けっこうな割合で早さには関わってきますが、
根本的には、やはり持ってる種類の量でしょう。
とは言え、人間はすぐに忘れていきます。これはみんな同じです。
なので、忘れてもいいようにしておくことが重要になります。
一度やったことは自分のナレッジとして、メモを残しておくなりして整理しておくといいです。
前に調べたことを、また調べるってのは時間がもったいないですからね。
日本ではなぜかプログラマーの地位は低いですが、
とても一朝一夕で早くなるものではありません。プログラムは難しいんです。
たくさんググって、理解して、たくさん書いてれば、人並みにはいずれなりますよ。
近道はないです。一緒に頑張りましょう。
投稿2016/03/16 14:12
総合スコア4666
おっしゃる通り、読むにしろ書くにしろ自分はまだ経験が足りてなかったです。最近ちょっと読む量は増えましたが、いざ自分で書こうとすると手が止まってしまうことがありました。
> 持ってる種類の量
これは本当に大事だと思いました。自分のチームのコードだけ読んでいたら他に応用が利かなくなってしまいますし、持ち物の量は多いほどいいですよね。
そういえばメモは残していたんですが、うまく再利用できていないことが非常に多かったです。その辺も少し調べて実践してみます。
ありがとうございます！
0
仕事の遅さの原因を正しく把握することが重要かと。
0. 設計に時間が掛かっている？
0. コーディングに時間が掛かっている？
0. 試験・バグ修正に時間が掛かっている？
設計
全体の仕様を見渡して、機能を分別し、データの流れがシンプルになるように設計する。
サンプルコードを作ってみながら設計する。
また、設計に関してはモアイの法則というのを聞いたことがあります。
- 漏れがないこと
- 曖昧でないこと
- 一意であること
コーディング
似たようなコードはなるべくひとつにまとまるように作る。（ライブラリ化する）
汎用性高く、流用性高く、シンプルであり、完全であることを目指す。
その言語でどのようなことができるかをちゃんと把握する。
忘れていることはすぐに調べる。
正しい調べ方を把握する。（人に聞く、検索する）
試験・バグ修正
試験の仕方をあらかじめ決めておく。
試験ツールを作っておく。
バグがあったら同様のことが過去に無いか調べる。（経験も必要か・・・？）
Unix哲学の一番最初に「Small is beautiful」というのがあります。
小さく、シンプルで、スマートなものを作るといいと思います。
投稿2016/03/16 15:38
総合スコア32
横やり失礼します。
UNIX哲学の最初に'Small is beautiful.'とあるのですね。
UNIX哲学という言葉もその初文も、初めて聞いたので、勉強になります。
ただ、UNIXは開発されたのが1970年頃ということもあり、少ないリソースを有効活用するためにも、小さく作る必要があったのではないでしょうか。
今なら、組み込み系でリソースが限られている等の制約がない場合は、必要以上に小さくしようとしてトリッキーで可読性の低いものを書くより、多少、その言語に慣れていない人でも理解できる、シンプルな書き方をすればよいかと。
最適化は道具であるコンパイラに任せて、それ以外のところに注力すれば、その分、作業速度は稼げますし。
揚げ足を取るようなコメントで申し訳ありません。
> 仕事の遅さの原因を正しく把握することが重要かと。
本当にその通りだと思います。作業中は集中していてどこに時間がかかっていたかなかなか思い出せませんでしたが、挙げていただいた項目はすべてヒットしてました。。
モアイの法則、初めて聞きました。漏れがなく曖昧でなく一意であること・・・自分の場合、性格的に雑でこの辺りについてはよく指摘を受けました。。
> 試験・バグ修正
おそらくテストコードやそのライブラリのことでしょうか。試験の仕方、試験ツール、その単語で調べたことがなかったです。自分では思いつかない単語から良い検索結果にたどり着けるので、正しい調べ方の把握につなげたいと思います！
いろいろ新しいことを知れました！ありがとうございます！
0
こんにちは。
プログラミングの速度は人による差が激しいです。その人が普通の人より２倍速い可能性もあると思います。
しかし、自分の生産性をより高くする努力は可能ですね。熟練することで何事もより高品質なものをより短い期間で作れるようになりますので、基本は地道に慣れることと思います。
その際に、他の人の優れたソースをたくさん読んで、なぜそのような記述をしているのか理解して、様々なテクニックを盗むと速いように思います。
どのソースが良質なのかと言う問題がありますが、言語を指定してここで聞いたら答えてくれる人がきっといると思いますよ。
投稿2016/03/16 13:49
総合スコア23274
なるほど、他人のコードを読む習慣が今までなかったですが、コードを読むのは大事ですよね。自分の中で使えるパターンとかが増えればその分実装も早くなりそうですし。社内のコードは読んでいるんですがGitHubとかで調べるようなことはしていなかったので、スターの多いものなど読んでみようと思います！
言語ごとにいい書き方がありますし、今度は言語を指定して聞いてみます！
> 基本は地道に慣れること
焦って一足飛びにできないか考えていましたが、自分が甘かったです。
ありがとうございます！
0
他の方が言われていないこと、あまり言われないことを、自論も含め挙げてみます。（被っていたらすみません）
- 道具に拘る
マウス、ディスプレイ、キーボードなどのインターフェース類に拘るだけでもスピードは向上します。
せっかくいいモノを買ったのだからという意味で、学習のモチベーションにもなるかもしれません。
- 代表的なアルゴリズムやデータ構造を勉強、あるいは、実装してみる
ロジックやコードの構造を頭の中で組み立てる能力が向上します。とりあえずコードを書きながら考えるのではなく、頭の中、もしくはノート、ホワイトボード上でロジックを組み立てるという習慣をつけることはおすすめです。また、代表的なアルゴリズムを知っていれば、本やネットで検索するときのキーワードにも使えるため、知らないことを調べる能力も向上すると思います。
- 未来視点で、どうしたら楽（ラク）できるかを考える
個人的に１番重要です。その場しのぎの努力を繰り返す人は多いですが、あとから楽をするために、設計をきちんとやりますし、コーディングの前に頭のなかでロジックを組み立てます。
既存のソースコードなどで実装したいことに似たようなコードがあれば、それを流用するのも手です。
しかし、単なるコピペでは、未来で苦労するのは見えてますので、コピペをさらに改良するなり、バグを見つけるつもりでコピーします。
- 読んで理解したソースコードのロジックを人に説明する
人に説明することは重要です。ここで重要なのは一方的に話をするプレゼン形式ではなく、都度相手が質問できる状況で説明することです。説明してみて初めて気づくことも多いです。
- 美しいソースコードを書くことに注力する。
レオナルド・ダ・ヴィンチの言葉で、スティーブ・ジョブズが度々引用していた言葉ですが、「洗練を突き詰めると簡素になる」という言葉があります。
今書いたメソッドは本当にこの名前が適切なのか、この引数はこの型でいいのか、引数名は適切か、戻り値の型は適切か、このクラスで宣言するのが適切なのか、など突き詰めるていくと力がつくと思います。
その過程で、デザインパターンやリファクタリングの必要性やありがたみが分かり、使いこなせるようになっていくのではないでしょうか。
また、必然的に可読性、保守性の高いコードになっていきますので、結局、未来で楽をするという考え方につながってきます。
投稿2016/03/16 17:01
編集2016/03/16 17:02総合スコア907
なるほど、ハードウェア的なこだわりは特に意識してませんでした。
macで開発してるので思考停止して備え付けのキーボードととらっくぱっどを使っていましたが、自分は元々デスクトップを使っていた時間の方が長いので、備え付けのものを使わないほうが早くなるかもしれないです。
実装してみる、というのがすごく大事だと思いました。なんとなく概念は知ってるというのは多いですが、実際に使ってないのでよく分からない、というパターンが僕はすごく多かったので。。
> 未来視点で、どうしたら楽（ラク）できるかを考える
この発想はなかったです。ほとんど開発経験がなかったので、どうしたら将来苦労するか、どうしたら楽になるかという考えがなかったです。僕のチームは設計に関するミーティングがやや多いと思っていたんですが、その辺りを意識しているんだとわかりました。ありがとうございます！
> 読んで理解したソースコードのロジックを人に説明する
これはすごくあります。いざ説明しようとするとうまくできないことが多くて。説明の機会がなかなかないので、まずは実装後に説明するつもりでメモを残すとかをやってみます！
この書き方が適切か、と思うことは多々ありますが、そこからデザインパターンにつなげたことはなかったです。。
すごく参考になりました！ありがとうございます！
0
たぶんその質問をするからには、参考になるもしくはとてもすごい方がいらっしゃるんだと思います。
聞きましょう。 「あなたはなぜ早いのかと」
たぶん人がいい方だと信じたい。 とても楽しそうにきっと答えてくれるはずです。
でありたいと思ったのは僕だけですか？
投稿2016/03/20 11:55
総合スコア446
0
「プログラミングの速度」を人と比べて速くしたい場合に何が速度を遅くしているのかをまず見極める必要があるかと思います。パッと思いつくのは次の2点でしょうか。
0. タイピングが遅い
0. プログラムの流れの構築（アルゴリズムの決定）が遅い
アルゴリズムの決定は速い（または普通）けどタイピングが遅い場合は、タイピングの練習しか無いでしょうね。他の方の回答のように、便利なツールを駆使するのも1つです。
アルゴリズムの構築が遅い場合は、これはプログラミングそのものと言うより、ロジカルに思考することに慣れていないか、思考の速度が遅いということになります。思考の速度を上げるのは、ここのサイトの範疇を超えてる気がしますので、別のサイトやそういう類の書籍などを参照されるのがいいでしょう。
私個人でいうと、プログラムをコードに落とすためには、まずプログラムのイメージが頭のなかに出来上がらないとコーディングはしません（というかできない）。プログラムのイメージというのは、データや処理の流れをイメージとして頭のなかに作っていくのですが（実際に数値を流していったりします）、これは他の方がどのようにしているのか知らないのと、かなり抽象的で自分独自のもので人に教えられるようなものではないのでこれ以上は説明が難しいです。
イメージを作るためには色々と準備します。プログラムの目的や動作など決めていく作業は当然あります。昔はフローチャートなども書いてました。
一足飛びには行きません。まずは基礎から地道に頭（思考）をプログラミングに最適化していくことではないでしょうか。
投稿2016/03/17 09:06
総合スコア3579
問題の箇所は確かに明確にする必要がありますね。
私の場合、２番が特にやばいです。実装の骨組みは作るんですが、動かすことを念頭に置いてしまっていたのでその骨組みがすごく雑なものになっていました。
> 一足飛びには行きません。まずは基礎から地道に頭（思考）をプログラミングに最適化していくことではないでしょうか。
その通りだと思いました。自分は読むのも書くのも経験が不足しているので、まずは自分で何か作りつつ、良いか書き方を他人のコードを見て勉強する。などをやっていきたいと思います。
ありがとうございます！
0
色々付け足したら長くなりました。
以下は私が工夫してプログラミング速度が速くなったと実感した経緯です。
共感出来る箇所、出来ない箇所あるかと思いますが、共感した箇所だけ参考にしてみてください。
- プログラミング力とは使える関数の数
- コーディングスタイルの確立
- 状態変数は持つな
- 命名には徹底的にこだわれ
- でもプロジェクトのコーディング規約が基本的に有線
- カーソルキーは極力減らそう
- その他タイピングの無駄
- 日本語とプログラミング言語の指使いは全く違う
- タイピング速度はこのように活かすのだ
プログラミング力とは使える関数の数
私はJavaScriptとPHPしか使えませんが、
標準関数の覚えている量は戦力の決定的差です。
その他プロジェクトで使ってるライブラリやフレームワークのメソッドも顕著に効果があります。
コーディングスタイルの確立
他の人も上げてますが、プログラミングの速度は読んだ量、書いた量に比例します。
それと同時にプロジェクトや自分のコーディングスタイルを確立しておく事が重要です。
もし読んでなければリーダブルコードを読みましょう。
そして全セクションで納得もしくは「いや、自分は絶対にこう思う。」と確信するまで読破しましょう。
状態変数は持つな
人間の頭の中で同時に記憶出来るモノは7個が限界と言われています。
状態変数の管理は人間様にとって非常に重いコストとしてのしかかってきます。
その結果考慮漏れ、バグにつながります。
しかし、状態変数を無理に削るとプログラムのパフォーマンスが低下する可能性もあります。
何でもかんでも持つな！減らせというわけではありませんが、必要最小限を保つ努力は怠らないようにしましょう。
「ん？この状態変数って必要不可欠だっけ？」と問いかけるだけでもかなり減らせるかと思います。
命名には徹底的にこだわれ
実際に動いてるプログラムの中にtmp,num,str,hoge,fuga,foo,barのような変数があればアウト。
使い捨てる為に名付けたtmpはそのコードを読む度に「えーと、これなんだっけ？」という無駄な時間が発生します。
怠った瞬間考慮漏れ、バグの原因となります。
でもプロジェクトのコーディング規約が基本的に有線
明らかにプロジェクトのコーディング規約がおかしい場合は戦うべきです。
ですが、好み程度の差異なら素直に従った方が良いです。
カッコやカンマの書き方一つでも、統一されてないと追加開発の速度や品質がガタ落ちします。
タイピングの無駄
例えば(j)と入力する時どうしてますか？
まさかShiftキーを押しながら89と入力し、左キーで戻ってからjをタイプ…等とはやってませんよね？
その後の状況もひどくカッコから出る為に右キーを入力する必要がありますので、2回もホームポジションを崩す事になります。
バグを極力減らす事が出来るので、褒められるべき良い癖の一つですが、速度を意識する場合は悪癖ともいえます。
モダンなエディタやIDEは閉じカッコや"忘れはチェックしてくれますのでカッコ忘れたらどうすんだ等と思う必要はありません。
矯正にはTyping.ioをどうぞ。
カーソルキーは極力減らそう
上下左右キーがコーディング時、一番の無駄な作業です。
SublimeやAtom等のモダンなエディタは無駄なカーソルキーを減らすためのショートカットやプラグインの数々が用意されており、高速なプログラミングをサポートしてくれます。
VimやEmacsも高速にプログラミング出来るので、頑張って覚えるのもありでしょう。
大事なのは道具をどう使うかです。
良い手段が思いついたら積極的に使っていきましょう。
日本語とプログラミング言語の指使いは全く違う
プログラマの場合、日本語はローマ字の人が多いと思いますが、
ローマ字入力の場合、左手は大抵ASERに指をセットし、必要に応じてT・G・Bキーに人差し指を伸ばせば殆どのケースをカバー出来てしまいます。
なので意外と左手の指を動かすという習慣が根付いていないので、プログラミングや英語用のタイピング速度を測った時に速くタイプ出来ていないという事は往々にしてあります。
タイピング速度はこうやって活かすのだ
この関数どうやって動かすんだっけ…？
対話シェルを立ち上げてささっと確認出来ます。
LinuxのGUI版にはGuakeという、ホットキーを押すと上からコンソールが生えてくる便利ツールがあります
「Guake Windows」や「Mac Guake」等とググると別のツールですがホットキーでコンソールを呼び出せるツールがあります。
RDBに値を確認しにいく時も極力SQLを打ち込みましょう。
phpMyAdminにアクセスしてマウスをポチポチやって確認するとか最悪です。
例えばMySQLであればmy.cnfを設定しておき、素早く開発環境のDBにアクセス出来る状態にしておきましょう
Bash
1$ mysql dbserver 2> show tables; -- テーブル名を確認 3> show columns from piko; -- 対象のテーブルのカラムを確認 4> select * from piko where xxx = "yyy";
GUI操作をどんなに突き詰めたとしても、4行を打ち込む速度には敵いません。
大量にSQLを発行したり戻る場合は、GUIのSQLクライアントを別途に用意しておくと捗ることもあります。
投稿2016/03/16 23:58
編集2016/03/17 13:50
総合スコア21393
コーディングスタイルの確立については、フォーマッタで整形はしてますが、正直どういうコードが良いのか理解できてなくて自分のスタイルが持ててないです。最近多少読む量が増えてきてるんですが、書く量は非常に少なかったです。僕の経験不足がモロに前面に出てきてる感じですねw
リーダブルコードは一読したんですがもうほとんど覚えてないので再度読みます！
状態変数についてはイミュータブルを意識してるので多分問題ないと思います。
命名・・・ここ完全にサボってました。CommonとかUtilとかすぐつけたくなってしまってます。。リーダブルコード読みます・・・
ツールの使い方は最近ちょっとずつ使うようになりました。Intellijを使ってるんですが、調べてみるとマルチカーソルとか選択範囲拡張とかいろいろできて便利ですよね。カーソルキーはMacだとCtrl + bfnpですが、これがなかなか慣れないですw でもホームポジションから手が離れずに移動できるんで、地道に使って慣れたいです。
タイピングの矯正のサイトなんてあるんですね！挙げていただいたカッコの例は大丈夫だと思いますが、結構カーソルキーに手をやることが多いので、矯正サイト試してみます！
いろいろ教えていただいてありがとうございます！
こんな駄文を読んでくださってありがとうございます。
返事から察するに、私のアドバイスした内容は役に立たない領域に達してるような気もします。
私の場合はTyping.ioをハムスターのように繰り返して速度アップ→CLIやSQL直打ちが楽しくなってきた→CLIツール作ってみよう→楽しい！
…というサイクルで楽しく速度改善ができはじめたと思います。
お互いウィザード目指して頑張りましょう！
0
何が必要か、如何するべきかなどは、既に掲示がありますので、
雑談的に、思いつくままに書くと、
ユーザーも、プログラマーも楽をする為に何をしているか、何をしなければならないか、
ではないでしょうか？
（楽：楽だけでなく、仕上がり、上出来でも）
⇒プログラムって、誰かが楽をしたり、幸せになるための道具ですよね。と思ったり。
稀に、高価で、使う人を不幸せにする物もありますが。
’
職人さん筆頭に、プロの方々は、楽をする為だけは有りませんが、
無駄な動きをしない、良い道具を使う、
上手に気分転換を行う、必ず休憩を取る、
工程、手順が、頭に入っていて、定型部分、非定型部分に分ける事ができる、
すり合わせが上手、打ち合わせが上手、
イレギュラー処理や処置が明確
前工程、後工程、に迷惑をかけない、何より自身に迷惑がかからないようにしている、
失敗が失敗ではない、リカバリが上手い。
暇な時間（待ちになっている時）が有る時に、遊んでいない、
遊んでいるように見えて、道具を作ったり、無意識にできるように、何かしていたり。
プログラマーであれば、通勤途中の物を、頭の中で分解して、
どうやって出来ている？、構成は？、分類は？としたりやら
対象に対するイメージ、処置方法が、早くつかめる方、つかめない方、
視覚化しないとつかめない方など、いろいろですので、
どの分野でも、自分なりの方法（パターン）を見つける事や、
時代に合わなくなったパターンを壊す覚悟が必要だったり。
投稿2016/03/16 23:27
編集2016/03/16 23:30
総合スコア2030
> 無駄な動きをしない、良い道具を使う、
> 上手に気分転換を行う、必ず休憩を取る、
> 工程、手順が、頭に入っていて、定型部分、非定型部分に分ける事ができる、
> すり合わせが上手、打ち合わせが上手
> 暇な時間（待ちになっている時）が有る時に、遊んでいない、
> 遊んでいるように見えて、道具を作ったり、無意識にできるように、何かしていたり。
要領が良い人って確かにこんな感じの動きしますよね。自分は行き当たりばったりでやっているので、この辺を意識できるようになりたいです。
> すり合わせが上手、打ち合わせが上手、
> イレギュラー処理や処置が明確
> 前工程、後工程、に迷惑をかけない、何より自身に迷惑がかからないようにしている、
> 失敗が失敗ではない、リカバリが上手い。
仕事の回し方が上手い人って感じがします。こういう風に立ち回るための考え方、私、気になります！
自分なりの方法というのがすごくしっくりきました。理解の仕方は人それぞれですし、自分に合った方法で理解できればプログラミングの早さにもつながるような気がします。
ありがとうございます！
0
私も、プログラミング早くなりたい。
ですので、私が遅い理由について説明します。
0. デバッグに時間がかかりすぎている
0. その言語での書き方を忘れてる
0. フレームワークについて理解が足りない
0. 睡眠不足で、バグが多い
0. マイクロマネージメントのせいでコンテキストスイッチングが起こっている
0. 仕様の把握が足りない
0. 納期を気にしすぎて行き当たりばったりのコードを書いてる
0. コードを推敲しすぎ
0. 綺麗なコードを読んだことがないので、問題の起こりやすいコードを書く
0. 知能が足りない
タイプしている時間はそんなに多くはないと思います。
私はタイプしていない時間を削ることが大事だと考えています。
それぞれの問題点には多分いくつも解決方法があるので、私もいつも悩みながら試しています。
投稿2016/03/16 14:17
総合スコア2884
> 睡眠不足で、バグが多い
> マイクロマネージメントのせいでコンテキストスイッチングが起こっている
> 納期を気にしすぎて行き当たりばったりのコードを書いてる
なかなか時間的に切迫した環境な感じがしますね。。
> タイプしていない時間を削ることが大事
すごくわかります。おまけに自分は考える時間が長くてなかなか手が動き出さなくて・・・
自分では気づいてなかった共通点がすごくありました。
ボトルネックになってそうな部分から自分も解決策を探してみます！
ありがとうございます！
0
ペア・プログラミングやライブコーディングといった、複数人数で話しながら構築するスタイルを実践してみてはいかがでしょうか。
ペア・プログラミングはレビューをコーディングと同時にすることで凡ミスを圧倒的に減らす目的です。コーディングにバグを埋め込んでから発見までの時間が長くなれば、修正コストと被害のコストが指数関数的に増えるので、凡ミスは発生と同時に防ぎましょう、という話です。（アポロ計画ではロケットが発射してからカンマとピリオドの間違いに気づいたわけです。損害額は・・）
レビュアーは見てるだけですから、作業効率がいい必要もありませんし、コーディングもタイプも遅くて大丈夫です。
上手な人の作業を見てれば、普通に速くなります。細かいショートカットだとか、テンプレートだとか覚えますから・・
実際のところ、エンタープライズのシステム開発では、コーディングそのものの作業時間は開発全体では2割とかなので、それが2倍ぐらいなら遅くても、たいした問題ではないです。
むしろ、それぞれが閉じこもらずに話しながら作れるようにすると、メンバー間でまちまちの作業をしなくなりますし、2倍ぐらいの話でしたら速くすることより、正しいことをすることのほうが大事です。
投稿2016/03/18 00:34
総合スコア234
そういえばこの前ライブコーディングでSwiftライブコーディングとかが話題になってたような。。確かにすごく参考になりそうです！
確かに実装が早くても設計が雑だと結局コードレビューで指摘を受けまくってしまいますし、まずは焦らず確実にですね。
コミュニケーションがしやすいとちょっとした事でも聞きやすくなりますし、仕事の進め方的な部分でミスが減ったり問題解決が早くなりそうですね。
ありがとうございます！
0
RAD(rapid application development)を使えばいいと
思いますが言語を変えるわけにはいかないでしょうね
Framework(ライブラリ等)を使えばいいと思う
ネットに落ちているんじゃないですか？
他人のソースコードをたくさん見た方がいい
うちはRADを使ってるしFrameworkも使う
よく使うルーチンはオブジェクト化してる
プログラムは極力書く量を減らす事を
考えた方が早く書けると私は思っています。
投稿2016/03/17 07:10
総合スコア51
RADというのは初めて知りました！テンプレート生成とかをうまく使えたらコーディング時間の短縮につながりますし、調べてみます！
フレームワークは使ってるんですが、他人のコードをあまり見てこなかったので引き出しが少ないです。GitHubのスターが多いものなどを見てみようと思います！
> プログラムは極力書く量を減らす
この考え方すごく大事だと思いました。動かすことにばかり考えがいってしまうので。。
ありがとうございます！
すみません、コメント投稿したつもりがベストアンサーを押してました。まだコメントへの返事をしていてベストアンサーを選べていないので一旦外させていただきます。
書く量を減らしてシンプルにした方が後のメンテナンスが楽
私のプログラムはかなりコメントが多い
世間ではメンテナンスは30%くらいらしいよ
うちはほとんどないから
プログラムは自分だけがメンテナンスするわけじゃないから
わかりやすくシンプルにしてコメントでわかるようにしておいた方がいい
メンテナンスのために病気でも出てこいと言われたくないから
0
プログラミングを速くする単純な方法。
設計を単純にする。（単純にするのは、高いスキルが必要）
一度作ったプログラムを削除して、もう一度作り直す。（前回２倍、今回は？）
例えば、ヒカルの碁で、すべての打った手順を覚えている才能があります。
プログラマーも、すべてのプログラムの動作を記憶出来ます。
頭の中で、デバッグが動くようになれば、速くなっているでしょう。
出来る人とできない人の差は、１００倍あっても不思議ではありません。
投稿2016/03/16 23:46
退会済みユーザー
総合スコア0
自己補完：
設計を単純にするについて、例えば if 文を使わないまたは、極力減らす
プログラムをする。
デザインパターン等 覚えておく必要があります。
参考サイト（ if 文がないプログラムにする方法 ）
http://www.sage-p.com/ml2/gokui03.htm
言われてみれば、チーム内のコードを見るとif文をあまり見かけない気がします。シンプルさについては他の方もあげてますし、シンプルというのがすごく重要なのかもしれないです。どちらにせよわざわざ複雑なものにする必要はないので、シンプルさを心がけたいです。
> 頭の中で、デバッグが動く
バグの発見の際にプログラムの動作を１からイメージできればすごく役立つ気がしました。本番環境でバグった時とかはなかなかデバッグするのが難しいのでイメージする力は大事ですよね。
ありがとうございます！
あなたの回答
tips
プレビュー
