ソフトウェア開発で学んだが使わなかったもの
開発手法など、一通り学んだが実際に使っていないものは多少なりあると思う。それらについて掘り起こしてみたい。 スクラム開発認定スクラムマスター研修には研修会場ホストという立場で数回立ち会った。認定外の研修も幾つか受講した記憶がある。書籍もそれなりに読み、Scrum Gathering Tokyoなどのコミュニティにも顔を出し、まあそれなりに色々考えて捉えてきた。でも、自分のチームでは使っていない。スクラム開発というアイデアに矛盾があるからだ。 そもそもスクラム開発ではチームの自律的な行動を良しとしており、それに対する”フレームワーク”を提供しているということになっている。イテレーション、バックログ、ふりかえり、デイリーミーティング（いまだに「朝会」って言ってる人いないよね？）、そしてそれらのお作法。誰が言ったかわからないが、それぞれの作者の意図を察するためには「守」が大事らしい。守破離の「守
Hello Worldの後に何を作るか - razokulover publog
新しい技術を学びはじめるとHello Worldのその先で何を作るか詰まってしまうことがよくある。 最初から作りたいものがある人はそれ作ったほうがいいし、実務で導入できたりするなら一番手軽で学びが多いのだが中々そうもいかないのが人生というもの。 そういう人にとってはHello Worldからある程度使えるもしくは本番投入時に選択肢にできるレベルになるための道筋があると便利だなーと思う。 自分はWeb系の人間なのでフロントエンド/サーバーサイド/モバイルアプリという感じでまとめてるが、インフラ屋やハード他デザイン系の技術はまた違うと思われるのでこれはあくまでも自分の場合はということで。 共通 言語機能を一通り試す(A Tour of Goみたいな感じで) 基本的な型/制御構造/IO周り/クラス/文字列操作/正規表現/よく使いそうな標準ライブラリ その言語固有の機能は重点的に(goだったらgo
最近コード中のTODOコメントの書き方を工夫している - $shibayu36->blog;
コード中に後でやろうと思って以下の様なTODOコメントを書くことがあります。TODOコメントというのは # TODO: 後でリファクタリングしたい ... # TODO: 投稿機能ができたら置き換えること ... みたいなやつです。 コード中にTODOコメントを気軽に書いてしまいがちですが、よくTODOコメントが放置されて気づいたらプロジェクト中に大量のTODOコメントが書かれたりすることがあります。直せる量を超えてくると、直すモチベーションも下がってきて、結局ただのコメントと同じ状態になります。 最近いろいろ工夫して、TODOコメントの書き方を変えたところ、そこそこうまく回ったのでメモしておきます。 TODOコメントの問題点 問題点として次のものがあると考えました。 (1) 書く人によって形式がバラバラ TODO, XXX, FIXMEなどバラバラだったりする (2) TODOコメントの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
