エンジニアリング のバックアップ(No.9)

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• エンジニアリング へ行く。
  • 1 (2014-03-29 (土) 07:06:43)
  • 2 (2015-07-04 (土) 21:00:34)
  • 3 (2016-08-25 (木) 10:30:40)
  • 4 (2017-01-16 (月) 11:14:38)
  • 5 (2017-07-24 (月) 15:40:47)
  • 6 (2017-12-06 (水) 21:47:11)
  • 7 (2018-04-14 (土) 14:27:36)
  • 8 (2018-06-11 (月) 12:45:24)
  • 9 (2018-12-18 (火) 13:46:52)

概要 †

• 最適化の反対はモジュール化。ギリギリモジュール性もギリギリ保て
• ずっと実装できれば幸せなのだろうけど、それってただの美味しいところを取ってるだけでは？？
• 技術力がなくなると芸人にならざるを得ない。技術にしがみつけ。

エンジニアリングの二つのスタイル †

• ドキュメントや仕様書を読んでからやる vs サンプルコードをコピペする
  • 仕様書の定義だけを読んで、「このメソッドがこのように使えるはずだ」とすると、仕様書がきちんと書かれたプロジェクトに関しては有限時間でエンジニアリングできる。しかもデバッグ可能な形で。
  • 困っている現象が合った場合、英語でググる
  • ググるの最たるものがサンプルコードエンジニアリング

まとめること †

• メカ・回路・制御のノウハウまとめ
• 試行回数を節約できる唯一の方法は熟練者を真似すること
• 設計、テスト容易性を甘く見る人は終盤死ぬ
  • プログラミングなら自動テスト
  • メカならアセンブリ可能性

• 外注だと違うかもだけど、プログラマって常に「どこまで汎用的にするべきで、どこまでは実行速度や開発速度を重視して汎用性を捨てるかを選択する」ってのを要求されると思っているし、サービスへの理解がない状態で書いたプログラムは、いくら仕様に沿っていても微妙なことが多いと思ってる。
• だから「プログラマは技術のことだけ分かっていれば良い」というのは無理があって、「このサービスはこういう理念だから、ここは変わらないけどここは拡張され得る」みたいなのをある程度把握したうえで設計・開発が出来ないとダメだよね、と結構思ってる。純粋な技術力だけで戦うのはなかなか難しい。