今日調べたこと
今更感ありますが、下記の用語を調べてみました
モバイバックホール（Mobile BackHaul）
モバイルバックホールは、ワイヤレスサービスのプロバイダにとって重要なインフラストラクチャ要素であると同時に、ファイバおよびインフラストラクチャのプロバイダにとっての主要な収益源です。 細分化された基地局を持つスモールセル基地局が標準的になるにつれて、大きな変化が見込まれています。 C-RANと5Gでは異なるネットワークトポロジが必要になります。 ベースステーションの分解により、バックバンド側に接続してバックボーンとMSCに到達する前に、ベースバンドユニット（BBU）が「BBUホテル」に移動され、そこで仮想ネットワーク機能（VNF）としてソフトウェアとして実行されます。
はい、意味不明でした
STM
STMはSynchronous Transfer Modeの略で直訳すると同期転送モードとなりまして、ATMは送受信側のタイミングを合わせない非同期転送でしたがSTMはデータの送受信にユーザがデータを送信できるタイムスロット(時間位置)が予め決まっている一定速度の通信です
はい意味不明
ATM
Asynchronous Transfer Mode の略で日本語では非同期転送モードとなります。
はい意味不明。とりあえず、STMのほうが新しいってことかい？？
イーサネット
イーサネットとは、ネットワークやコンピューター間での通信モデル TCP/IPプロトコルのネットワークインターフェース層に対応する有線の規格です。 イーサネット規格のひとつが、ローカルエリア・ネットワーク、LANで最も身近であるLANケーブルです。
噛み砕いてみたら、
LANのケーブルの線の本数とか色とか配置とか、そういうのが決まってるってこと？？
TCP／IP
TCP/IPとはTransmission Control Protocol/Internet Protocolの略で、インターネット上で様々なサービスを利用するための決まり事です。
まあインターネットでやり取りするときの約束事か。ってわかるかい！
まあわからんくても業務に差し支えないからええか！
時は飛んで３週目、今の所感
毎日書くのが大変で、週毎にしようと思います。。。
コードリーディングの毎日
現状はまだ要件が固まっていないこともあり、不完全な外部設計書に目を通しつつ、対応するソースを読むことが業務中の殆どの時間を費やしています。
なのでコードを全然書いていないんですね。
主にコードを読んで、処理を追っていってどういうロジック、実装パターンなのか、改修する場合に影響が及ぶコードはどこなのかを、エクセルなどに起こしてまとめて整理しているという感じです。
要件が固まる前に参画できたので、たっぷり時間はありますが、とはいえコードリーディングの目的も曖昧になりがちです。
目的なきコードリーディングはほんとに進まない。
また、そもそものシステムがどういう仕組なのかとか、業務用語などがほんとに理解位できない。仕様書を見ても結局理解出来ない。
先輩に質問したら「仕様書に書いてあるよ」って言われるけど、その仕様書がどこにあるか探すのにホント一苦労。
別の階層に同じ名前のファイルがあったり、そもそもサーバの場所も違ったり、バックアップでコピーして仕様書に変更を食わてたり。
だから結局無駄に存在しているファイルやフォルダが大量にある中で探さないといけないので大変。
というかそういう状況になっている時点で管理体制まずいでしょって思いますがどうなんでしょ。
GitじゃなくてSubversion
自分「Gitじゃないんですね」
先輩「Git使ったことないんだよね。でも今までSubversionの案件ばかりだったし、べつにGit使わなくても問題ないよ」
まあ私は未経験なので、どっちも実務で使ったことは無いですけど、でもSubversionってプルリクできないじゃん？
レビューどうすんの？
画面共有？席移動して？
ブランチはどうすんの？
コミットしたらマージされるって、コミット怖いんすけど？
ドキュメントが更新されていない
環境構築手順などはエディタやエクセルなどでおいてあったりするんですけど、それがもうバージョンが違って同じようには行かない。
変更点まとめみたいなのも、別の資料には反映されてるけど、こっちには反映されていないとか、いちいち中身を突き合わせてみないといけない。
ドキュメントが多すぎる
外部設計書と内部設計書を合わせると２００か３００個くらいファイルが存在している。どこに何が書いてあるかわからず、毎回迷子。
これって普通の量なんですかね？？
しかも階層めっちゃ深いし複雑やし。。。
迷子どころか、目隠し迷子やわほんま。頼むで。
資料の作成能力は身につきそう
おいら資料作成とかめっちゃ苦手なんやわ。
せやからある意味チャンスやなとは思っとります。
他人が書いたソースを解読する能力も上がると思うし、解読するときにどうやって書き出して整理したらええかっていうのも大事なことやしな。
資料作成は今までやったことなかった分、新鮮でええわ。
というところで、先週からの所感でした。
２週目 １日目
開発に関する資料に目を通した。
ところがどっこい。なんのこっちゃ理解できない。
びっくりだね。
もっとわかりやすい言葉で書けないものかね。
という感じの１日でした。
人によって書き方が違う
コードを読んでいても、「これは違う人が書いたコードだな」とわかるほどに、人によって書き方って違うんですね。
それは発見として良かった。
でも、やっぱり別の書き方で読むのに慣れて急に違う人のコードを読むと、「うぅっ。。。」ってなります。
急にわからなくなる。
まあまたすぐに慣れますけど。
改修案件はふるい技術を使うのでハチャメチャになっている
今やデータはDBで管理するのがデファクトスタンダードだと思いますが、今回の案件では、
を使って、それぞれからデータを引っ張ってきて集計するみたいな機能を作ってます。
故に、
などが混在しています。
バッチからVBAを起動したり、シェルからVBAを起動したり。
もうね、なにやってんの？？って感じ～
バッチもシェルもVBAマクロもそんな知らんし～
しかも初心者から見ても変な書き方してるなぁという部分が多々あった。
コメントって大事だなって話
処理の所々にコメントが書いてあるけど、結局わからんという始末。
「if文をネスト」って書いてあってもネストされてなかったり、そもそもif文の条件分岐の説明も書いてなかったり。
自分、もしくは同じ現場にずっといる人にしかわからないようなコメント。結局エンジニアは入れ替わりがあるから、初めての人にもわかりやすくコメントを残すのが重要だなと思いましたね。
疑問： ビルドツールってAnt？Mavenじゃないの？てか時代はGradleだと思ってたけど。。。
ってことで古い感じがぷんぷん。まあ基本となる、ベースとなる知識は変わらないだろうからいいんですけど。それでも古くなって非推奨になっている技術を使うのはいかがなものかと。。。。
ということで、ほんの少しだけど、コードが理解できてきてうれぴい１日でした
＼(^o^)／
５日目、６日目 コードリーディング
既存のコードを理解する時間でした。
基本的にエンジニアの仕事内容として、１から作って行くよりも、すでに動いているものの修正が多いので、どういう構成で成り立っているかを理解していないと修正箇所すらわからないということになる。
まずはクラスとメソッドをエクセルに書き出して、処理内容を日本語で書いてまとめていきました。
結局細かな処理は理解できないところもあったり、実装方法が理解できない部分があった。
特にインターフェイスと抽象クラスの使い方。
基本的に
```
定義
XxxService.java
実装
XxxServiceImpl.java（XxxService.javaをimplements）
```
となっていて、具体的な処理内容はXxxServiceImpleを見えれば書いてあると思ったらなかったり。。。
自分の認識のズレとしては
* クラス extends 抽象クラス implements インターフェイスで、インターフェイスの実装はクラスじゃなくて抽象クラスで実装されている
って部分ですね。
あとはEclipseで検索かけてひたすら見つけてはエクセルに書き出して説明を書き足していく作業で２日終わりました。
理解するのに時間がかかるので、２日かけても対して進んでいません。。。。
3日目 、４日目 赤字を黒字にする
またかよ。
まあまだ案件の仕様設計が完成していないらしいので、それまでのつなぎの雑務ですね。
設計書の改造箇所を赤字で書いていて、改造が終わったので黒字に戻すという作業だけど、すごい量の設計書。
１５０くらいのファイルがありました。
古い設計書をもとに改造箇所を反映しているので、無駄な部分は「共通化により削除」とかの記載もあった。削除とは書いてあるけど、設計書自体は消さないんですね。
だから一応ファイルを開いて確認するという作業が必要になる。
ほんと生産性のない作業だけど、最初は仕方ないですかね。
3日目 、４日目 赤字を黒字にする
またかよ。
まあまだ案件の仕様設計が完成していないらしいので、それまでのつなぎの雑務ですね。
設計書の改造箇所を赤字で書いていて、改造が終わったので黒字に戻すという作業だけど、すごい量の設計書。
１５０くらいのファイルがありました。
古い設計書をもとに改造箇所を反映しているので、無駄な部分は「共通化により削除」とかの記載もあった。削除とは書いてあるけど、設計書自体は消さないんですね。
だから一応ファイルを開いて確認するという作業が必要になる。
ほんと生産性のない作業だけど、最初は仕方ないですかね。
二日目。赤字を黒字にする。
赤字を黒字にする経営者仕事を頼まれる！？
先方「ちょっと頼んでいい？」
早速仕事じゃん！
自分「大丈夫ですよ。よろしくおねがいします。」
先方「この黒字化してほしいんだけど。」
まさかそんな経営者視点の仕事を早速やらせてもらえるとは＼(^o^)／
先方「この赤字になっているところを黒字にしてほしいんだ。このフォルダを個々にコピーして、フォルダ配下のファイルを開いて赤い字になっているところを黒字にして。図の中の赤字はやらなくていいよ。」
最強の雑用ですね。
でもまあ未経験者にとってはどのファイルを見ても目新しいし、ちょっとは勉強になるかなという励ましを自分に捧げました。
いろいろ書いてあるけど全然理解できんし、そもそもこんな大量の資料をホンマに活用しながら開発してんの？！って印象だけでした。
実際はホンマに使っているのかもしれませんが、似通った資料も大量にあり、混乱を招くんじゃね？って思いもひたすら去来していました。
あとは来週テスト稼働するシステムのソースコードとか資料に目を通して２日目終了しました。
来週からどうなるんでしょう。早く開発やりたいなぁ。
