Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
Help us understand the problem. What is going on with this article?

ソースコードから思想を読み取るべきか?

結果として

あくまで個人の見解になりますが
先に結果を言いますと「否」になります。

何回も失敗しているから

実装方法や方針の資料が無い場合で、
他の実装を参考にする…という手順になるのですが、
かなりの確率で間違えてます。

特に変更するソースファイルが増えるほど後の巻き戻しが多いです。

余裕でスケジュール吹っ飛ばします。

問題点

①過去実装からまとめた実装方法を有識者に見てもらう
 →これは繰り返すスパンが短ければ短いほど良いと思います。
 PDCAを高速で回して実装方法を確立するべきです。

②ソースからしか読み取るものが無い
 →レビューの回数を増やすべきだと思います。
  兎に角自己判断で決めつけないことが大事。
  fixしてコミットするまでは「実装中」。

③他社との兼ね合いで思想が分からない、または、変更点が被りそう
 →立場によって変わりますが、なるべく影響のない実装方法を模索すること。
  共通テーブルとか使ってたら、最新版で既存から一部削除されて別途追加されてるなんて事がありかねない。
  というか実際にあった。

④共通化や使用方法が簡略化されるはず
 →確証の無い思い込みが1番危険
  実際に、「一部の変更より簡単にする方向性・そういう思想となるんだろう。」と思って進めたところ、ドツボにハマった。
約1ヶ月3、4回目のリファクタリングが発生した
  他者巻き込む程のリソースとメリットがあれば別ですが、自分の思想と仕事は切り分けることが最短かもしれない

⑤理解度不足
 →検証が大雑把の場合、PDCAのPlanが深く掘り下げられて無いことになる。
  後々になって判明することでリファクタリングが発生

対策は?

いくつか述べてますが、
 ・有識者に見てもらう
 ・精度が大雑把なときから何回もレビューしてもらう
 ・実装の思い込みがないか立ち止まる(独自理論で都合の良い解釈をしないこと)
 ・疑問点はこまめに質問する
 ・コードの制御は1行ずつ追ってよく理解すること

以上。
多分基本的な事だと思います。
個人的な見解になりますが、5年目でも未だに出来てなかったポンコツなので記載する。

※再投稿記事(前のは最初の記事に上書きしたため)

uesh
主にスマホからの投稿なので 引用多めでコード少なめになるのはすみません。 言い回しとかもなるべく見直し修正を繰り返さない方針で、躓いたりトラブルしたとこをジャンル関係なく投稿していきます。 なんか作った→説明するよ!ってのもいつかしたいなぁ。。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away