書く時間と考える時間
o 仕事を早く終わりにして帰りたい
o スキルアップのためにプログラミングたくさんやりたい
o オープンソース活動のための時間を確保したい
こういう感じの様々な悩みがあるかと思いますが、
ズバリ！
書く時間と考える時間を分離する
をオススメします。
これができれば、通勤の電車でも、
用事があって歩いているときでも、
ご飯を食べているときでも、
お風呂を入っているときでも、
横になって休憩しているときでも、
ストレッチしているときでも、
ショー待ちしているときでも、
プログラミングができて捗ります。
書いて考えて書いての繰り返し
月並みですが、プログラミングは、ただひたすら書くだけの作業ではありません。
今の時代のプログラミングであればなおさら、プログラミング言語やフレームワークの進化により、書く量に対して考える量が増えていると思います。
もちろん、書きながらじゃないと考えられないこともあるので、それが100%分離できるかというとそうでもありませんが、中にはある程度分けられることもあるはずです。
どんなことを考えるのでしょうか？
どれが分離できそうでしょうか。
思考1: クラス構造や名前などのデザイン
いまのプログラミングは、ただ動くものを作るだけでは足りません。
o 全体を把握しやすいプログラム
o バグが見つけやすいプログラム
o 積み上げ実装がしやすいプログラム
o 若い人たちの手本になるプログラム
実現するのに選択肢がいくらでもあり、上記の要件を満たすプログラムをデザインすることが求められます。
// プログラマーに求められるデザイン脳 | jfluteの日記
http://d.hatena.ne.jp/jflute/20170623/desigraming
1. 命名デザイン
2. 構造デザイン
3. コメントデザイン
4. DBデザイン
5. アーキテクチャデザイン
わかりやすく分離しやすい思考ですね。
リファクタリングもここに含まれるかもですね。
ただ、それなりに難度は高いので後でコツを示します。
思考2: 難解なロジックの仮説検証
「これ実現するにはどうすればいいんだ!?」
とうなるようなパズル問題。
複雑なプログラミングをしてて、ふと止まってしまうことはありませんか？腰据えて考えないとわからないなぁ、というようなロジックの実装。
であれば、本当に腰を据えましょう。
カフェでハーブティーでも一杯しながら...
「あっ、こうやればいいのか！」
って思いつくのはパソコンの前である必要はありません。そして、パソコン開いた時に(というか、開きたくてしょうがなくなる)、一気にそのアイディアを実現。で、うまくいかなかったら、また別の用事をしながら思考。うまく仮説検証サイクルにフィットさせていきます。
思考3: 資料を見ながらステップ実装
ERDやテーブル定義などを見ながらクエリーを書いたり、要件を見ながら一つ一つの実装をしたり...
これはさすがに分離できそうにありませんね。ドキュメントを見ながらじゃないと書けないでしょうか。
いや...ある程度把握して頭の中で全体像を展開できれば、漠然とした実装であれば頭のなかで導き出せます。100%思考できなくてもいいわけで。
コツ1: キャッシュする
「いやいや、そんなうまくいかないでしょ？」
って思われるかもしれないので、幾つかのコツをまとめてみました。
まずは、思考に必要なインプット情報を、頭のなかにキャッシュすることです。キャッシュだから恒久的な記憶じゃなくていいです。わりと一瞬でいいです。
帰る直前、移動する直前、ランチに行く直前、お風呂に入る直前などなど...
パソコンをパタンと閉める前に30秒だけ...
思考に必要な...
o 書いてる途中の自分のプログラム
o ポイントになるその周辺のプログラム
o 関係のあるドキュメント
o などなど
を頭に焼き付けます。
「焼き付ける」という感覚が重要です。覚えようとするのではありません。すると、パソコンがなくても、それらが残像のように頭に広がります。
パソコンの前でやっていた思考ワールドを、いかに頭の中だけで再現するかがキーポイントです。コードが頭の中をあちこち飛び交うようにしましょう。
コツ2: スパイラル思考
頭の中で思考をして、パソコンの前で作業して...で、おしまいではなく、
頭の中で思考をして、パソコンの前で作業して、また頭の中で思考をして、またパソコンの前で作業して...の繰り返し。
一回で終わりにする必要性はまったくないというか、隙間時間を活用するために作業が細切れできる方が良いです。
頭の中でこれ以上考えるの無理！と思ったら、遠慮なく別のトピックの思考をすれば良いです。なので、複数の課題を同時に持っていたほうが良いですね。
パソコンの前にずっといても、「書いて考えて」を繰り返しますから、そのリズムと、「パソコンの前にいる、パソコンの前にいない」のリズムを合わせられたら良いのかなと。
コツ3: 暗闇とお友達
わからないことがあっても先に進む力。昔々、数学の授業でこういうのありませんでした？
(2 + x) * y = z + 5
x と y がわからないので、z もわかるわけないから、もう考えようがないように見えますが、でも、わかることもすごくたくさんあります。
o 2 と x は足す
o それに y をかける
o 一方で z に 5 を足す
o それらが同じ
別に頭の中だけで答えを全部導きたいわけじゃないですから、これだけわかれば思考できることはたくさんあります。
やってはいけないことは、一段ずつ思考してわからないところで止まってしまうこと。「"x" が出てきた瞬間にもうわかんないからおしまい」にならないように。
パソコンないので確認ができないものがどうしてもあります。わからないならわからないで、それは x なり y なり変数にして、論理を積み上げていけばいいだけです。すると多少分岐が増えるので、頭のキャパシティが心配ですが、x や y に対して仮説を立ててアプローチすると良いでしょう。間違ってても無駄ではありません。それだけ分析が進んでることになるので、パソコンの前でもスピーディにやっていけるはずです。
やりたいのは、全体作業の完遂ではなく、思考作業の塗りつぶしなので、暗い部分は暗くて別に驚かなくていいのです。
ちなみに、パソコンを持っているときは、ちょこっとだけ開いて一瞬だけ見て閉じるとか。立ち状態で、ずっとはパソコン開いてられないけど、一瞬見るだけならできるって場面もあるでしょうし。
コツ4: CPUパワーの配分
何かをやっていたとしても、頭のCPUパワー100%使ってないこともあります。
24時間CPUパワー100%は人間耐えられませんが、ある程度は残ってるパワーがもったいないって思えます。
両方パソコンの前でのたとえですが...メールの返事を書くのに100%使うかというと、そうでもありません。少しパワーが余っています。なので、メールを書きながら、プログラミングのロジックのことをぼんやり考えます。すると「あっ！！！こうすればいいのかも」って、唐突にひらめいて、いったんメール止めてEclipseへ。
そして、プログラムを書いて...プログラムを書くときもCPU100%とは限りません。わりとわかりきったことを書くときは少し余裕があります。なので、その残ったパワーを使って、メールの返事の内容の方向性とかをぼんやり考えます。プログラムでまた少し悩むようなことが来たら書くのを止めて、メールの方に移って考えた内容を書き込む。すでに方向性とかも少し考えてあるので、100%使わずにメールを書き進められるので、プログラムのことを考えながらメールを書き書き...繰り返し。
ちなみに jflute は、その行き来が一瞬でできるようにと、MacOSXに付いてる (MissionControl (昔はSpaces (昔の方が良かったなぁ...))) をすごく重宝しています。8,9年前にMacに移行したときに一番のポイントはそこでしたね。
日常生活でも、これができる場面がたくさんはずです。ただ、メインのものが疎かになっちゃうと良くありません。だから、配分コントロールが大事です。10%,20%だけ使うというようなバランス感覚。これも慣れですね。
注意: 車の運転してるときとか、恋人と話をしているときは100%集中しましょう。
このブログも分離して書いた
プログラミングだけじゃないですね。このブログ記事も、休日の午前中起きてスムージーを飲んだ後、すっかり一週間の疲れが溜まっていたので、布団に潜りながら考えていました。
休んでいるわけなので、100%のCPUを使うと疲れてしまって本末転倒なので、もやもやっと思考するくらい40%くらいですかね。
記事の全体の流れ、途中のサブタイトル、ところどころ具体的な語り、思考とコツに分けようとか、「思考1,2」と「コツ1,3,4」は、布団の中で思いついて、大体の内容を考えました。
で、休んで元気ばっちりなので、一気に書き出しました。書くことでまた「ひとりフィードバック」が生まれます。「コツ2,3,4」とかは、コツ1を書いたことで、わりと流れに影響しない独立セクションだなと思ったので、そこは飛ばして全体の流れの骨組みを確立する方を優先。
後半もざっくりだけ書いて途中で中断、もう支度して出なきゃいけないからー。でも随分と見通しが立つところまで一気に書けましたよ。
残りはまたシャワーでも浴びながらとか、ストレッチをしながら頭の中で書こうと。
普段のブログも、電車の中や舞浜でショー待ちしてるときに、ストレッチしてるときなどに考えたりしてます。
四六時中プログラミング
jfluteは、こういったプログラミングスタイルを「四六時中プログラミング」と名付けて、意識してやっています。(加えて、四六時中オープンソース活動 or 四六時中マネジメント整理整頓 or 四六時中講演のイメージトレーニング)
自分は何かと移動することが多いので、移動直前は狙ってキャッシュします。10秒から30秒、怖いくらいにパソコンを睨みます。目的地に付いた頃には悩んでたロジックが解決されてて、「うおー」と書き出して実現、また悩んでパタン。移動して目的地に付いて「うおー」で完了みたいな。
レアケース対応の抜け発見やバグ発見なども、お風呂の中での脳内レビュー中に思いつくこともしばしば。
複雑な実装の解決アイディア出しや、新機能の実装デザインポリシーの構築などは、恐らく半分くらいはパソコンの前じゃないですね。
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
(早速お風呂の中で脳内レビュー中に思いついた話)
ただ、そのためには、「頭に焼き付けやすいコードを書く」ということが大前提ですね。そこはわりとこだわっています。
なので他人のコードはキャッシュがしづらいものですが、でも自分が書いても結局とっ散らかっていれば同じです。jfluteが徹底してクラスのコードスタイルにこだわるのは、そこが大きいかもしれません。みんなもっと、パソコンに縛られずに、プログラミングできるようにしようよ！って。
_/_/_/_/_/_/_/_/_/_/
というか、こんなブログも書いてましたね。
// 四六時中プログラミング | jfluteの日記
http://d.hatena.ne.jp/jflute/20121209/shirokupg
このスキルを狙って鍛える
でも、最初はあまりうまくできなかったかと思います。人間、頭の中の思考って意外にコントロールできないもので。ぐるんぐるんしちゃいがちです。整理整頓できないとアウトプットにならないですから。
だから jflute は、よく狙って鍛えていました。急ぎじゃない機能の実装とかのときに、「これは徹底して頭の中だけで考えてみよう！」とか縛りを付けて、書きたくても書かない、ひたすら考える。うーんうーんとうなって最後に書いてフィードバック生まれて、思考のどこが精度悪かったのか？とか振り返って、また繰り返し。想像のトレーニング。
特にオープンソース活動は、時間の確保が命、これがDBFluteの生命線だとも思って。
でも、これはスポーツと一緒で、しばらくやらないと徐々に衰えていくんですね。
なので時々...
「ああ、なんか最近パソコンの前にばかりにいるなぁ」
とか思ったら、また狙って鍛えます。
パソコンの前にばかりいるということは、他の生活的な用事がこなせてないということですから、サスティナブルじゃなくなっちゃうので、これが人生の生命線だとも思って笑。
...
「色々と考えないといけないややこしいロジックだなぁ」
って壁に当たったら...
「いいや、その件はスパでお湯につかりながら考えよう」
ってなればもっと楽しくプログラミングできるかも!?(^^
