技術的負債とどうやって戦うか - Qiita
プロジェクトが進行するにつれて増える『負債』 長いプロジェクトに携わっていると、技術的負債をいつ返すのかが課題になってきます。 リファクタリングはいつの時点でやるのか、これは長いプロジェクトを運用していく上で問題になっていきますが、今回は負債の種類を整理し、それぞれどう対応をしていけばよいかを考えていきたいと思います。 私達の開発では常に時間が足りない 最近読んだ、「アジャイルサムライ」という本には下記のようなことが書いてありました。 (開発における)3つの真実 プロジェクト開始時点にすべての要求をあつめることは出来ない 集めたところで要求はどれも必ずと言っていいほど変わる やるべきことはいつだって与えられた時間と資金よりも多い 以上のことからわかるように、私達の開発には時間が無いということが常だということがわかります。実際、技術的負債が多いプロジェクトほどこの傾向が強いのではないでしょう
会社潰すのは簡単、アイツがいれば勝てる、と思った人間を雇えば良い
最近話題の エンジニアよ、ゼネラリストなんて目指すな！―VASILY 金山裕樹のキャリア論（http://japan.internet.com/busnews/20121130/3.html）を見て・・・ コードを書くことが目的化しちゃってる人も多いので全否定するつもりはないけど、コードが汚くても「アイツがいれば勝てる」と思わせる人間を素人判断で雇うことが如何に危険かプログラマ視点でまとめてみる。以下何度も見てきた典型的な失敗パターン、設計と実装が完全に分業化されてる分野は知らないけどWeb業界などそうでない所のお話。 手抜きプログラマは人を騙す非エンジニアを騙して手抜きするのは簡単。余程のヘタレでない限り手抜きをしても絶対にばれない。コードにコメントがなくてもモジュール化されてなくてもコピペ満載でもマジックナンバーだらけでも動いてさえいればユーザーは気にしない。 手抜きプログラマの評価は
エクセルで顧客リストのCSVファイルを読み込んだところ、携帯電話番号の090XXXXXXXXが90XXXXXXXXとなってしまいます。…
エクセルで顧客リストのCSVファイルを読み込んだところ、携帯電話番号の090XXXXXXXXが90XXXXXXXXとなってしまいます。 先頭に’を付ければ0は表示されますが、それ以外の方法でそのまま表示する方法はありませんか？ （携帯電話番号以外にも色々な数字コードが入り混じっているので桁数も一定ではありません。）
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
