レガシーコードからの脱却 5章プラクティス1 やり方より先に目的，理由誰のためかを考える
5章プラクティス1 やり方より先に目的，理由誰のためかを考える
要求の妥当性を検証するのに決まった形はない． 顧客がアナリストに伝え，アナリストがドキュメントにし，開発者がそれを読みながらコードに落とし込む． まるで伝言ゲームで，会社区の仕方も千差万別だ．
顧客と顧客サービスマネージャーは開発者に具体的なやり方を伝えるという考え方を避ける必要がある． ソフトウェアの作り方というのは，作ったことのない人にとってはまったく想像つかないものだ．
開発チームはやり方にまえふれられると，命令のようにとらえてしまう． 一歩離れて問題を眺め，どのように実現するかを考えることなく手続き的なコードになってしまう恐れがある． ソフトウェア開発者として，プロダクトオーナーと顧客が何を欲しいのか，なぜ欲しいのか，誰のためのものなのかを知りたい．どうやってやるかは教えてほしくない． 大事なのは，ほかにさまざまな作り方がある中で，なぜそのやり方を選んだ，そのトレードオフ を開発者が理解しているかどうか．
過去に著者が取り組んだ素晴らしいソフトウェア開発プロジェクトには，例外なくプロダクトオーナーがいた．顧客ともっとも頻繁に連絡を取り，プロダクトが本来どうあるべきか一番よく理解している人間．プロダクトオーナーが技術系の人でないほうがうまく行く傾向で，プロダクトがどういうものか細部まで詳しい知識を持っている，つまり，その領域に本当に精通している人． これが次に作る一番重要な機能だと言える人．必要なのはユーザーの糸を伝えていくことであって，些細なこと，細かいこと，政治的なことにとらわれることではない．
仕様書もなく作業をするという考え方は一部の開発者を興奮させる．要求が出揃う前にソフトウェアのコードを書くように開発者に依頼するのは，彼らが何をしたらよいかわかっていないうちは非効率で無謀．しかし開発者はすべての要求が出ずとも順次追加することで，開発を始められる．品質を向上させながら効率的に行うことが可能．
辛うじて十分なドキュメンテーションがあればよく，ソフトウェア開発はコーディングが全てだということを忘れて，仕様書や設計の作成に時間をかけているチームが多い． これをやると，残るのはコードどころかまとまりがなくバラバラのドキュメントになる． そうではなく，コード自体にすべての知識をまとめるべき．開発プロセスを円滑にするのは会話．
辛うじて十分なドキュメンテーションから着手すれば，何か機能を作り始める前に，チームが知っておくべきことがいくつか出てくる．段階的な要素から着手する前にプロダクトオーナーは以下のことをわかっている必要がある．
- 受け入れ基準とはどんなものか 受け入れ基準やコーナーケースをストーリーカードにさっとメモしておいて，どんな例外を扱わないといけないのか思い出すようにすると良い．
- 開発者と議論するためにはどのくらいの詳細さが必要とされるか
プロダクトオーナーのための7つの戦略
- SMEになる テーマごとの専門家(SME)でなければならない． そして，プロダクトのあるべき姿を深く理解していなければいけない． また，システムを作るよりも前に全員が理解できるようシステムを視覚化し，例示してみれることに時間を割くべき．
- 開発を発見のために利用する 開発の家庭においてより良い解決方法を発見するために広い心を持ち続けなけばいけない． 反復型開発にはフィードバックの機会が多い． 開発が正しい方向に向かっていることを確認すべきである．
- なぜ誰のために，を開発者が理解できるようにする
- どうやって手に入れるかではなく，何が欲しいのかを説明する 仕様書やユースケースよりも，何を作るかに集中する．
- 質問にすばやく答える ストーリーはプロダクトオーナーと開発者の会話の出発点となるようにできている． プロダクトオーナーが捕まらない時は，開発のスピードが落ち，開発者は結局あとで間違っていたことがわかるようなことを推測しないといけなくなる．
- 依存性を取りのぞく ほかのチームと協力することで，依存性が誰かをかかりきりにしないようにする．
- リファクタリングを後押しする
よりよいストーリーを書くための7つの戦略
- プレースホルダーとしてみる スプリントプランニングや今後の議論に持ち込みたいと思う話の本筋をつかむためにストーリーを活用する．
- 目的に注目する 開発者が機能の目的，どのように利用されるかについて理解するべき． 擬人化を使うとユーザーのニーズやシナリオを理解しやすい．
- なぜ機能が必要とされてか知る
- シンプルに始めて追加はあとで行う
- エッジケースを考える エッジケースはストーリーカードの裏に書留，記録をつけておく．そして後でテストを書いて実装を駆動する．
- 受け入れ基準を利用する SpecFlow,FIT,Cucumerといった受け入れテストツールを使うかストーリーカードに下記示すかしてテストとして表すのがよい．
www.slideshare.net
はてなブログでの数式入力
キーワード VScode, latex, equation 数式
はてなブログでは，MathJaxでlatex形式の数式を変換しているらしい．
普段使用しているVSCodeからはてなブロブ形式に変換する方法を調査した． 良い方法が見つかった．
文字列置換ではてなブログのフォーマットにする
方法としては，VSCodeの拡張機能であるReplace Rulesを使用するというもの． 決められたルールで文字列置換が可能．
コマンドパレット（Ctrl+shit+p）からPreferences: Open User SettingsにあるReplace Rulesからsetting.jsonで編集する． 追加するのは下記コード．
下記
"replacerules.rules": {
"はてな式 (MathJax) inline" : {
"find": "\\$(.+?)\\$",
"replace": "[tex:$1]"
},
"はてな式 (MathJax) center" : {
"find": "\\$\\$([\\s\\S]+?)\\$\\$",
"replace": "<div align=\"center\">[tex:{$1}]</div>"
}
},
お試し結果
インラインもいける．
どうもありがとうございました．
PBR: Physically based rendering
keywords PBR, CG, ray tracer, rendering
Link
- Document
- Renerer
Initialize git
Initialize git
keyword git, linux, install
Install
sudo apt-get update sudo apt-get install git git --version
set config
git config —global user.name <user name> git config —global user.email <mail address>
To confirm:
git config --global --list
Create repository
git init # initialize git add . git status cit commit -m "Fiest commit"
To resister repository:
git remote add origin <URL> git remote -v git push origin master
add SSH
Error
git push origin master Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Create key
$ ssh-keygen -t rsa -C mail@mail.com Enter file in which to save the key (/home/xxx/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again:
Copy and paste key
ls ~/.ssh/ id_rsa id_rsa.pub
Access github and go to settings -> SSH and GPG keys
set config
vim ~/.ssh/config Host github HostName github.com IdentityFile ~/.ssh/id_rsa User git
Check connection
ssh -T git@github.com Hi xxxxxxxxx! You've successfully authenticated, but GitHub does not provide shell access.
