もっと開発スピードをあげるために
昨日に引き続き仕組みについてアレコレと(*´∀`)ﾉ
こんばんは。
キテレツです。
昨日に引き続き、自分の行動のシクミについて考えてみました。
今日はプログラム開発の手順と解析の手順について。
考える時間をa長く取るわけにはいかないので、出来るだけ多くの結論を出して試してみます。
他人のプログラムの解析には・・・やはりGrepか
となりますよね。
優れたGrepはなによりの解析ツールです。
優れたGrep・・・いや、優れたGrepの使い方でしょうか。
正規表現をすぐに忘れてしまうキテレツには少々ハードルが高いですが、ファイルをまたがったGrep機能は必須ですね。
今日のところの結論
結局月次に落ち着いたかもですが
- Mainとなる処理を見つける
- 機能を洗い出す
- 関数の中まで見ないで読み流す
- 全体のフローをイメージする
大枠的にはこんなありきたりな結論に至りました。
今までも同じような考え方でやってきたはずなので、やり方を変えてみます。
Grepする数を少なくしたり、可能な限り深く掘り下げずに機能を予想してみたり。
ついつい目的を見失いそうになってしまうのですが、あくまでも目的は全体を把握して理解することというのを忘れてはなりません。
何やっているのかだけわかれば、同じ機能を別の方法で実装したっていいわけですから。
明日は今日よりももっと早くソースを読んで書けるようになろう。
さらにもうひとつ！
仕組みとして感がなければならないのは、仕事の進め方です。
こ〜してあ〜して・・・・こんな動きにしてください！！(*´∀`)ﾉ
って言われた時に、すぐに問題点を指摘したかったり、面倒なことを請け負いたくないからできるだけ勉強してから打ち合わせに望みたいがそうも行かないことって多々あります。
そんな都合の良い案件ばかりではないです。
これについても、昨日までの自分と違うことを試してみます。
- シンプルに考える。複合的に考えない
- 一部だけとか部分的に開発できるのかどうかを判断する
- 相手から「この機能だけは盛り込んで」って言われるものを全て洗い出す
- ここまででどうでしょう？ってラインをはっきりさせる。
とにかく、
作るものが明確になって、実現方法まで確立するまでモノ作りを始めない
ってスタンスに出来るだけ近づける。
知らないことにチャレンジする場合は、試しながらの開発になるのは仕方がないと思いつつ、試していると結局モノが出来上がってしまうことも考えられる。
ので、やりたいことを明確にして、やりたいことのポイントを絞り込み、技術的に問題が解決できるかどうか。
本当にそれでいいかどうかを確認取りながら進めてみようかと。
よくわかんないから任せます！(*´∀`)ﾉ
って言われるのはつらいので・・・・それは避けたいなぁ。
好きにしてって言われたら、まぁ、好きにするか。
どちらにせよ、
制作物についての責任は製作者にある
わけですから。
