TW Day2 13:15〜 "The Software Engineering Part of Data Science"

一言でいうと

Software Engineer(以降SEと略す)の立場からData Scientist(以降DSと略す)のコードの扱いについて知見を共有したトーク。コードの品質、設計、デプロイについてSEの視点から知見を共有

発表資料リンク

発表資料：[TODO: ここにリンクを入れる]
YouTube：[TODO: ここにリンクを入れる]
トーク詳細：https://tw.pycon.org/2019/en-us/events/talk/860258210542518501/

発表者/所属

Niño R. Eclarin

発表日付

2019/09/21

概要

SEとDS

状況：DSの作ったnotebookがSEのもとに届く

code quality
maintainability
（アプリにしたら限定されないデータを扱う）
documentationが重要

model accuracy
visualization
モデル作成で扱うデータは限定的

PythonはSEとDSとの間で共通で使われている

Solutions

Data Driven Development

データの入力（Analyze部分、どんなデータか）
出力（パイプライン）
データがどのように変換されるか

1. Code standards

linter & automatic formatter
functionを使う
Type hint（object）

Error handling カスタムのExceptionクラスを定義する

Data Integrity

in & out どんなデータが入って、どんなデータが出るのか TrainingDataクラス（←metadataというプロパティは便利かも）
粒度生のデータなのか、加工したデータ（白黒画像）なのか

2. アーキテクチャ

マルチスレッド決定木のようなmemory bound algorithms向き実装しやすい

マルチプロセス NNのようなCPU消費量の大きいアルゴリズムに適する実装は少し難しい

SEがDSのコードのglue codeを作るインターフェイス、クラス化 class ModelInterface(ABC) これを継承してMyMedelクラス（RandomForestClassifier().fitを返すなど）

3. デプロイ

メモリやCPUの使用量が大きければクラウドで動かす

CI（自動テスト）

[以下はオプション]

新規性・差分

トークで知って試したいこと

dataclass（自分がハンズオンやるときなどは型ヒントなどSEから見ても理想的なコードに近づけたい）
ThreadPoolExecuter

感想

このトークにおけるSEとDSの業務範囲の分け方はHacarusの個別事例だと思うので言いすぎな箇所もあるという印象。 jupyter-blackを入れてコーディングしているDSもいるだろうし、そもそもDSという肩書の業務範囲が勤め先によると思われる（勤め先ではこの話のDS+SEの範囲を指してDSと言っているため）ジェシーさんのResearch oriented codeという言い回しの方がスキマが残るので好み（SEもResearch oriented codeを書ける）

自分がこのトピックを扱うなら、DS向けに「後工程に向けて気をつけたいこと」として共有する（ジェシーさんのトークに近い） PythonについてDSはSEほど理解していない。DSにSEと同じだけ理解させるよりも、手を取り合うほうが好み

ftnext / PyConTalkSummary