新人プログラマ応援 - みんなで新人を育てよう！
今、Qiitaでは、「データに関する記事を書こう！」という行事をやっている。
この文章は、テーマ2『データに関する記事を書こう！』参加記事でもあります。
新人の方によく展開している有益な情報
で参照・引用しているURLを一つづつ確認してみよう。
確認する視点は３つ。
-
書いた時点と今とで事情が変わっていないか。
-
書き手と、読み手で見えかたが逆の事象はないか。
-
真偽の論理的な書きぶりの事項は、統計的もしくは確率的に扱った方がよくないか。
まとめは、時と場合と統計に区分する。
書き手と読み手で見えかたの違いは、場合分けをしていればおきないかもしれない。
自分が属している場合と違う場合も書き込めばいいのだから。
コードリーディングについて:「ソースコードを読むための技術」
1. 時間：対象言語・枠組み(frame work)
2002年から2006年の間に加筆している。
初稿がいつかは未確認。
どの言語を対象にした議論か、どういうフレームワークを使うときの議論かは、未確認。
mainという名前が出てきており、C言語系は対象に入っていると予想できる。
2. 立場：
2.1 静的解析・動的解析
基本的に解析は動的解析から始めるのがよい。 静的解析とは、多かれ少なかれ、プログラムの動作を予想することである。 対して動的解析で見るのは事実である。 まず事実を見ておいたほうが方向付けがしやすいし、間違いも減る。 最適化する前にプロファイルを取れ、というのと似ているだろうか。 事件解決はまず現場から、というのでもよい。
事実とは何かという立場の一つを取っている。
別の立場には、ソースコードそのものが事実であるという立場がある。
ソースコードを静的解析することによって、ソースコードそのものの事実を動かす前に変えておくと作業が楽になるという視点がないかもしれない。
ソースコードを動的解析するまでの間に、コンパイルスイッチの選択、リンクまたはロケーションスイッチの選択、ロードスイッチの選択など、さまざまな動的な確認をするための条件の違いがある。これらの条件の違いを検討する前に、静的解析を行うとよいというの別の立場で存在していないだろうか。
コンパイルスイッチも、リンクまたはロケーションスイッチも、ロードスイッチも同一の条件でしか仕事をしない人にとっては、無意味な議論をふっかけられたとしか思わないだろう。
立場が違えば、真逆の方法がよいというのは日常茶飯事だと思っておくといいかも。
2.2 読む順番
まずコードを読む目的を明確に決め、それにだけ 集中するようにする。全てを読まなければいけないときでも、パスを 分けて部分ごとに読む。
まず、どこを読むかを決めるのに、静的解析はとても役立つ。
静的解析の警告の多い箇所もしくは、その静的解析の原因を作っている可能性のある箇所を読み、そこを直すと、いきなり読みやすくなる経験は何度かあった。
CPUに同梱のコンパイラのヘッダファイルが、静的解析をかけずに出荷していた頃のもののままだったりしたときに、よくある事項である。動的解析をする前に、かならず静的解析はかけている。いつも同じCPU、同じコンパイラ、同じリンカ、同じOS、同じローダ、同じスタートアップを使っている人には関係ない話かもしれない。
2.3 状態遷移・時系列図
ソースコードから、状態遷移図か時系列図を生成するツールがあればかけるようにしている。
モデルベース開発に向けた ソースコードからの状態遷移モデル抽出技術
状態遷移表リバースエンジニアリング抽出ツール RExSTM for Cのオープンソース化 山本椋太
あるいは、ソースコードを見ながら、状態遷移図（表）または時系列図を書いて、そこから自動生成してみて、同じ論理になっているか確かめることがあったような気がする。
自動生成の仕組みに、今読んでいるコードを入れるかどうかの判断をするかもしれない。
3. 統計的：
3.1. フローチャート
※ 追記2：『Cプログラミング診断室』でも似たようなコメントを発見した。 以下、同書の p.78 より引用する。 「フローチャートは禁止しましょう。フローチャートは、 制御の流れを「もろ」に書けてしまうのでよくありません。 プログラムは、データを処理するためにあり、データの違いによって 制御の流れが変更されます。あくまでも、データが主体です。 変数、引数などのデータをどう定義するかで、プログラムの組みやすさは 大幅に改良されます。データ構造がどうなっているかの図のほうが、 フローチャートよりはるかに役立ちます。データの意味だけは、 しっかり書きましょう。」
フローチャートは、パンチカードに穴をあけてプログラミングしていた時代の技術です。
1970年代。その頃は、パンチカードの順番を入れ替えることで論理を変更することがありました。どう順番を入れ替えるか、フローチャートを使うと、それ以外の方法より効率的であるという統計データがあったらしいです。
時は流れて、2020年代になっても、1970年代に、「プログラムを書いたら、まずフローチャートを書け。」または「プログラムを書く前に、まずフローチャートを書け」と言っていた人たちがいたらしいです。
1980年代になって、パソコンで入力したプログラムをホストコンピュータに送ってコンパイルするようになると、パソコンでフローチャートを自動生成したり、フローチャート以外の方法で論理的な順番の設計ができるようになりました。プログラミング言語も、構造的な記述ができたり、関数単位で処理をまとめたり。にもかかわらず、全体を設計したり、全体を審査する立場の方々が、フローチャートを書けといいつづけたらしいです。
そういう方々の元で仕事をされた方は、たとえば３０年くらいはフローチャートを書き続けたかもしれません。そして、2000年代にそれらの方々が、全体設計したり、全体を審査する場合に、フローチャートがないとわからないとおっしゃることがありました。
その結果、現在でも、フローチャートを書いている会社はあるらしいし、フローチャートを書いている人はいるらしいです。
大事なのは、全体設計したり、審査する方が、フローチャートを書く時間以上の効果を事業全体にもたらしているかどうかです。ソースコードを何で書くかも似ているかもしれません。全体を設計したり、全体の審査をする人が、どの言語で書いてあるとわかるかで、言語を選択するでしょう。英語とか、日本語とか、C言語とか、Pythonとか。それと同じように、設計、審査する人が、フローチャートをわざわざ書いたことに対して、それを上回る効果を出してくださるのなら、それは無駄ではないかもしれません。
統計を取り、確率計算してどうすればいいかを決めればいいことだとわかるでしょうか。
プログラムは間違えずに入力する時代から、プログラムは間違えて覚える時代にいつ変わったか。フローチャートあるなし。
残念ながら、私はフローチャートを書くのが嫌なので、パソコンのホストコンピュータへの通信エミュレータを自分で移植して、自分の作業はパソコンだけでフローチャートを書かずに済ますようにしていました。
通信エミュレータの移植
フローチャートを書いたり、読んだりする人の気持ちが全くわかっていません。
外している可能性があると思います。
3.2 コールグラフ
ところで、この文書の以前の版ではコールグラフ視覚化の トピックにこだわりすぎていたように思う。 確かに、コールグラフを視覚化すると時によっては それ一発で動作が理解できるようなこともあるのだが、 必ずしも役立つとは限らない。 コールグラフが効果を発揮するのは、関数の数がそれなりにあり、 しかも関数呼び出しが深いときだ。逆に言うと、そういうときでないと役立たない。
どんな道具でもいつも役立つとは限らない。
どういう場合に、どれくらいの割合で役立ちそうか、目安を述べるといいかもしれない。
個人的な経験では、ある事業に１度はcall graphを書くことは意味がある。
どれくらいの複雑さになっているか、どのあたりがややこしくなっているかを調べた方がいいかどうか、ざっと眺められるかどうか。
C言語で言えば、includeの関係が、複雑になっていて、もっと簡単にして、ファイル数を減らすといいかなって思うことがある。あるいは、ファイルが大きくなりすぎていて、ちょっと分割した方がいいかなって、分割する前の後で、call graphを比較してみるとか。
道具は、その時点の問題を解決するための効率的な方法に役立てればよく、道具を使うことが目的ではないことがわかっていればいい。各種の図でも同じかも。
なんのために書いた状態遷移図か意味わかんないものを見かけたことがあるような気がするとか、しないとか。
3.3 社会調査(field work)
社会的な事象では、統計による検証はできないと仮定して考えるとよい。
統計は嘘をつくための道具かもしれないと。
逆も真：社会人が最初に確かめるとよいこと。
統計の嘘。仮説（127）
社会事象は検証できないかも。仮説（204）
4 まとめに代えて(Instead of summarizing)
新人プログラマ応援 - みんなで新人を育てよう！
今、Qiitaでは、「データに関する記事を書こう！」という行事をやっている。
この文章は、テーマ2『データに関する記事を書こう！』参加記事でもあります。
いくつかの事項は、データを取ってから追記できればいいかもしれない。
あるいは、お手持ちのデータがありましたらコメントいただけると幸いです。
自分の頭で考えることが大事なのではない。
何か行動すれば、必然的に、自分の頭で考えなくてはならないところに追い込まれる。
自分の頭で考えるようになるには
「自分の頭で考える」ということ。
行動して、測定すればいい。
ぼくの先生「人がやらないことをやれ」プログラマになるまで。仮説（37）
小学校の絵の先生には、色を置いてみるという試行錯誤を教わった。
中学校の技術の先生には、人がやらないことをやれと教わった。
考え方など教わらなくてもいいのだ。
行動すれば、その責任は自分で考えて、よりよくするのが試行錯誤で、人がやらないことをやった人が考えることかも。
DoCAP(Check Action Plan) 芸術でも技術でも運動でも
4.1 参考文献(reference)
@kojimadev 1年以上かけて生産性倍増＋成長し続けるチームになった施策を全部公開
@torifukukaiou【毎日自動更新】新人プログラマ応援 - みんなで新人を育てよう！（2022年04月） LGTMランキング！
@torifukukaiou 【毎日自動更新】データに関する記事を書こう！ LGTMランキング！
@kazuo_reve 「新人の方によく展開している有益な情報」の中で大学時代に得ておけばよかった情報
@kazuo_reve 私が集めた有益な情報・知識のまとめ
@kazuo_reve 私にとって有効だった学び方5選
@kazuo_reve 自分のQiitaの記事を分析してみた
@kazuo_reve 私が効果を確認した「小川メソッド」
@e99h2121 育児していたからこそエンジニアのお仕事に役立ったこと10選
@e99h2121「女性こそエンジニアになるべきだ？」デブサミウーマン登壇記録
@e99h2121 新人さんにすすめる有益なツール達 2022春
@e99h2121 新人さんにすすめる有益な技術書達 2022春
@ohakutsu 新卒1年目のエンジニアがQiitaの速度改善をした話
@ohakutsu 新卒2年目から見た達人プログラマーの振る舞い
4.2 自己参照(self reference)
ソースコードを読むための技術: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１）
スペックアウト手法: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（２）
変更の影響範囲を特定: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（３）
質問は恥ではないし役に立つ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（4）
質問するときのパターン・ランゲージ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（5）
「できない人」ほど、人に聞けない: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（６）
分からないをすぐ伝える: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（７）
15分ルール: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（８）
検索の仕方: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（９）
エラーメッセージの読み方と対処: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（10）
Google検索のコツ: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１1）
新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（12）
日報、週報、月報、年報: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１3）
新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（１4）
分報（分単位報告）: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（15）
分かる: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（16）
わかったつもり: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（17）
開米瑞浩 図解: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（18）
要求仕様: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（19）
SE用語: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（20）
文章の推敲: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（21）
結城浩 数学文章: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（22）
結城浩 推敲: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（23）
あいまい表現: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（24）
やまとことば: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（25）
鍵語による見直し: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（26）
開米瑞浩 MECEとロジックツリー: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（27）
芝本秀徳 考える: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（28)
佐藤航陽 論理: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（29)
清水吉男 設計: 新人プログラマ応援 @kazuo_reve 新人の方によく展開している有益な情報（30)
「@kazuo_reve 新人の方によく展開している有益な情報」はじめ記事を参照して頂いた時にしていること。
@kazuo_reve「「新人の方によく展開している有益な情報」の中で大学時代に得ておけばよかった情報」に付け加える3つのこと。
プログラマにも読んでほしい「QC検定にも役立つ！QCべからず集」
図を使って分析すればこんなに簡単。安全（１１）
５月病にならないで
文書履歴
ver. 0.01 初稿
ver. 0.02 表題変更 主題を前に
ver. 0.03 表題変更 短く 20220410
ver. 0.04 ありがとう追記 20230531
最後までおよみいただきありがとうございました。
いいね 💚、フォローをお願いします。
Thank you very much for reading to the last sentence.
Please press the like icon 💚 and follow me for your happy life.