失敗する書き直し、成功する書き直し / karino2 - Message Passing
全体的な事を言えば、自分は書き直し反対派と思う。 morritaさんの言う20年前の意見をほぼそのまま現代まで持っている。 頭の硬い古い老人という事だろう。 そういう訳で、そんな古い側の人間が書き直しについてどんな事を思っているのかを書いてみたい。 失敗するケースは割と限定されている ソフトウェアの書き直しには、成功するものと失敗するものがある。 失敗する条件を厳密に挙げるのは難しいけれど、失敗する書き直しは、自分は見れば分かる、と思っている（本当に分かるかは議論の余地があるけれど）。 まずshinhさんの言っている半分素人が挑戦するケースは良く見かける。これはまぁいい。全然良く無いけれど。 それ以外で良く失敗するのは、ある程度の規模、だいたい10万行以上のソフトウェアで、 その時点で多くのユーザーを持っていて、 書き直しにかなりの時間と人がかかる奴が多いと思う。 そしてデスクトップ、iO
Design Docs のいけすかなさ / morrita - Message Passing
Design docs というのが昔からあまり好きでない。読むのも書くのも好きでない。 仕事で文書を書くのはやぶさかではないけど Design docs はなんとなくいや。 せっかくなのでこのイヤさを言語化してみたい。 Design Docs とはなにか 自分が想定している Design docs は この文章が説明しているようなものだ。 なにかそれなりの規模があるものを作る時に設計やそのトレードオフをざっと文書化する文書。 もっというと一般名詞の design docs ではなく、リンク先に書いてあるような自分の勤務先固有の The Design Docs 文化が好きでない。 「設計やそのトレードオフをざっと文書化する。」 それだけ聞くと割と良いもののような気がして、自分もある時期までは良いものだと思っていた。 「ドキュメンテーション」というのは、プログラミングのポップカルチャーにおいて
モノレポのはなし / karino2 - Message Passing
モノレポについて経験豊富そうな皆さんの話を聞きたい。 まずはその背景から。 会社で分かれるレポジトリ フリーランスをやっていると、たまにいろんな零細企業を集めて一つのサービスを作る場に遭遇する。 人を集める時に、一つの会社だけじゃなくて複数の会社が集まることがよくある。 たとえばマーケティングが強みの会社が自社ではエンジニアを持っていなくて、開発は外部の人たちを集めてやるみたいな。 しかもそれぞれの会社からは一人とか二人だけしか来ないので、 6人の小規模なチームなのに会社は4つあるとかいう状況になったりもする。 そうすると何が起こるかというと、レポジトリが会社ごとに分かれたりする。 「クラウドとフロントの間はAPIを決めましょう、 それでクラウド側がバイナリをリリースして、フロント側がたまにそれをマージしましょう」みたいなフローになる。フロントとバックエンドなんて関わっているのは3人しか居
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
