読者です 読者をやめる 読者になる 読者になる

うろ覚えの雑感

何でも適当に書いていくブログ

自分にイライラしてしまう時

単純ミスってあるじゃないですか。単純ミス。

やらかすと切ないような恥ずかしいような気持ちになるあれ

プログラムを書いていると特にスペルミスとか結構やるんだけど、それが積み重なって自分に対してのダメ出しの許容量を超えてしまって、かなりイライラしてしまったんです。

仕事に対して、完全に勉強してレベル上げるフェーズなので、それ自体はもう頑張って追いつこうみたいな気持ちでやってはいるんですが、こう単純ミスを防ぐのって自分なんですよ。完全に自分。

まだまだ色々足りてないのは自覚している。レビューで指摘貰ってもまだ納得感がある。(時々、え、このチケットでやらなくてよくね?とは思うけど雑食よろしく、たくさんの経験を積み上げるためにもやってみてる・・・)

それでもさ、単純ミス・スペルミスとかそういうのをやってしまうとさコストがかさむのよ。2倍に。

見てもらう前に、5分・・いや3分でいいから見るだけで防げるのが見なかったがゆえに10分とか15分消費する。これの積み重ねがもったいない。

と頭でわかっているのにミスるわけです。

何度か1日でやらかすと本当に自分にイライラする。

ああすればよかったこうすればよかったがすぐ頭を持ち上げて、思考の邪魔をする。

過去に戻れないのに過去に引っ張られるとその分前に進めなくて結局もったいないのにね。

そういう時に思いっきり

あーーーーーーーーーーーーー

って叫びだしたく成る。

ふがいない自分に

できているようで出来ていない自分に

話を聞くのは難しいよねって話

www.midoriyakuhin.com

今回も記事から。

喋ることは簡単だけど難しい

聞くことも簡単だけど難しい

自分はそう思っている。

喋ることは、好きなことを好きなだけ喋ってる分にはいいかもしれない。

でも何かを伝える為に喋るのは案外難しい

理路整然と話しているつもりでも脇道にそれることがよくある。好きなものを話すときって案外そんなものなのかもしれないけれど、深く入ろうとすればするほど相手も同じレベルの知識や深さが求められていく。

中々そこまで至らないから難しい。

あと、初めて会う人や久しぶりでも話したことが少ない人に対してもどのような話題を振ればいいのかいつも悩む。

悩んでいるうちに機会損失してしまうわけだけど、これは自分だけではないと思っている。

話して見たことが相手の琴線に触れたりした時に無用な衝突をしてしまわないかを心配してしまう。

大抵の場合取り越し苦労なのだけれども(苦笑)

さて、本題の聞く方。

何でもそうなのだけど、「聞く」という行為だけであれば簡単だ。街中に出てみればいい。そこは雑音も含めて話は聞こえてくるだろう。

今回の記事では傾聴というキーワードだ。

主に1:1やカウンセリング的な話に近いとは思うのだけれど、話を聞いて欲しいだけの場合、語りたい場合でやはり違うのだと思う。

相槌は必要だと思うし、話に対して的確な質問や展望で返せば盛り上がるだろう。

技術もそうなんだけど、やはり生きてきた足跡も大事なんだろうなぁと思う。

とりとめのない文章をざーっと書くのが最近楽でしょうがないから、散文で失礼。

共感して傾けて、そこに集中して聞いてみるのは大事だ。やってみよう。

ストレスと上手く泣けないことについて

www.midoriyakuhin.com

を読んだ雑感と自分のこと。

自分はどのタイプなのか

照らし合わせるまでもなく

②落ち込みやすく劣等感の高い、自己否定タイプ

だな、と。

何に対しても自信がないから去勢を張ってしまうし、気がつくとネガティブな方向へ思考が飛んで行く事がよくある。

前にもこんな感じの記事を読んだ時に、自己否定をしないところから始めるべきだと思い続けてきた。

この記事中の

このタイプはまず自己否定をなくす事が先決です。それには小さな事でも自分を褒めるようにしてください。そのためには、些細な事でも「良くできた」とこころの中でつぶやくようにしてみてください。自分を褒める事はけっして悪い事ではないことをまず受け入れてみてください。

それでも自己否定を止められない方には、「”止まれ”サインテクニック」をお勧めします。これは自己否定を始めた瞬間に、道路標識の赤い止まれサインを思い浮かべ、その時点で「~するべきだった」などの自己否定的な考えをやめてしまうテクニックです。癖になった否定の考えは何回も浮かんでくるのでその都度止めてください。自己否定からは一切良い結果は生まれてきません。

前者はともかく後者のテクニックは初めて見た。結構使えるのでこれはぜひ試してみて欲しい。

ストレスが溜まると涙する

これはよく言われるのだが、自分にはあんまり当てはまっていない。

というよりも、うまく泣けない人間なのだ。

人は幼少期~思春期に至る部分で大半の人格形成が成されるというのはよく聞くがそこで泣くことに対して相当ネガティブになっている。

例えばアニメ「フランダースの犬」などを子供の頃に見た時のこと。

ラストのシーンでネロとフランダースが寄り添い天使に天国へ案内されるシーン。あれを見た時幼い自分は大変泣いたのだが、それを家族には笑われた経験がある。

その後フォローがあればいいんだが、大変まずいことに「馬鹿にしたような笑い」やら言葉を掛けられている

そういうことが何度もあり、泣くことに対してネガティブになっている。

最近、そのあたりの呪縛を感じることが多くてもがくんだけど、中々過去には勝てなくて苦労する。

うまく泣くために、好きなものをどんどんやっていくのが近道かなぁと思う。

本当に乱雑な文章になってしまったw

リーダブルコード 第三部、第四部

書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。

第三部 コードの再構成

10章 無関係の下位問題を抽出する

  1. 関数やコードブロックを見て「このコードの高レベルの目標は何か?」と自問する
  2. コードの各行に対して「高レベルの目標に直接的に効果があるのか? あるいは、無関係の下位問題を解決しているか?」と自問する
  3. 無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする。

10章のキモは - プロジェクト固有のコードから汎用コードを分離するということ

11章 一度に1つのことを

  • コードは1つずつタスクを行うようにしなければいけない。

本書の手順

  1. コードが行っている「タスク」をすべて列挙する。この「タスク」という言葉はユルく使っている。「オブジェクトが妥当かどうかを確認する」のように小さなこともあれば「ツリーのすべれのノードをイテレートする」のようにあいまいなこともある
  2. タスクをできるだけ異なる関数に分離する。少なくとも異なる領域に分割する。

12章 コードに思いを込める

コードをより明確にする簡単な手順を使う

  1. コードの動作を簡単な言葉で同僚にもわかるように説明する
  2. その説明のなかでs使っているキーワードやフレーズに注目する
  3. その説明に合わせてコードを書く

声に出すラバーダッキングは有効である。

13章 短いコードを書く

  • 最も読みやすいコードは何も書かれていないコードだ

  • 汎用的な「ユーティリティ」コードを作って、重複コードを削除する。

  • 未使用のコードや無用の機能を削除する
  • プロジェクトをサブプロジェクトに分割する
  • コードの「重量」を意識する。軽量で機敏にしておく
  • 不必要な機能をプロダクトから削除する。過剰な機能は持たせない。
  • 最も簡単に問題を解決できるような要求を考える。
  • 定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく。

新しいものはなるべく書かない

第四部 選抜テーマ

14章 テストと読みやすさ

  • 他のプログラマが安心してテストの追加や変更ができるように、テストコードを読みやすくする。
  • コードを完全にテストする最も単純な入力値の組み合わせを選択しなければいけない。
  • テストには最もキレイで単純な値を選ぶ。

15章 「分/時間カウンタ」を設計・実装する

割愛。

リーダブルコード 第二部

書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。

第二部 ループとロジックの単純化

7章 制御フローを読みやすくする

  • 条件やループなどの制御フローはできるだけ「自然」にする。コードの読み手が立ち止まったり読み返したりしないように書く。
  • 条件の並び順の優劣
    • 条件は非定型よりも肯定形を使う。例えば、if(!debug)ではなくif(debug)を使う。
    • 単純な条件を先に書く。ifとelseが同じ画面に表示されるので見やすい
    • 関心を引く条件や目立つ条件を先に書く
  • 衝突することがあるので自分で判断する
  • 行数を短くするよりも、他の人が理解するのにかかる時間を短くする
  • 変更するときにはコードを新鮮な目で見る。一歩下がって全体を見る

8章 巨大な式を分割する

  • 巨大な式は飲み込みやすい大きさに分割する
  • 「頭がいい」コードに気をつける。あとで他の人がコードを読む時にわかりにくくなる。
  • 巨大な式の分割の最も簡単な方法は「説明変数」を導入すること。以下の3つの利点がある
    • 巨大な式を分割できる
    • 簡潔な名前で式を説明することで、コードを文書化できる
    • コードの主要な「概念」を読み手が意識しやすくなる

9章 変数と読みやすさ

この章は下記の問題について考える。

  1. 変数が多いと変数を追跡するのが難しくなる。
  2. 変数のスコープが大きいとスコープを把握する時間が長くなる。
  3. 変数が頻繁に変更されると現在の値を把握するのが難しくなる。

解決は

  1. 邪魔な変数は削除する。
  2. 変数のスコープをできるだけ小さくする。
  3. 一度だけ書き込む変数を使う。

リーダブルコード 第一部

書籍「リーダブルコード」を読みつつ自分用のメモとしてまとめたので、備忘としても残しておく。

1章 理解しやすいコード

  • コードは理解しやすくなければいけない
  • コードは他の人が最短時間で理解できるように書かなければいけない
    • コードを理解するとは「バグを見つけられる」「変更を加えることができる」「6ヶ月後の自分も含んだ他人が上記を行える」
  • 理解する時間を短くするコードのためのコメントもあり

第一部 表面上の改善

2章 名前に情報を詰め込む

  • 名前に情報を詰め込む

テーマ

  • 明確な単語を選ぶ
    • 気取った言い回しよりも明確で正確な方がいい
  • 汎用的な名前を避ける(あるいは、使う状況を選ぶ)
    • tmp・it・retvalのような汎用的な名前を使うときは、それ相応の理由を用意しよう
  • 抽象的な名前よりも具体的な名前を使う
  • 接尾語や接頭語を使って情報を追加する
  • 名前の長さを決める
  • 名前のフォーマットで情報を伝える

類語辞典を活用しよう

3章 誤解されない名前

  • 名前が「他の意味と間違えられることはないだろうか?」と何度も自問自答する
  • 最善の名前とは誤解されない名前
  • 自分が書いたプログラムが正しく他人に理解されるかどうか

4章 美しさ

  • 一貫性のあるスタイルは正しいより重要だ
  • 複数のコードブロックで同じようなことをしていたら、シルエットも同じようなものにする
  • コードの「列」を整列すれば、概要が把握しやすくなる
  • ある場所で【A・B・C】のように並んでいたものを、他の場所で【B・C・A】のように並べてはいけない。意味のある順番を選んで、常にその順番を守る
  • 空行を使って大きなブロックをロン履歴な「段落」に分ける

5章 コメントすべきことを知る

  • コメントの目的は、書き手の意図を読み手に知らせることである
  • コードからすぐわかることをコメントに書かない
  • コードを理解することに役立つものなら何でもいいから書こう
  • コメントを書く作業は3つに分解できる
    • 頭の中にあるコメントをとにかく書き出す
    • コメントを読んで(どちらかと言えば)改善が必要なものを見つける
    • 改善する
  • 酷いコード+コメントではなくコードそのものを改善すること

6章 コメントは正確で簡潔に

  • コメントは領域に対する情報の比率が高くなければいけない
  • 複数のものを指す可能性がある「それ」や「これ」などの代名詞を避ける
  • 関数の操作はできるだけ正確に説明する
  • コメントに含める入出力の実例を慎重に選ぶ
  • コードの意図は、詳細レベルではなく、高レベルで記述する
  • よくわからない引数にはインラインコメントを使う(例:Function ( / arg = / ...))
  • 多くの意味が詰め込まれた言葉や表現を使って、コメントを簡潔に保つ

about this blog ~ feel so think

初めて記す。

ブログの一つ目の記事って迷う。

何かを伝えたいとかそういうブログではなく、日々思うこと、感じることをただ感じたままに綴れればいいなと思う。

そんなウェブログ。ログとしての自分の何かが続ければ残っていくだろうと感じるためだけに書いてみようと思う。

日々していること

  • 仕事
  • ゲーム
  • 漫画
  • アニメ
  • 筋トレ ー 楽器(ベース)

こんな世界の片隅にどこにでもいそうな、そんな人間。

ちっぽけな世界を書いていこう。