@ledsun blog

Hのキーがhellで、Sのキーがslaveだ、と彼は思った。そしてYのキーがyouだ。

プログラマにできるとよさそうなこと

十行程度のプログラムが読めること

  • プログラミング言語の文法を知っている
  • 分岐とループを追いかけることができる
  • 変数の状態変化を追いかけることができる
  • 関数呼び出しを追いかけることができる
  • 十行程度のプログラムを複数回書いたことがある

プログラムを読んでプログラムの動的な振る舞いを想像できる

  • プログラムの主な処理の結果を想像できる
  • 主な処理の終了条件がわかる
  • プログラムから主な処理を読み取れる
  • 似たようなプログラムを書いて、動かしたことがある
  • 既知のプログラムと読んでいるプログラムの違いがわかる
  • イディオムを知っている
  • イディオムを書いたことがある
  • プログラムがどう動くか知っている

重複したソースコードを関数に抽出できる

  • 重複したソースコードがわかる
  • 同じ入力と出力をもつコードブロックがわかる
  • コードブロック単位で入出力を比較できる

プログラムのある機能がソースコードのどの部分に依存しているか読み取れる

  • 機能の表示する情報が、プログラムのどこで管理されているかわかる
  • プログラムで管理している状態が、いつ初期化され、いつ変更されるのかわかる
  • 状態が、プログラム上のどこから変更されるのかわかる
  • ユーザ操作によって呼び出される関数が、ソースコードのどこにあるかわかる
  • 関数呼び出しが追える
  • 関数呼び出しが、複数の関数、モジュールを跨いでも見失わない
  • コールグラフの途中経過を抽象化できる
  • プログラム中のモジュールの大まかな役割分担を知っている
  • モジュール分割したプログラムを書いたことがある

バグの原因を特定できる

  • バグが起きた理由を説明できる
  • バグの原因を知っている
  • バグが起きない状態が作れる
  • バグが起きる状態が作れる
  • バグの再現方法を知っている
  • バグが起きる方法を試したことがある
  • バグが起きる方法が思いつく
  • プログラムのモジュール構成を知っている

ソースコードから書いた人の気持をエスパーできる

  • コメントや関数名、変数に惑わされずに、処理内容を追うことができる
  • 似たような失敗をしたソースコード書いた経験がある

作法にのっとって機能を実装できる

  • 特定のフレームワーク、ライブラリ、ツールをの使い方のどう変えれば、何が変わるかわかる
  • ツールに慣れ親しんでいる
  • ツールを使ったことがある
  • ツールを使ったプログラム書いて、その動きを試すことができる
  • ツールの使い方を調べることができる
  • ツールの名前を知っている

動くけど使いにくいプログラムを改善できる

  • UIを改善ができる
  • よいUIと悪いUIがわかる
  • よいUIを知っている
  • よいUIがどういうときによいUIか知っている
  • ユーザがプログラムを使う文脈を想像できる
  • ユーザがプログラムを使う文脈を知っている
  • ユーザになったつもりで、プログラムを動かすことができる

動くけど問題を解決していないプログラムを改善できる

  • 機能仕様のバグを検出できる
  • 問題を解決する機能を考案できる
  • ユーザがプログラムを使って解決したい問題を知っている
  • ユーザの抱えている問題を知っている
  • ユーザの立場を知っている

リファクタリングができる

  • モジュールの影響範囲のいびつさがわかる
  • モジュールの影響範囲のあるべき姿がイメージできる
  • モジュールの影響範囲のあるべきパターンを知っている
  • モジュールを実装したことがある

たくさんリファクタリングできる

大きなリファクタリングができる

自分の書いていないソースコードの重複を発見できる

  • 他人の修正を見ることができる
  • 他人の作業と自分の作業の関わりがあるか判断できる
  • 他人の作業目的から自分がやっていることと似たことをしていると想像できる
  • 機能からソースコードやモジュール構成をイメージできる

レールから外れたプログラムの設計ができる

チーム開発で気をつけていること

この日記は同僚が読んでいないことを前提に書いています。もし読んでしまった同僚の方は絶対に感想を伝えないでください。

日に二度のオンラインミーティング

4月に在宅勤務が始まって以降、一日2回zoomを使って開発チームでオンラインミーティングをしています。 そこではチームメンバーが担当するタスクを話しています。

いわゆる朝会に近いです。 ただし、時間を区切った朝会と違い、目指す仕様や実装方法に疑問があるときはその場で相談しています。 ですので、一回のミーティング時間は15分〜1時間半までバラツキがあります。

その間、相談してないメンバーもミーティングに参加しています。 これが良いのか悪いのかは判断がついていません。 よくある朝会の手引では、「会は一定時間で打ち切り、個別の相談事はあとで行う」を勧めていると思います。 反しています。 3人チームなので、無駄にする時間がx1でレバレッジが効いていないので、そのままにしています。 人数が増えたら、考えるかもしれません。

オンラインミーティングは、退席すると「どんなことを話しているのか」わからなくなることを懸念しています。 オンサイトであれば、会議に参加していなくても、「ずいぶん長いこと話しているな」レベルのフィードバックが得られます。 オンラインでは何もわかりません。結論をチャットで共有してもいいのですが、それはそれで手間です。

「チームでお仕事をしている感」の演出になればと思っています。 チームメンバー間で、勝手にオンラインミーティングで相談し合うなら気にしなくてもいいのかもしれません。 それはそれで、問題が速く解決する方法なのか、という問題があるかもしれません。

日に二回のオンラインミーティングで、詰まっている点を確認して都度解決しています。 質問で割り込まれることはほとんどありません。 在宅勤務作法の教育上は、よくないかもしれません。 いまのところは、そこまで先は考えていません。

オンラインミーティングで決めていること

オンラインミーティング中に、次のことを決めています。

  1. おおまかな実装方針
  2. MergeRequest(いまGitlabを使っています)を作成するまでの目標タイム
  3. 画面の見た目

目標タイム

タスクのざっくりした実装方針を決めています。 が、大抵は仕様を見落としています。

最近、大きすぎるタスクを振って、大きなMergeRequestをレビューするはめになりました。 自業自得です。 一番の要因は、仕様を見落としていました。 大きなタスクであることに気がつかなかったのです。

目標タイムを設定するようにしました。 原則、当日中にMergeRequestを出せるようにタスクを調整します。 ちょっと無理そうな場合は、なるべくタスクを分割します。 ストーリーの単位より小さくわけます。 例えば、編集画面が大きすぎれば「編集画面に現在値を表示するまで」と「値を更新する処理」にわけます。

見た目

新規の画面では、見た目を相談することもあります。 オンラインミーティングで画面共有して確認しています。 あるいはスクリーンショットをとって、加工してコミュニケーションを取ることもあります。

話していないこと

逆に話していないのは、ソースコードの細かい実装方針です。 既存コードの追い方がわからない場合は、一緒に見ています。 既存コードの真似して書ける部分は、コピペでもよく、動作が機能を満たしていれば良いです。

ソースコードの細かい指摘は、MergeRequestのレビューで行っています。 共通関数の抽出やスタイルの修正などは、全部MergeRequestで行います。 なるべく理由は説明して指摘するようにしています。

言葉で伝わらなさそうなときは、コメントにソースコードを書きます。 この辺はスラスラ、プログラミングできるスキルがあってよかったと思います。

最初に「動作する」に取り組み、その後で「きれいな」に取り組む

動作するきれいなコード: SeleniumConf Tokyo 2019 基調講演文字起こし+α - t-wadaのブログ

動作確認

機能を動かしてからわかる、妙な動作は、マージ後に確認しています。 1つの開発ブランチに対してチームで開発しています。 開発ブランチですので、ストーリー単位までいく前にどんどんマージします。 マージした開発ブランチを、手元のPCで動かして、意地悪なテストをします。

明確な不具合を見つけたらIssueを作成します。 動かしながら、仕様の理解を深めて、仕様の矛盾点がないか探り出します。 疑問点を洗い出したり、仕様を確認する作業までは一人でやっています。

最終的な決定は、オンラインミーティングで誰かと喋りながらのほうが決めやすい気がします。

スケジュール管理

単純な線形予測では、微妙に遅れています。 見積もりの不確実性コーンをぶっちぎる程は遅れていないので、気にしないようにしています。 内心ビビってますが「教育の投資効果で取り戻せるはず」と、自分に言い聞かせています。 焦ってした雑な仕事が、あとで自分の首をしめるのは目に見えています。