プログラマが知るべき97のこと/1人より2人
プログラマが知るべき97のこと/1人より2人 - Wikisource
宝くじのリスクがとても良かった。 これ私が前に書いた、より安全の話に近いと思った。 ほぼありえないリスクを考慮してより良い選択はどちらかってところ。 でもやっぱりペアプロの費用対効果はまだ疑問符残るな
[A]
もし開発チームに加わったばかりの新人なら、ペアの相手には、知識も経験も豊富な人を選ぶべきでしょう。 これができるのは贅沢なプロジェクト
経験豊富な人がいない場合、「2人で考えました!」と変なもの作られたらもうOUT
またそれと同じくらい重要なのは、人間関係を円滑にできる人、また人にものを教えるのが得意な人を選ぶことです。
昔、同僚に「コーチングというのがあって…」と言われたけど、彼が一番良く理解してなかった 同僚はペアプロの信奉者 ペアプロはやる気があって根性を曲げる必要のないペアでしか成立しづらいので、懐疑的。 コーチングって、哲学に似てて、コーチする人はそいつのそばに疑問を置いてやるしかないのと、 哲学する本人に間違った自尊心があると成立しない。 「自分の自尊心はどうでもいいから、真実を知りたい」という気持ちを持つ自分、という自尊心が必要で、 なかなかそこら辺は難しいかな。 高所に到達して安全な位置の心の状態を持っているか、達観してるか、のどっちかで、 前者は成功者だし、後者は坊主だ
- 補足
根性を曲げる必要のない = 素直な気持ちでコーチングや設計に集中する、という気持ち
高所に到達して安全な位置の心の状態を持っている = 嫌なやつと組んでるとか邪心とかない状態
オブジェクト指向エクササイズのススメ
www.slideshare.net
マジでこれ無料公開かよ。すげーいい時代だな
[A] 興味深い
[A] 今日は遊ぶ暇ないなw
[A] 明日現場で読むかw
[S] 何がまじかよなん?
[M] ただでこれ読めるんだよ?
[M] 僕のバイブル
[S] そっちかw なるほど。
[A] [妥協する」w
[A] http://www.slideshare.net/nowokay/ss-41730024 slideshare.net
[A] こっちも面白いw
[A] どーしてこうなるw
[M] なんかよくわからんかった
[A] http://www.slideshare.net/rootmoon/7-37892729 slideshare.net
[A] こっちはまともw
[M] ドキュメント見つからなかった
[S] http://postd.cc/more-good-programming-quotes/
[S] オブジェクト指向エクササイズでドットシンタックスの件はjQueryとかReactiveExtensionsとかのチェーンビリティを考えると、ちと辛いっすね。
[M] 関数型言語では辛いと思うけど、最終的には結局ここに行き着くような気がしている
プログラマが知るべき97のこと/「人間」を知る
プログラマが知るべき97のこと/「人間」を知る - Wikisource
言葉にしづらいが、とても重要な気がする
プログラマが知るべき97のこと/偶然の仕様ではなく本物の仕様のためのテストを書く
プログラマが知るべき97のこと/偶然の仕様ではなく本物の仕様のためのテストを書く - Wikisource
1ヶ月に一回読みたい 簡単に書いてるけど実践は難しい。 必ずメソッドの構造を見てテストを書いてしまうから。 テストファーストを実践すればいけそう。 ただテストファーストが辛い。
[S] 単体テストでよくあるJSON、XML、HTMLの比較だけでも実践(属性順に依存しないとか)のくせつけたいな。 単純に文字列化比較しちゃうとライブラリのアップデートとかで簡単にこけるテストになるからね。
[A] コードレビューはユニットテストレビューのつもりでやるといくらか解決されるかもね。
[M] 最近本当にそう思う。コードレビューで重要なのはテストコードなのではないか?という1つの結論。
[M] そこからTDD思想に則り、コードが最適化されていくという流れが一番自然なのではないか。と
[M] スレッドの問題とかユニットテストで保管できないコード的な問題はやっぱりコード本体をレビューする必要があると思うが、そこまで重要なコードって全体の5%もあれば多い方だと思うので考えなくても良いレベルかとも思う。
[S] ケント・ベックの書籍読み直すか。
プログラマが知るべき97のこと/車輪の再発明の効用
プログラマが知るべき97のこと/車輪の再発明の効用 - Wikisource
よく出てくる単語がまた出てきた。 この車輪の再発明の使い方はポジティブで良い
[S] 非常に頷ける。 問題解決能力のほか、自分でフレームワークとかライブラリを作る場合も土台になるよね。
[A] モノによるw
[A] 「自分の手でゼロからコードを書き、あれこれと試行錯誤をすることを通して学ぶ」のと「**を自分で作り直して組み込む」ってのは大きく違う。
[A] それと、荷馬車の車輪があるからと言って、自動車向けに車輪を再発明するのも違うし。
[A] 再発明や応用をする必要があるなら、その原理を学んでないと苦しいかもね…って事に還元されてしまう気がするわ。
[S] そんなもんすかね。
[S] ただ、
自分の手でゼロからコードを書き、あれこれと試行錯誤をすることを通して学ぶ これは、ハイコストハイリターンなのは違いない。
ワープロとWYSIWYGをゼロから作ったことあるけど、掛かる時間やばい。得たものも相応に大きかったけど。
[A] 再発明は必要なときもある(特に新しいもの、新しい時代に)。
[A] 再発明すれば、勉強になる。
[A] どっちも間違ってないけど、作ってるモノによって、選ぶ方法は変わる。=モノによるw
[S] それは確かにそうですね。
[A] 「教育」というのは、「ひっくり返った亀がもがく」が必要。「生産」は「ひっくり返らない事」が必要。
[S] 面白いw
[A] 自社で後輩の面倒を見るときに、ここのジレンマが大変。教師はいいなーっていつも思う。
[M]
「教育」というのは、「ひっくり返った亀がもがく」が必要。「生産」は「ひっくり返らない事」が必要。
これいいね
[A] 教育現場の人はよく口にする話かな。
[S] 職場の教育でもがきをやらせるのは厳しい。
[S] というか、それは学ぶ側が自分で時間とって個人でやるべきだわな。
[A] 僕が、「教育」というのは「ひっくり返った亀がもがく」が本旨、と聞いたのは、道徳哲学の大学教員だったけど、
[S] なんで俺的には、良い技術者は勝手に育つから、人を育てるよりは育った人を離さないようにする職場が理想だと思ってる。
[A] 人格の形成とは「自己陶冶」という点に、とても共感している。
[A] 技術者の形成とは、技術者が自ら「自己陶冶」できるように育てることが、おそらくいちばん大事なんだよね。
[A] 「勝手に育つ」ように仕向ける。
[A] 「育った人を離さないようにする職場が理想」ってのもそうだけど、
[A] googleだっけか、コピーを作る人っていう話がどっかで出てたかな。
[A] 「面白いと思ってやってることが金になる」なら技術者は自ら学ぶし、いなくならないよね。
[S] そうですね。
[A] 「いまさらだけど*****の面白い仕組み」とかの勉強会とかみんなでやれるとそういう職場になると期待するしかないのかもしれない。
[M]
人を育てるよりは育った人を離さないようにする職場が理想だと思ってる。
僕にはこれは不可能に見える。 だって育ったら自分でやってみたくなるじゃん。 お金あったら、そのお金で時間買って作りたくなるじゃん。 組織の仕事できないじゃん。 組織にとって、よっぽどのことがないと引き止める理由ないじゃん。 辞めるよね。
組織にいながら頭を抑え付けられず自分のやりたいことができる組織って、それ組織として崩壊してる気もするので、なんか矛盾していて不可能に思えた。
[A] 絵描きは絵描くのが好きだし、音作りやる人は音作るの好きだから、そこら辺組み合わせるコーディネーターがいるかどうかも大事だと思ってる。
S さっきでたけど、内的報酬、外的報酬の話だと思う。
[A] アメフトの司令塔はQBだけど、実際はオフェンシブコーディネーターとQBは試合中インカムで会話しながらやってる。WRやHBは走るの好きだし、TEはぶちかましが好きだし、Sは人の妨害するのが好きなので、それでいいと思うよ。
[M] まだ読めてない。探して読んでくる
[A] キーは前に出た人は24時間しかないって事じゃないかな。全部出来ないし、得手不得手はあるから得意な事で進めたいし、得意を伸ばしたい。
[A] 管理に行きたいか、技術に行きたいか、業務を抱えたいか。
[A] 一応は本人の希望を考慮する。適正ないと可哀想な扱いになるけど。
[M]
さっきでたけど、内的報酬、外的報酬の話だと思う
読んだけど、やっぱり 内的報酬
を100%満たすことはできずに結局独り立ちすることになりそう。
なので、どれだけ組織が 内的報酬
外的報酬
を用意しても実現は難しそう。
googleとかの超大手は最前線でこれ意識してそうだけど、結局優秀な人って独立してない?
[S] それ、「正解はひとつ」になってなければ良いのだけどね。 高給取が「管理」に集中してるようだと良くなさそう。
[A] 管理者は高給取だけど、技術選んでも業務選んでも割と食っていけるだけの年収はあるらしい。ベーシックインカムみたいなもんやね。
[A] だから辞める人は、自分の内的理由で辞める人が殆ど。
[A] お金ではやめない。
[A] 独立はしてもいいやん。
[A] 会社にとっての人的資産流出は、仲違いなのだから。
[A] 昔で言うアスキー、スクエニなんかも、辞めて独立しても出入りして仕事してる人多いし、会社もそれなら全然オーケーだと思う。
[S]
会社にとっての人的資産流出は、仲違いなのだから。
うまい。確かにそうだな。
今日のポエム
githubコードレビューはエゴの塊だ。 そのコードが良くなるというより、俺が読みづらいから直せの雰囲気を感じる。 これではダメだ。 ほんの少しでも良くなる指摘をするべきだ。 それは命名による読みづらさではない。 実行時パフォーマンスという点でだ。
S
コードレビューの内容実際見ないと感想は言えんな。 前もなんか同じ話題した気がするけど、コーディング規約じみたチェックはするけど、コードの中身はあまり読んでもらえないんだっけか。 命名規則云々はコーディング規則で規定するべきで、それに則ってなければただの誤字脱字みたいなもんで、指摘は有りだけど、議論するところではない。 さっと流して中身を議論するべきで、そこ出来てないなら本末転倒ではあるかもですね。
M
今の僕の印象だと、命名指摘:8割、パフォ指摘:2割ってイメージ。 致命的でない限り命名指摘の費用対効果って、薄いと思うのでそれに対してかけている時間(チェック・変更修正・確認)が無駄にしか思えない。
S
言いたいことはまた違うんだろうけども。 コードの見やすさ自体は最終的な工数にも響くんでかなり重要だと思ってる。 まあ、コードの見易さは最終的に宗教問題だから、合わないと最悪 見やすいコード とは => 一貫性のあるコード => コーディング規約を規定 コーディング規約に規定しない一貫性 => プロジェクトの王様の思想に合わせる 最終的には郷に従わないといけない部分が出てくる。
ただのローカルログ