snobby.fm

放課後でティータイムな話題をお届けしたりしなかったりします。

ep.5 to be or not to be, that is the question.

2018年06月15日

MP3ファイルをダウンロード

内容紹介

出演者

luccafort
luccafort

日報をやめてGeekbotを始めた話し

  • 会社で導入したというわけではなく個人で導入した。
  • 日報に求められる「今日やったこと・明日やること・苦労してることや問題点」をDMでbotに返信していく。
  • 解答し終えると設定されたチャンネルにその内容がまとめて通知される仕組み。
  • また答える時間や質問内容は柔軟に設定できるため日報という大仰なシステムはいらなかったのだ!みたいな感覚がある。
  • とはいえ問題点もある。フルタイムでない社員がいた場合に関係ない曜日でもメンションされる。
  • 働いた日や時間を柔軟にしてほしいが元々フルタイムで働くことを前提にしてるっぽいので厳しい。
  • 有料プランでこの問題が解決するのかどうかわからないが良くなって欲しさがある。
  • また通知が飛ぶ時間が微妙に遅れてくることがある、これは無料枠だからなのか?致命的ではないがたまに通知来ないな?ってなることがある。

どんなに酷いコードでも現状動いてお金を稼いでいる以上は敬意を払うべきなので安易にクソコードとか言わず「歴史的経緯」って呼んでる

  • わかる…がとはいえ「稼いだ金額 < 費やしている人件費」なことは往々にしてあるのでそれはクソコードといっていいのでは?
  • クソコードという言い方が良くない、心理的安全性が得られないというのはわかるんだけどそれを放置するほうが良くないのでは?という気持ちが強い。
  • お金を生むコードは確かに尊い、だがしかし一転損益分岐点を超えた場合はそのコードはクソということになっている。
  • クソコードというよりは汚コード、腐れコードと呼称すべきなのかもしれない、賞味期限が切れたコードという意味で。

コメントのいらないプログラムの書き方

  • 意図はわかる…が煽り成分が多くて炎上してしまったもったいないエントリ。
  • コードはただの振る舞いでしかないので何故そうあるべきか?を書くのがコメントだと思う。ただコメントがいらないようなコードを書くべきというのは理解できる。
  • なのでぼくはコメントは必要があればつける派です。
  • そういえばこのブロガーさん、炎上した結果本質的でない部分で燃えてしまっって難しいと言ってたけど多分断定的だったり、ないほうがいいぞ!というニュアンスが皆無だからということを理解していないし普段から煽り気味な発言多いのでなんだかなあ…という気持ちになる。

普通の会社と駄目な会社の見分け方?

  • お題:ちょっといいこと思いついたんですけど、検索結果まるごとHttpSessionにもっちゃえば、ページめくりのたびにDB検索しなくて済むし、横から追加・削除あっても一覧表示ズレなくていいことづくめじゃないですか!?
  • まあこういうのは往々にして古いシステムなどでありがちではあるのだがふとこれを会社の良し悪しの判定に使えそうだなと思った。
  • というのも以前働いていた会社でとあるECサイトのカートの実装がまさしくこんな感じだった。
  • 恐らくここが普通の会社とだめな会社の分水嶺だと思うのだが普通の会社は「少しずつ大きすぎる裁量をセッションから剥がしていく」アプローチを取る。
  • ところが駄目な会社は「大きすぎてどこで問題がでるかわからないから触らないでおこう」となる。
  • こういうのは業務の至るところで発揮されるのではないかとこの話しをみて思い至った。
  • セッションやキャッシュは非常に便利である、だがしかしそこが肥大化してしまい問題があるといったときに企業としてどうアプローチしていくのか?最適解を少なくとも理解しているかどうかそれとも考えることを放棄しているかは駄目な会社の判断材料になり得そうだなと思った。
  • なお、ぼくが経験した会社で駄目なアプローチ、つまり大きすぎて何がなんだかわからんので放置というアプローチを取った会社は2社あった。
  • どちらの会社もやはり技術的なレベルが低いと感じて最終的に退職したのでリトマス試験紙として最低限の役割は果たせそうだなと思った。
  • 「こういう最適解を行うのが最善だけど問題が起こったらどうするのか?」と返すところは自分的にはマッチしない考えなので案外いい敷居な気がしてきた。