少人数開発に役立つ5つのまとめ
if ( $blog == " Webエンジニアのためのライフハック " ) { print " 1-byte.jp "; } ホーム1-byte.jpとは 書いてるヒトは ここ2ヶ月間で気になる記事がたくさん上がっていました。 特に少人数チームにおける開発に関する記事です。 昨日、書き上げた”1年間の技術的負債を返すために読んだ3冊の本“にある通り、お知らせメールでは1年間の技術的負債を返そうとしています。 そのためには今まで曖昧だった箇所を浮き彫りにし、改善する必要があります。 また、せっかくなので新しいモノも取り入れたい。 こうしたことを考えながらの2ヶ月だったので、自然と目に止まった記事が3つありました。 スタートアップ企業で8年間Webの開発をしてみての反省点いろいろ 複数人(2-3人)でウェブサービスを開発するコツ A successful Git branching m
[ソフト開発] わかりやすいプログラムの書き方 - よくわかりません
※このエントリは、Arata Kojima/NPO法人しゃらく さんが公開しているわかりやすい技術文章の書き方の改変です。 このページは、プログラムやコードなどを書く方々のために、分かりやすいプログラムを書くためにはどうすればよいのかについて説明しています。 1. 自分が伝えたいこと・訴えたいことを誤解しないように相手に読んでもらうにはどうするべきか。 2. プログラムを書くにあたって知っておくべきルールは何か。 3. プログラムを書く前にどのような手順を踏めば、分かりやすいプログラムを作れるか。 などについて参考にしていただければ幸いです。 プログラムを書く前に プログラムを書く前に次のことをしっかりとイメージしておく。 何を書くのか。 書こうとしている物は正確に何であるのか。 仮定して良い、必ず成り立つ前提（状況／状態）は何か。 成り立つ事が単に多いだけ／今はたまたま成り立っている、と
「このサイトと同じものを」の危険性 - がるの健忘録
以前から何度もあった話なのですが…ちょいとかみ砕いて。 まず。 「このサイトと同じように作ってください」という発注は、原則NGだと思っています。ここが結論。 高確率で「無考察」という背景が見えるから、というのが理由になるのですが。 以下、もう少々かみ砕いて。 上述の発注が来た場合。作業としてはまず「指定されたサイトの仕様調査」になるわけなのですが。 いわゆる「画面遷移」ひとつをとっても。コンパクトなサイトであっても、数十Pageに渡るなんてのは案外にさらっとある話です。 正直、全Pageなめ回して、抜けオチがないようにチェックするだけでも一苦労ですし。ある程度まで「使ってみて」、様々な分岐処理を全部洗い出した上で確認しなければならないので。 結果として…おそらく、発注側が気軽に使っているニュアンスとは裏腹に、大抵の場合「結構な高コスト」になります。 …という話をすると大抵出てくるのが「そこ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
