技術的負債への後悔と返済｜Seiji Takahashi@ベースマキナ
反省文。 tl;dr・「後から改善すれば良い」のスタンスは、返済コストを甘く見積もっている結果 ・負債の返済にはコーディング以外の工数が大きくかかってくる ・技術的負債を"徐々に"返済することは様々な面で良い 出社即リファクタリング最近出社した直後に、こっそりリファクタリングの時間を一定程度取るようにしている。朝のウォーミングアップがてら改善作業をしていると、瞑想みたいな効果があって大変気分がよくなるし、その後のコーディングも生産性が上がる。大体こういう気分。 具体的な作業は、アーキテクチャの方針が固まってなかった時代のコードの１つのエンドポイントだけ、適切なレイヤ化を施したり、単体テストが可能なメソッドとして切り出しつつ実際にテストを書いたり、テストに必要な共通処理を定義したり、だ。 初期から機能追加を重点的に行ってきたプロダクトでは、スピード優先の名目で多くの負債が生まれる。こうした負
TypeScriptをお勧めしたい7つの理由 - Qiita
お勧めしたい理由 1 新しい文法を使っても古い環境で動作させることができる 私の場合、GoogleBotが認識できるJavaScriptが前提なので、おのずと使える機能はES5に制限される。その範囲ではclassすら使うことはできない。しかしTypeScriptを用いれば、classだろうが継承だろうがやりたい放題だ。事前にやるべきことは出力ターゲットの指定だけだ。 2 型チェックが強力で柔軟 変数に型を付けることができるので、ちょっとしたミスが起きにくくなる。TypeScriptの凄まじいところは、可能性のある型をすべて記述できることだ。送られてくるデータが「数値」、もしくは「文字列が入った配列」など、可能性を事細かに指定できる。さらにif文で型チェックを入れておくだけで、文法チェックの段階で型を確定してくれるのだ。わざわざキャストする必要もない。これはかなりヤバイ。 3 入力補完が利用
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
