新しいものを表示
セロトニンください さんがブースト

水素水飲んでネタにすぐ対応できるような体づくりをせねば

lintとformatter、外に出るときには服来て出かけるのと同じぐらい当たり前であってほしい。

ちなみにPHPとPhpStormの組み合わせはワーニングがクソ煩くてphpDocがもりもり膨らむという傾向が出てきて辛い。

セロトニンください さんがブースト

lint と format は現代を生きる人類の義務といえる(適当)(本気)

もし自社開発であればリファクタリングのチャンスはあるはずなんですが、開発要員が足りないと雑な設計のもとに新機能実装がやむを得ずなされて、じわりじわりとクソコードとなっていきます。設計は割と生き物なので、やばいとなったら立ち止まってリファクタリングする必要があるんですが、これを果たして会社は承認してくれるのでしょうかね??承認してくれたらとてもいい会社だと思います。

あと、僕の場合ユニットテスト敷かれてないとクソコードとかレガシーコードとか言い出す。

1メソッド30行超えだすとなんかムズムズしだして、100行超えだすと中指が立つ。

試作品とかならいいんですけど、修正に納期がつきまとうようになってくると殺意が湧いてきますよ。

最近、メソッドが縦に2画面使うようになってくるとfxckというワードが頭をよぎり始めるのでまだまだ菩薩になれていないと感じます。

手続き型からオブジェクト指向型に強引に移植されて、書き方はどう見ても手続き型で、1万行を超えるゴッドクラスや1000行を超えるモンスターメソッドなどを見たら自然と口から出ますよ。>BT

学生時代からずーっと見積もり失敗しててはきそう

僕の場合、ティントきた見積もり工数に2倍以上をかけないと駄目臭い…(自信を失う)

M3振り返りに思ったよりも時間取られている(いつもの)

ちなみに僕は、得体の知れないプロジェクトに入って雰囲気つかめてない状態のままクソコードを読みつつ新たに機能を追加しますとなったら、「無難な選択肢を取りたいのでクソコード風な書き方をしてプルリクする」ということをします。

まあこれはプロジェクトの規模による。

得は当然あるけれどもコミュニケーションコスト発生するからそこはそこで気を付けないとね

セロトニンください さんがブースト

本の予算の都合でオレンジはまだ読んでない本だけど、よく名前を聞く本で言うと、
O'Reilly Japan - リーダブルコード oreilly.co.jp/books/9784873115
みたいな感じでちゃんと書けているか?><を検証するのに、自分だけで考えるよりも、「あなたが書いたもの作ったものでここがわけわからなかったです・・・」って人をサポートすると、より手っ取り速いですよって言いたい・・・><

古いものを表示