駆け出しプログラマーが不明点にぶち当たった時に意識してること

駆け出しプログラマーは分からない事だらけ

駆け出しのプログラマーは、コードを書くにしても何をするにしても、わからないことがたくさんあるんです。僕の先輩も

『え、そこで躓く！？』

みたいに思われたこともあるかもしれません。

そんな僕が、わからないことがあった時に意識していたことを『具体と抽象』という言葉を使ってまとめてみます。

抽象的質問で理解してもらえない

『もうすこし具体的に教えて』

こんなことを言われたことはないですか？

僕もしょっちゅう言われます…

色々なところでよく聞く『具体と抽象』ですが、駆け出しプログラマーにとって、具体と抽象ってどのようなものなんでしょうか？

本記事はこの問いに対する個人的見解をまとめてみました。

ついでに、dZERO社出版されている『具体と抽象、世界が変わって見える知性のしくみ』のレビューも兼ねて、記事を書いています。

駆け出しの身分で恐縮ですが、本記事を執筆させていただきます。

なお、本記事に対する意見や間違い等がありましたら、コメントより優しく教えていただければ幸いです。

またdZERO社様から出版されてます、『具体と抽象、世界が変わって見える知性のしくみ』は、仕事やプライベート、さまざまな点で活かせる内容になっています(案件等ではありません)。ぜひ、お手に取ってみて欲しいと思っています。

当記事を読むにつれてあらかじめ理解していただきたいこと

本記事では、駆け出しのプログラマーがわからないことにぶち当たった際に、意識していることを言語がするのが主な目的です。

書籍『具体と抽象』を読んだ際に、色々とわからないことがあった時の対応などを思いついたため、それをまとめるのも目的であります。

本記事の結論

わからないこと、躓いた際には一旦抽象的レベルで物事を整理してみよう。

その後、具体レベルのものを出していって、

• わかるところ
• わからないところ
• わからないことに対して試してみたこと
• 結果

の整理をしよう。ってことを僕は意識しています。

そもそも具体と抽象とは

色々と考察する前に、まずは言葉の定義からできればと思います。

具体と抽象とは、表裏一体の関係であり、切っても切れない関係性のある言葉だと思います

• 具体→はっきりと何かしらの形になってるもの
• 抽象→形になってるものをまとめた概念

と僕は認識しています。抽象概念Aというグループの中に具体概念A-1 , A-2というふうに、階層構造をなしています。

例えば、上記例の『抽象概念A』を、ここでは『魚』に置き換えて考えてみます。

ここからは、皆さんも考えながら、記事をご覧いただけたらと思います。

皆さんは何をイメージしますか？

• マグロ
• タイ
• イルカ

など、人それぞれさまざまなものが思い浮かんだのではないでしょうか？

ここでいう

• マグロ
• タイ
• イルカ

を具体と言います。

すなわち抽象というのは、具体的概念の共通する点をまとめて、命名したものとなります。

具体はその抽象的なものを人間が認識できる形として存在しているものと言えます。

このように、具体と抽象は階層構造をとっており、どの階層にあるかによって、具体と抽象は変わってくるものです。

プログラマーにとっての具体と抽象って何？

ここからが、この記事の本題です。あくまで僕の今ある世界における抽象の話をします。

読者の皆様にとっての抽象もおしえて頂けますと幸いです。

プログラマーの方々は抽象と聞くと何をイメージしますか？

インターフェースとかですか？多分これも抽象ですよね。

色々とありますが、今回は書籍『具体と抽象』を拝読させていただいた上で、

**『わからない場合の具体と抽象』**に焦点を絞って考えてみようと思います。

わからないことができた場合、具体と抽象が鍵になる

具体と抽象で言うとコードというのはソフトウェアを動かすための具体的概念である思います。

そんな具体的であるコードを書いている時、ふと『ここわかんねえ』ってなることがあるとします。

そうなった時、自分はいつも、わからないことの具体と抽象を考えてみます。

今回の例題

例えば、実際に現場にて

『Aという機能を追加してほしい』

と言われたとします。

Aという機能を追加するには、

1. Bという処理
2. Cという処理
3. Dという処理

を踏まないといけないとします。

ここで、Cという処理に詰まっているとしましょう。

『わからない』を具体と抽象に分ける

わからない！ってなったときにすぐに

『わかりませ～ん』って聞くのではなく、ここで一旦考えるフェーズに入ります。

大体15分くらい調べたり考えたりします。

まずは、やりたいことを考える

今回の場合、Cという処理は、Aという機能を実装するために必要なパーツであると言えます。

じゃあそのCという処理は何をしたいのかを考えます。

Cという処理を達成するために必要な具体的概念を考える

次に、Cという処理を達成するために何が必要かを考えます。

仮にCという処理を達成するために

1. Eというコード
2. Fというコード
3. Gというコード

を書く必要があるとします。

具体的概念に『できる・できない』をつける

ここまでくればほぼ個人的にはゴールだと思っていて、

どこはできるけどどこができないかを考えます。

これで、最初の『わからない』に比べてだいぶ具体的になったのではないかと思います。

そうすると、先輩とかに聞くときも

先輩、今この開発でこの部分ができないです。
概要としては、Aっていう機能を実装するには、B→C→Dって手順を踏んでいけばいいと思っています。BとDはわかったのですが、その中でCだけわからないです。
Cってところでは〇〇をしたいので、E、F、Gそれぞれコードを書いたんですけど、このFの部分がわからないです。

みたいになるのかなと思います（結論ファーストではないのは許してください）。

参考文献