プログラムを作って饭を食うということ
- 1. プログラムを作る 2013/04/03 1 / 1 コストが下がる 快適な環境を追求する デバッグするスキル テストをするスキル コードを読むスキル 名前にこだわる 没頭することも大事 フロー状態を大事にする Exceptionが上がっているのはエラーだからです エラーを無視しない 本当に求めているものはそれですか？ 顧客の言葉はそのまま受け入れない 言語?イディオム?テクニックを学ぶ テストがあれば怖くない よりよい構造 変更を恐れない 自分が扱ったコードは元のコードよりも良くする 一人だけで創っているわけではない 他の人と協調する 保守しやすいコード わかりやすいコード とりあえず動かそうというコードは書かない 良いコード コードを見る人のためにテストを書く データ構造とか 他社への思いやりを考慮したコーディング 一人より二人 テストのないソフトウェア開発はありえない コード分析ツール コスト意識 面倒でも自動化できるものは自動化する Riak MongDB NoSQL Oracle SQLite PostgreSQL データベース ３つのスキル 自動化ビルド Webアプリプログラミング スレッドプログラミング その場しのぎをしない 精度見積もり 限界を知る Ant Maven YAGNI原則 かも知れないは要らないもの 余計なコードを書かない タスクトラッカ レビューの仕組みとSCMと連携したい バグレポート ITS 定時に帰れるような仕組み?やり方を考える 徹夜?休日出勤しない ハードワークは報われない エラーハンドリング etc ... QA １つの変更の理由は常にひとつでなければならないSRP（単一責任原則） OCP（開放?閉鎖原則） DRY原則 ステップ実行 C# Perl LISP Erlang 関数型言語 Python 言語 正規表現 プロトコル TCP/IP CSS HTML プロトコル Webの知識 SMTP?POP?IMAP ログ Servletコンテナ コマンド Apache Eclipseを知る ツールの知識 DIの知識 ClassLoader Linux ネットワークの基礎知識 Javaのツール VM Javaの知識 変更を恐れない 属人性の排除 手順化 自動化 省力化 デプロイ?リリース 技術だけではない 自分が学びたいものを発表?議論 チームのコード 学ぶソース Webサイト 書籍?雑誌 学び続ける姿勢 ノイズにならないように JavaDoc コードにかけないことのみコメントにする ブランチ、タグのルール コミットログ コメントの規約 カプセル化 正常系?異常系 境界値の考え方 知識（想像力）がいる 書き方 批判をしない コーディングにおける全員が守るべきガイドラインの確立 チーム全員に同じ知識を共有する クラス設計 デザインパターン メソッド分割の単位構造化 レビューの時の感謝の気持 ありがとうの気持ち 他人よりまず自分を疑う リファクタリング 開発効率 保守性 可読性 レビュー カバレッジ レビュー 見える化 制約をいれる 分散リポジトリ 見える化 書く 考え方 使い方 再発防止 原因追求 自動化 ドキュメント化 ツール実行自動化 単体テスト 規約にそっているか 重複がないか アンチパターンがないか ツール チェック コードを私物化しないように 対する意識 ルールに沿うようにガード 手を動かす どこまで必要か？ アルゴリズムとか どうやって手に入れるか 車輪の再発明しない commonsとか ライブラリの知識 実際にシステムを使うユーザについて お客様 他のメンバーとの協業 エディタ IDE ツール レイアウト スタイル バージョン管理 文章の書き方 ドキュメント 辞書ベースにしたい 変数 メソッド 命名規約 コーディング規約 知識を集約?拡散 プログラマとしての勉強法について ベースとなる知識 知識 障害対応 設計 制約 チーム デバッグ 作業 コーディング 規約 意識 プログラムを作る