小さいうちに少し分けておくと、後で仕事が楽になる
小さいコードに、いきなり厳密な多階層構成は要らないかもしれません。けれど、小さいうちから役割分離の考え方を持っておくことには意味があります。入口、設定、入出力、ロジック。この区切りを少し意識するだけで、後から育てる余地が生まれます。
Python プロジェクトの構成とは、ファイル整理ではなく、仕事を継続できる形にすることです。保守、分担、再利用、引き継ぎ。そのどれもが、どこに何があるかと無関係ではいられません。
完璧な形を最初から当てる必要はありません。ただ、どこに何を書くかを意識しないまま増やしていくと、後で苦しくなります。構成はコードのためというより、仕事を壊さないために必要なのだと思います。
結局おれは、「計算を正しく組むこと」には意識が向いとったけど、「人が途中から入っても回るようにすること」までは、あまり考え切れてなかったかもしれんばい。
それはすごく自然だよ。作る人は、どうしても「まず解く」に集中するからね。でも仕事になると、解けることと、引き継げることと、安心して直せることが、同じくらい大事になってくるの。
たしかに、後輩や他部署の人に見せると、毎回おれが横に付いて説明しとる気がするたい。それって、コードが共有できとらんということやね。
うん。しかもその状態って、ストークが頑張るほど属人化しやすいんだよ。優秀な人ほど、説明で埋めてしまえるから、構造の問題が表に出にくいの。
それは耳が痛か……。自分が分かっとるから回っとるだけで、他の人からすると入口が見えんままやったかもしれん。
だから構成が効くんだよ。どこが入口で、どこが設定で、どこがロジックで、どこが入出力か。それが見えるだけで、「この人はここを見ればいい」が生まれるの。巻き込みやすさって、説明力だけじゃなくて、構造でも作れるんだよ。
なるほどたい。構成って、きれい好きのための話やなくて、「人に渡せる形にする」ための準備なんやね。
そうそう。最初から豪華にしなくていいけど、「誰かが次に入ってこられる余白」は作っておきたいのよ。
じゃあ次からは、「動くか」だけやなくて、「人が入れるか」も見るようにするばい。
うん。それができると、コードが個人技から仕事の基盤に変わっていくよ。