意味のある名前について

Clean Codeを題材に色々書いた。飛ばしている目次もある。
自分にとって必要なところだけ写経。自分の思いが強いところは自分の言葉で。

■意図が明確な名前にする
その意図が明確な名前をつける、言葉なら簡単に言える。
胸に刻みつけることはたくさんあるが、良い名前をつけることはその後の時間の節約できる。
名前をつける時は注意深く、そして後でより良い名前が浮かんだら変更してください。そうすることで他の人を幸せにできます。
変数、関数、クラス名は大命題に答える必要があります。なぜそれが存在するのか、何をするのか、どのように使用するのか。もし名前に説明が必要なら意図が明確とは言えません。

意図を表現した名前を用いれば、コードはもっと変更しやすいコードになります。いかに例を書いた。

public List<int[]> getTeam(){
  List<int[]> list1 = new ArrayList<>();
  for(int[] x : theList){
    if(x[0] == 10){ list1.add(x); }
    return list1;
  }
} 

難しい記述はないものの、これではしたことが明確には分からない。というか伝わらない。
このコードを見た時、暗黙的に考えてしまうことが
1. theListはなに?
2. 4という値はなにを表すのか
3. 戻り値のlistはなにを指すか
4. theListの[0]はなんだ
上記のような暗黙の問いは、コード以外の場所に存在する。(ドキュメント類)

では、次のように書き換えてみよう。
マインスイーパーのプログラムだとした時、

public List<int[]> getFlaggedCells(){
  List<int[]> flaggedCells = new ArrayList<>();
  for(int[] cells : gameBoard){
    if(cells[STATUS_VALUE] == FLAGGED){ flaggedCells.add(cell); }
    return flaggedCells;
  }
} 

コードの構造は変えずに、値に意味を与えた状態。さっきより読みやすい。だけど条件式などがまだ明確でない。次は、厳密に役割を与えて名前をつけてみよう。

public List<int[]> getFlaggedCells(){
  List<int[]> flaggedCells = new ArrayList<>();
  for(Cell cell : gameBoard){
    if(cell.isFlagged()){ flaggedCells.add(cell); }
    return flaggedCells;
  }
} 

こんな感じで、名前を明確化し、適切な名前をつけるだけでコード上で何が行われているのかが読み取りやすくなります。


■偽情報を避ける
コードの情報を曖昧にしてしまうような、間違った情報をコードに入れるのは避けるべき。その単語の意味が確立されて意味が、我々が意図した意味以外に様々に存在するのであれば、その名前は避けるべき。複数の顧客際に、実際にそれがList でないなら、accountListという名前を使用するのはやめましょう。間違った理解を招く可能性があります。accountGroup、あるいはaccountsのような名前がいいと思う。似た概念に似た綴りを与えるのは1つの情報になります。ですが、ごく一部分のみが異なる名前をつけないように。XYZControllerクラスに、EfficientHandlingOfStringとEfficientStorageOfStringが混在していたら気づくのが遅くなる可能性があります。整合性のない綴りを使用するのは錯乱します。気をつけましょう。

■意味のある対比を行う
get1やget2のような、数字の連続を使用した名前は避けてください。クラスも同様です。これは錯乱というより、無情報です。これらの名前はプログラマの意図を提供しません。

public static void copyChars(char a1[], char a2[]){
  for(int i = 0 i < a1.length; i++){
    a2[i] = a[1];
  }

このメソッドの引数の名前が、source、destinationなら読みやすくなりと思います。ノイズを発するワードにはまた別の無意味さがあります。例えば、Productというクラスがあるとして、ProductDataやProductInfoというクラスがある場合、違う名前をつけても意味は一緒です。InfoやDataは英語のa、an、theのようなものです。意味に明確な違いがあるのであれば、付け加えるのも間違いではないということも注意してください。読み手に違いがわかるような名前をつけてください。
ノイズワードは冗長的です。variableという単語が変数名に含まれてはいけません。tableという単語が表の名前に含まれてはいけません。NameStringのどこがNameよりも優れているというのか。

■発音可能な名前を使用する
オレオレ省略はやめてください。headerの事、getHdrはgetHeaderだとか、DtRcdはDataRecordだとか。例外もあります。例えば、indexはiと略されたり。
名前が長くなっても、オレオレ省略はやめてください。そもそも長くなりすぎる名前には、責務与えすぎという問題も気にしてください。

■メンタルマッピングを避ける
自分がつけた名前を、コードを読む人が心の中で(その人が知っている)名前に変換しなければならないような状況を作ってはいけない。ノイズになります。

■根拠のない文脈を与えない
例えばの話、プレフィックスやサフィックスを「整合性」としてつけるのはやめましょう。それはコードには関係ないので。ソレの役割を適切な名前で使用してください。




以上。
だいぶ要約して書いた。他の人と理解が違っている箇所もあると思うけど、そういう時は指摘してくれると助かります。
それにしても最後らへんの飽きた感w
けどいいや。

きくかわ、会社辞めるってよ。

どうも、きくかわさんです。

 

蒸し暑い日が続いてるね。こう、、、風に肌を舐められてる感触。ソレを味わいながら街を歩きますが。嘘、味わってない。

 

さて、本題。

7月31日をもって退職が決定しました。入社して3年半年くらいかな?試用期間もあったしよくわからないけど。22歳プログラム歴4年目。高卒で働いて、、、振り返ると少し前のように思える、早いなぁ。(卒業式か!)

辞める経緯としては色々。でも強いて言うなら、前の現場が楽しくて、今の現場が楽しくない。その現場チェーンが生んだしこりがでかくなって取りたくなった。

 

次どうするの?って聞かれるけどわからない。

「良い」会社があれば入りたい。

良いの定義は、チーム開発してて仲が良いチームとか給料が良いとか、、、それだけか。そんなところに入れなければフリーランスとして野良きくかわさんになるしかないわけで。

 

もちろん将来も考えてるわけだから、しっかり稼がないといけない。技術的、仕事への考えが未熟とかは言い訳しない、成熟したくないってのもある。けどそういうの、足りないから中々仕事って見つからないんだね。会社も。どこを見てもハードルが高い「気がする」。縁ってどこにあるんだろう。

 

これから不安を感じながら日々過ごすわけだけど、どうにか幸せになりたい。近くにいる人とかお世話になった人に顔向けできないし。まず俺が幸せじゃなきゃね。

 

別に形式ばって書くつもりなかったから投げやり文章。

頑張らないとね、さらに。

 

縁よ、こーい。

TDDBCで僕が持ち帰ったもの

どうも、きくかわさんです。

 

TDDBC(Test Driven Development Boot Camp)に参加してまいりました!

TDD Boot Camp(TDDBC) - TDDBC

仕事以上に疲れた。俺いつも手抜いて仕事してたのか‥って思うくらいには。

 

・参加への理由

TDDってテスト駆動開発の事ね、はいはい。。。で?詳細は知らないよ?

ってなったので参加してみた。いつもそれっぽいことはしてるけれど、TDDについて説明できない =「つもり」を解消したかった。あとは、、、ペアプロ久しぶりにしたかったんです。はい。

 

・TDDBCの目標(あくまで個人的な見解)

今日のテーマは、気軽に!だった。

 そして、TDDBCはこう謳ってます。

TDD Boot Camp(TDDBC) とは、テスト駆動開発(Test Driven Development)について、座学だけでなく、実習形式で手を動かして体得することを目的とするイベントです。

TDDを体得すること!!

つまり、2回目の受講者としての参加は、この人たちにとっては責務を果たせてないらしい。 きっとTAの人たちへの一番のお礼は、次TAとしての参加なんだろう。

 

・内容

最初に講演、TDDのこころ(タイトル忘れちゃった)をご静聴。irofさんのスライド、名言的なの多くてめっちゃすこ。(変な意味はないです。)

続いてデモペアプロをご騒聴。完全コントでした、これは褒め言葉です!コンビ名は左右らしいですよ。

あとはTDDペアプロで50分、振り返り10分を3回転。集中してたからかな、なかなかキツかった。

コードレビューして全体振り返りして、びあばっしゅ。 

まぁ色々割愛。

 

 

・感じた事

TDDってこんなに難しいの?って。ペアプロも取り込んだから余計に難しく感じのかな。テーマは気軽に。ちなみに気軽の意味は

こだわったり面倒がったりしないで行動に出るさま。また、堅苦しくなくて、気がおけないさま。

気軽にはまだなれなかった。こだわるし、面倒だし、堅苦しい。でもTDDスキルを身につけることで解消できそう。むしろ思想?が好きだから今後とも寄り添っていきたいと思うよ。

あと、Clean code that work. (動作するきれいなコード)って言葉。

誰もが望む事だと思うけど、実現できる人はどれだけいるんだろう?ってそんな感じ。

 

・僕が今日TDDBCで得たもの

1. TDDのルール

  • 重複を取り除く
  • 新しいコードを書くのはテストが失敗してる時だけ

2.テストパターン出しの助けになること、要素、心がけ

  • 不安をテストする
  • ToDoリストを作成し、それをテストとする (最初に作りすぎるより、ある程度出して、他からのフィードバックを元に追加していく)
  • 引き返す (テストをしていると、「あれも、これも」となる。そうなる前に、「一息ついて」「前に戻って」「小さなステップを意識する」)

3. TDDのサイクル

RED -> GREEN -> REFACTORINGのサイクルに乗っとって実装していく。それぞれのSTEPで気にすべきことがある。

RED

  • Assert First (最初にassert書け。話はそれからだ。)
  • Dog Fooding (自分が作った料理の味見してみ?ってことかな。)
  • エラーを観察しょ。。。 (エラーログが自分に何を訴えているのか見定めよ)

GREED

  • 仮実装 (なりふり構わずテストを通せ。話はそこかr)
  • 三角測量 (すみません、これよくわからない。)
  • 明白な実装 (一息でコードを書くが吉。実装方法が明白なら出来るでしょ?)

REFECTORING

  • 容赦のないリファクタリング (コードの悪臭を感知して早期に取り除く。)
  • テストのリファクタリング (テストも同じように、悪臭を放ちます。プロダクトコードをテストコードとして、テストコードをリファクタしましょう!)
  • リファクタリングの止めどき (次のテストを通すために変更箇所が1箇所なら止めていい。)

 簡単に説明すると

テストを書き、テストを通すためのそれなりのプロダクトコードを書き、通ったらプロダクトコードをきれいにする。これの繰り返し!

以上、今日の収穫です。 三角測量が本当わからない。。。

まぁできるできないは置いといて、チャレンジ精神と取り組みのルールはいただきました。ありがとう!

 

・あとがき

Developer Testing

開発者が開発者のために,自分自身のために,もしくはチームメンバーのために行うテストです。

これもすこ。(横文字名言の好きさ加減がハンパない気がする)

不安を解消してくれる奴っぽいし、しもふりにく沢山与えて仲間にしたいよねー。

「つもり」は多少改善された「つもり」

これ堂々巡り!!

 

あ、TAの皆さん、会場貸してくれたFirst Serverさんありがとう!

届け、俺の感謝の気持ち。

 

関ジャバ主催のKANJAVAPARTYに行ってきた!

どうも、きくかわさんです。

内容が絞られるためタイトル詐欺です。(自首)

 

6月24日の関ジャバのKANJAVAPARTYに行ってまいりました。

大規模イベントということで、かなりの人数の方や内容の濃いセッションが各部屋にて行われていてかなり刺激を受けた。(刺激受けすぎて死ぬかと思った。。。)

昨日ブログ書こうと思ったんだけどね、体力なくて帰ってすぐ死んだよ。 懇親会もあったし、二次会も少しの時間だけど行ったので。(夢見たいな空間だった。)

 

んでまぁ色々見たんだけど、ハンパないほどめっちゃはかなりすごくとてもしょるけど、寺田さんのセッションが「これはやばい。この人かっこよすぎる」って感じた。

正直なところ、Javaエバンジェリストとかすごさもわかんないし、JavaCampionだからどうとか俺はまだわかんなかったからそういう視座では見てなかったんだよ。ただ立ち振る舞いやその姿を見てただかっこいい。んでその未来に生きる姿勢がすごく響いた。技巧的でありエモいセッション。俺この人に救われたよ。だから今回はこの人に注目して書く。一番思い入れ強かったし、うん。

 

まぁ俺のモチベーション云々は置いといて、セッション内容について。

ブログに残すとか考えてなかったし、主に自分が興味のあることしかメモってないから粗雑ではあるのでご了承を。

 

$$セッション題名

■You can change the world! AI & Bot でより良い社会を作ろう!

 

内容的には、「〜教えて」って入力したらURLとか、その説明がが返ってくるような感じのアプリを題材にしてた。UIがLINEみたいな対話形式だったのも。

その裏側を見せてくれたり。使ってたのがMicrosoftAPI多かったし、RESTが使えればどの言語でも的なことをおっしゃってたので敷居を下げてくれたりね。

そもそも翻訳とかってGoogleとかIBMのワトソンのイメージもあってMicrosoftがそんなの作ってたのかおい。って思いましたまる。実際にコードとか見せてもらったり。凄く簡素だったイメージ、API呼ぶだけだからかな?

んで、今回それを作るにあたって一番時間かかったのが「データのパターン作る」ところ。…わかる、凄くわかるよ!!!って心の中で叫んだ。(心が叫びたがってたし)

そういう「〜教えて」って言い方が一つならいいんだけど、方言もあるし言い方が変わっても意味が同じなんだってのを、自分でパターン出す時って限界あるししんどかった、って経験があるから物すごく共感できた。それとこんなにすごい人と同じところで苦労したってとこがなんか嬉しかった。

最後にほんやくコンニャク、はい。これ聞いた時、アァスゲーミライってね。本当に未来的だった。リアルタイム翻訳のことね。

まぁ理論的にはデバイスから音声が取り込まれてそれをテキストに置き換えて翻訳して音声データにして返す。

これができればいいんだけど、なんかそれを見た時すごいなぁって少年の心取り戻した。(小学生の夢がゲームプログラマだったのも思い出した。)

 

$$気になった単語

■Cognitive Services

まぁMicrosoft のインテリジェンスAPIの集合体なのかな?

azure.microsoft.com

 

Microsoft Translator

まぁ、翻訳サービスだね。

Cognitive Servicesの一つにもそんなのがあったけど違いってなんなのかな?

Microsoft Translator - Built for enterprise

(これだけ埋め込みできなかった。)

 

■LUIS

自然言語を解析してくれるツール。文章の種類を振り分けたり、キーワードを抽出してくれるやつ。GUIでできるんだって。

www.luis.ai

 

他にもあったんだけどさ、これらが気になってて。

(仕事でもこんな感じのことしてるし)

特にLUIS。本当これみたとき衝撃受けたんだよね。

これを知るまでは、入力された文章を自分で形態素解析して、XMLで管理しておいたフレーズに対して類似するフレーズにパーセンテージ降って、一番スコアが高いフレーズを叩き出して、それに関する処理を行って。。。ほんと泥臭いやり方してるw

これを知っただけでも、あの場に行った意味も出てくるし「勉強会ってか、予習会なんじゃねぇか、、?」という思いが強くなった。

まだ使えてないんだけど、このブログではとりあえず「思いの丈を書く」と決めていたのでLUIS使った軽いアプリ作れたらまた何か書こうと思う。

 

最後に。

他にも面白いセッションたくさんあったし、すごくためになった。

知識だけの話じゃなくて。耳の痛い話も聞いたし。笑

あとね寺田さんに「ブログ書くまでが勉強会」と教わりました。これからそうします、アウトプット大事だよね、登壇者が一番勉強になるって俺も知ってるし。

関わってくれたみなさんありがとうございます!(直接言えよ。)

発散の在り処

ストレス、どこで発散しますか?

人間関係、金銭関係、仕事、恋愛さまざまなストレスの発生源の押さえ方。

それらは一体どこにあるのかが最近わからなくなってきました。_(:3」z)_

 

というのも、私は喫煙者でして一週間前ほどから禁煙しました。理由はお金と健康のためです。

実際吸わなくなって、3〜4日は全く吸いたいと思わないんですよね、いつも。

吸いたいときといえば、イライラが募った時に、イライラした気持ちをニュートラルに戻す道具として使ったりしてました。なんで減りも早いわけでなくて7日に1箱くらい。。。(多いんかな?)

 

で、

やめました。と断言はしても私の場合は仕事ですね、その関係でイライラすると必ずタバコを吸いに行き落ち着いて計画を立てて、さて作業、というプロセスが出来上がっていた訳です。タバコをやめたのでそれも上手く機能せず、イライラが募って仕方ないのでどうするべきか…と悩んでおりますと。

 

タバコなんていいことがないと、人は口々に言いますが私はそんなことないと思っていて、コミュニケーションが取れる、頭の中の整理ができる、ということでもすごく役に立っていました。意外に重要だったんだな、、、。

私の特性として、断言したら続かないというジンクスがありまして笑

なにげなーく、いつやめてもいいや、と思ったことはもう数年続いていて、その枷の様な言動が逆な苦しくて辞めてしまいガチなんですよね。(辞めた言い訳です)

 

甘えです。

ひたすら自分に甘えてます(^ν^)

 

皆さんの発散方法あれば知りたいです(^з^)

GW明けのアレ

どうも、何かが抜けた私です。

 

皆さんはこの時期いかがですか?

やる気が無いとか、仕事や勉強が億劫になる時期です。

かんっぜんに抜け殻。

やる気どっかに取られた気分が付きまとって中々思考回路が動きませんねー。

 

誰か対策しりませんか?

 

あー、、、嫌なことばかり考えてしまう。

悶々と

最近、悶々としてます。

ただの愚痴です。


いろいろあるけど、

・チームといいつつ個人プレイなチーム()

・朝の進捗を声かけないとやらない

・最新技術を使える案件なのに何かと古い

・ソースのテストを全くしない

・一部してる!って見つけたら結果をコンソールに表示してただけ…(assert使おうよ)


開発手法、手段ともにボロボロです(´∀`=)

技術力もないチームなので何だかこのままじゃ自分もダメになりそうだなぁとか思いながら最近は勉強を始めました。(4年目にして真面目になりだす)


どうにかしないと、、、と思ってチームの皆さんに直接投げかけたりメールを入れたりするも全く響かず、白旗をあげました。

このチームをどうにかするより自分がダメにならないようにするのに必死だ_| ̄|○


多くの人は現在まで培った経験や技術を武器に戦ってます。それで実現できることを知ってるのです。だから余計に辛い。

新しいものを更に取り入れるには学習や新たに経験を積まないといけない、効率よくするための何がしかをそれらによって効率が悪いと跳ね除けてしまいます。

ましてや若造にゴチャゴチャ言われるとウザいに決まってますよね(´∀`=)


だから分かり合えないと今は諦めて、もしまた気分が向いたらゴチャゴチャ言ってみようと思いましたまる


でも、なにをどう頑張ればいいのかねぇ…。



以上。