私がシステムエンジニアをやっていてなんとなくわかったことがあったので未来の自分のためにメモしておく。
まだまだわからないことだらけだが、今のわかり具合を言語化するというのは大切だと思うの。
あくまでも独断と偏見でメモっているだけですよ。
プログラミング言語はただの目的を達成するための道具で大切なのは仕様理解
これ真理。
仕様の理解度でプロジェクト内での信頼度が大幅に変わります。
プロジェクト内での発言力が増します。
クソコード量産しないためにもプログラミングのお作法は大切ですが、要求された仕様の通りにプロダクトが作られていなかったら元も子もないのです。
しかし仕様に寄せようとする精神が強すぎてとりあえず納期守りましたみたいなプロダクトが結構ありました。
そして運用で死ぬ運命になるサービスをいくつもみてきました。
仕様通りかつ運用がしやすいことがベストなのですがなかなかうまく行かないのです。
なぜなのか。わからん。
適度な雑談は必須
上の仕様理解につながる話です。
私は雑談のついでに仕様でわからないことなどを上司などにフランクに聞いたりしていました。
私はもともと雑談をするのが好きだったので最初は必須だとは思っていませんでした。
どこで雑談が必須だなと思ったのかというと、あるプロジェクトで無言でプログラミングをしている人がいたのです。
毎回ぴったり定時で退社していてめちゃくちゃ出来る人かと思っていました。
しかし期限日にほぼ全ての仕様が的外れな実装をしていることが判明していたのです。
プロジェクトチーム全員に迷惑がかかりますよね。
それを放置したチームにも責任は当然あります。
その人曰くチームメンバーには相談しづらい雰囲気だったそうです。
相談しやすい雰囲気はプロジェクトを円滑にすることがわかりました。
雑談の出来るチームの文化を作ることが認識の齟齬を産まない大切な一歩だと感じました。
ジャンルにもよりますがIT業界を人と話さなくても良い職業だと思っている人はこの業界はやめたほうがよいですよ。
話すのが辛いならチャットでもいいじゃない。
性能が悪いプロダクトはだいたいなんちゃってプログラマが多いからなのだと思う
なになにの言語ができますと言っている人でフレームワークや言語の中で何が起こっているのか理解していない人が割といます。
何も考えずにとりあえず仕様通りの実装をすると負荷テストで無事に死にます。
あとシステムフローを理解していない人が実装していると同じ処理を何回もしている箇所がいくつもあります。
セールスフォース案件のガバナ制限で泣きそうになりながらリファクタリングしたのが懐かしいです。
このあたりは仕様理解の話ですね。
言語で何が起こっているかとか細かいところまではわからん。
文系四大卒でもどうにかなるという最終幻想
よくある簡単なアプリや業務系のプロダクトなどを開発するまではどうにかなります。
なぜエラーになって、なぜそうすれば治るのかと追求しているブログは少ない(このブログ含め)ですが、エラーになってもだいたいブログに書いてある情報で治ります。
そう問題解決から仕様の実現まではどうにかなります。
ただしかなり努力しないとどうにもならないことがあります。
それは今流行りのディープラーニングやニューラルネットワークなどの機械学習系がやりたくても辛いのです。
結局数学的考えや統計が生きてくるのです。
私は機械学習を一からやっていますがわからんのです。
それと物理演算とかそういうのも辛い。
なので算数を一から始めようかなと思っている次第です。
わからん。
タバコ部屋での会話の重要性
私はタバコを吸いません。
しかしたまにタバコ部屋にいることがあります。
タバコ部屋では気持ちがリラックスしているのかスモーカーからぶっちゃけた話が聞けます。
スーパーどうでもいい話からオフィスでは聞けない話まで幅広くです。
スーパーどうでもいい話の割合の方が圧倒的に高いです。
そうそう、知っていましたか？タバコはやめたほうが健康に良いそうですよ。
英語の重要性
なぜ日本人は英語を最低６年はやっているのに理解できないのか。
と議論するつもりはありません。
私は英語ができません。(厳密には嫌厭しているだけです)
何かしらのライブラリやフレームワークを使用する際に使用方法が書いてあるブログを見ます。
だいたいの使用方法は書いてあります。
もちろん書いていないこともあります。
そしてブログでは大切なことが抜けていることがよくあります。
例えば推奨はしていないメソッドですよとか性能面であまり良くないよとか。
実際の英語のドキュメント読まないと痛い目を見ることがよくありました。
そのために英語は重要なのです。
英語わからん。
昼寝はした方が良い
私は昼寝をしたほうが効率よく午後の仕事ができているような気がします。
お昼の雑談はもっとも大切な時間の一つですが、昼寝の時間も考慮しておいたほうが良いですね。
ちなみにスペインでは昼寝が当たり前のようです。
プログラマーは管理職の給料を超えられないという幻想水滸伝
ピンキリですが超えられると思います。
いつまでも超えられない会社にいると超えられないです。
そして給料に目が行ってしまうとやりたいことができなくなってしまうのでバランスが必要だということ。
そして会社をやめてもすぐに死にはしないということ。
流行り廃りは早い
システムエンジニアに限らずどの業界でも流行りの勉強はするべきだと思います。
1年立つだけでかなりレガシーな記憶になってしまいその記憶では太刀打ちできなくなっています。
特にフロントエンドはえぐい。
日々勉強は辛いですよね。
何もしないよりは技術者のツイートを見るだけでも良いと思います。
ただし技術者のツイートはだいたいアイドルかアニメかネコなのでほぼ参考にならないこともありますが癒されます。
雑談が必須なのはこの辺でも言えます。
技術者が技術系のツイートだけをしていると飽きてしまってツイートをやめてしまうと思います。
これと同じで私がこのブログでなんでも書いているのはやめないためです。
ブログをやり始めてから前より自宅でプログラミングをするようになりました。
何がいいたいのかわからなくなりました。
コードをレビューしてもらう大切さ
自分自身のコードが正しいと思い込んで書き続けるのはよくなかったです。
謎の流派になってしまって誰が見てもおかしなコードにならないためにもレビューをしてもらいましょう。
これも運用がしづらい設計になる要因ですね。
あとプロダクトの属人化を防ぐためにも仕様とソースコードの認識合わせは大切でした。
レビューしておけば誰かがプロジェクトから抜けたとしてもすぐにフォローできるのでグッドです。
ここでちょっと一息
経歴だけ長いおじさんの特徴まとめ
- 昼休みに昼寝しないで午後の勤務時間に昼寝してる。(スペイン人かな)
- 色々理解しないで開発しているが完成はしている。(運用が面倒)
- プログラミングは仕事でしかしない。
- 技術書とか読まない。
- 「理解しました。」←してない。
- 「間に合います！」←間に合わない。リスケもしない。
- 開発ブログだけ参考にして開発している。
- コードレビューが一瞬で終わる。
対策
定期的にできているか聞いてみる。
そして今何をしているのかを説明してもらう。
三ヶ月後は他人
自分自身が開発した後にすぐに読み返すと意味がわかりますよね。
しかし数ヶ月立った時にそのソースコードを読んでみてください。
このクソコード書いたやつは誰だッ！！となっていたらそれは勉強不足です。
他人(いつかの自分)が見てもわかりやすいように書いておきましょう。(自戒を込めて)
なるべくコメントを書かなくてもわかるようにガンバらないといけないです。
出来る人は勉強会に行っている
勉強会に行かない出来る人もいる
本当にこれ。
勉強会に行かない出来る人に話を聞いたら、勉強会に行っている時間で技術書読んでいるほうが言語理解が深まるだそうです。
勉強会ってそれのためだけでもないと思いますけどね！
無理をしない
システムエンジニアは健康な体が一番の資本です。
体を壊したら大変です。
健康に働くために無理をしてはいけないのです。
残業時間の多さで自慢してはいけないのです。
寝てないアピールをしてはいけないのです。
働きまくったことを武勇伝にしてはいけないのです。
私は睡眠をとったほうが効率よく仕事ができている気がします。私は。
その日のタスクが終わったらさっさと帰るのが一番です。
明日で良いことは明日しましょう。
技術書を読まなくてもどうにかなる
どうにかなります。
ただし性能の話のところで出てきましたが負荷テストで死にます。
何をすると早いのか遅いのかくらいは覚えておいて損はしません。
私はパラパラでしたが見ておいたほうが効率よく開発ができたのでよかったと思います。
あとは技術書を読みたくないのならチュートリアルは最低やったほうが良いです。
いかに敷居を低くして自分のやる気を出すかが重要だと思いました。
もちろん技術書を読んだほうが運用のしやすいかつ性能が良いプロダクトができます。
なぜか徹夜すると間に合う
これは七不思議ですね。
スケジュール通りに頑張ったので間に合ってはいるのですが、それは間に合ったと言えるのでしょうか？？
設計思想が大切
世の中にはいろんな設計思想というものがあります。
言語も大切ですがこの設計思想が結構大切です。
Ruby on RailsではDRY(同じことを繰り返さない)とか規約重視とかあるわけで、設計思想の共通認識がある前提でそれにしたがって書いておくとチームでスムーズな開発ができます。
そして責務とかなんとかで揉めにくくなるわけですね。
文系はオブジェクトの気持ちになって考えろですね。
正直オブジェクト指向とか関数型プログラミングとかDDDとかよくわからん。
オブジェクト指向と10年戦ってわかったこと
関数型プログラミングはまず考え方から理解しよう
ドメイン駆動設計の用語と解説(抜粋版)
正規表現とSQLはどこでも通じる
正規表現はどの現場でも使用していました。
正規表現エンジンは違えど大まかな表現は同じなので覚えておくとかなり重宝します。
例えば「指定文字列が存在する行以外を抽出」ができると仕事の効率が上がります。
ちなみに上記例題の場合は私はこんな感じにやっています。
^(?!.*指定文字列).*\r\n
正規表現の検定とかあればいいのに。
それとセールスフォース以外の開発では、SQLは必ず使用していました。
SQLを理解していると最初にSELECT文書いてからロジックに落とし込んだほうが早かったりします。
性能の観点からもSQLはとても大切な位置にいました。
なんだかNoSQLとかいうのも出てきてるけど今は気にしない。
給料130万円以上の人はプログラミング言語を一から書けるレベルらしい
風の噂で聞いた話。
強すぎ。
あとがき
何がわかったかというとわからないことがわかったということ。
まだまだ足を踏み入れただけだったという罠。
わからないことがわかったので少しづつ学びたいです。
スポンサードリンク