  |
はてなキーワード: リファクタリングとは
客が大企業で古いシステムのサポートが切れるから新しいものを入れる、みたいなやつ。
なんか新しいシステムを入れるのに、古いシステムのどれだけ満たすか、独自開発がどれぐらいいるか、みたいな調査をするのだけど、なんかアホだなって思ってた。
古いシステムはそもそも魔改造されてるわけで、サポートが切れるっていう意味もよくわからず、古いソースコードが急に消え去ったりするということなのだろうか、という疑問があった。例えばJavaのフレームワークが古く、アップデートできない状況ならば、なんとかしてリファクタリングするなりして解決したらいいのではって思ってたんよね。
まともなインターンでも酷くて時給2000円とか普通で時給3000円なのに、それよりも低い価値しか提供できないのか？
新技術の検証とか、リファクタリング試行とかインターンにやらせたりするが、10年やってもそのインターンよりも低いレベルなのか？
孫請けSIerや零細企業だと月給20万円とかいう世界があるのかもしれんが、もしインターンより安いのが当たり前だと思うなら転職した方が良い。
クソみたいなJST大手SIerで雇用してる低レベルプログラマーでも月100万円/人月で、
月稼働時間が(22日*7.5時間/日=）165時間だとすると、時給6060円だぞ。
簡単なことをやるにせよ、
ラジオを聴きながら、というか例えば芸人のエピソードトークとかの内容をある程度理解しながらプログラミングってできるもんかな？
例えばテトリスしながらラジオの内容理解するのは多分余裕だし、筋トレしながら、運動しながらもまあ大丈夫。
でも例えば目で小説を読みながら別軸で別の小説を音声で聞く、は多分大多数の人間には無理な気がする。
文章書きながら～もちょっと自分には難しい、複雑な構成を書いていて頭のリソースが書く方に使われている場合は音声で言っている内容の理解度はめちゃくちゃ下がると思う。
例えばプログラミングと言っても「リファクタリングとして○○クラスのメソッドをXXクラスに移して決まった法則に従ってメソッド名を変更する作業を100回繰り返す」というようなあんまり知的労働を伴わないような単純作業ならまあ多分できる。
100回くらい同じ仕組みを作ったことあるシステムの構築、とかでもできなくはない気がする。
ただゼロイチでアーキテクチャを構築するとか、調査を含めた不具合解消とか、英語のドキュメント読みながらの検証作業とか、これはもう小説読みながら別の小説を聴く、に近いものを求められる気がする。
ただ俺の脳のスペックだと難しい気がする、ってだけで他の人はどうなのかなってのもよくわからん。
在宅ワークが増えて「音声で何かを聞きながら仕事をする」ことって昔に比べると増えたと思うんだけど、「プログラマーがラジオを聞きながら仕事をする」ってできるものかね？
1. Markdown, Textileは知っていた。
2. 「何か新しいことを覚えようかなぁ」というコレクター魂のようなもので、reStructuredTextの手を付ける。
3. Sphinxなるものを知る。Pythonとから、Djangoとか、あの見慣れたチュートリアルを作るドキュメントツールがSphinx。
4. 面白いのだけど登場人物が多くて話が追えないなろう系のメモとして使ってみる。
6. LaTeX記法での数式表現、Matplotlibの機能に感動する。
8. 索引ページに気づく。
9. 日本語表示がイケてない。微分なら「は」の項目に、積分なら「さ」の項目に表示してほしいじゃん？「微」「積」の項目なんよ。。英語と同じように「頭の一文字」を取ったらそうなるよね。
10. 探してみたら、「Yogosyu」というプラグイン（※Sphinxでは拡張モジュール）があった。使ってみる。
11. 最新のSphinxに対応していない。ここからPythonのコード解析へと逸れる。
12. 取り敢えずエラーはでなくなったけど、元々索引ページとは関係ない機能だった。同一「用語集」での表示順が日本語に対応するだけ。
13. （しばらく放置）
14. 「単語の先頭に振り仮名を付け足せば、いい感じにソートしてくれる？」と気付く。
15. 表示の直前で「振り仮名」を取除くために、どこで表示しているか探す。
16. （紆余曲折）
18. ここで初めて「プラグイン形式にすれば良くね？」と気付く。
20. 出来上がって喜ぶ。
21. ここで初めて「これってクラスにしたら、全体の見通しが良くなったりする？」と気付く。
22.（この辺りで、unittestモジュールに手を付ける）
23. テストケースのお陰でリファクタリングが怖くない。喜ぶ。
24. setup.py, setup.cfgの書き方を学ぶ。
25. pypi公開を果たす。誰にも知られずひっそりと…
26. テストケースにjinja2を通した結果も加える。一人で成果に喜ぶ。
27. githubに手を付ける。学ぶ。基本的なことは覚える。
30. teratailに登録。コソコソ。「何がなんだか分からない」では質問しないし、そのうちどうにかなることが多い。先駆者に感謝。
32. coverageを知る。学ぶ。基本的なことは覚える。
33. circleciを知る。学ぶ。基本的なことは覚える。
34. カバレッジが90%を超えて喜ぶ。←今はこの辺。
※ボッチの日常
「TypeScriptを勉強する」が対策として上がってるならちょっとは理解できると思うが、
難しい文章を理解するために有効な手段のひとつはリファクタリングだ。
こんな感じ。
主張(a) 「その文章を読む価値があるのか」という想いの度合いが薄ければ、それに応じて文章は難しくなる。 (a)は文章にだけ言えることではない。 コンテンツを理解することは、モチベーションが高ければ容易になる。 「その難しいことをやるだけの価値があるのか」 「自分の人生の一部という、他にも選択肢がある中での、かけがえのない時間と交換するだけの価値があるのか」 という部分がモチベーションの高さに結びつく。 # 次のパラグラフは複数の主張が混濁しているようで、主張を明確にできていないように思える ＞ モチベは時間に応じて減衰していくので実際には習慣をつけるという能力も必要だが、 ＞ 点火点であるトリガーではモチベは有能な起爆剤になる。習慣化や自分のスケジュールに組み込まれることによって、 ＞ 必要なモチベの量はだんだん減っていくこともあり、 ＞ モチベだけがすべてではないが、基本は「価値あるぞ」と思えるかどうかだと思う。 コンテンツを理解すること自体は難しくない。 難しいのは、「それを突破する価値がある」と考えられる（＝モチベーションが高い）状態を作り上げることである。 モチベーションが高い状態を作り上げることに寄与する要素 ・自分には突破できるという信念（自信） ・それを裏付けする成功体験 ・たとえ無駄になったとしても人生において問題ないという経済状態 ・あなたならできると言ってくれる身近な人 上記の要素を揃えることは、難しい。 上記の要素を揃えるためにどうすればいいかは、ここまで読み進めてこられたみなさんならもうおわかりだろう。 # ここまで読み進めても「どうすればいいか」についての記述は無く、 # これは存在しない主張を、さも存在するように見せるレトリックに見える。
ちょっとプログラミングできる、っていうレベルの人が一番うざい
長い月日をかけて誰にも使われないソフトウェアが完成する
完成する頃にはもう居ない
自分はサーバサイドだから、フロントエンドだから、AIだから、とか言ってその分野ばっかりやる人
ぶっちゃけその分野もこっちでやった方が早いしできるんだけど
まぁそれはみんな一緒かもしれんけど同じことばっかやってて成長しない
最近のQiitaにも多いけど「こうしたら動きました」って言って内容理解してない人
これってどういう意味？って効いたら「コピペしてきました」って言う（意味を聞いてるんだが）
大抵は冗長かつ不十分な実装になっててしばらくして動かなくなる
まぁ誰しも通る道だとは思うので丁寧に指導はするけれど
『アジャイルソフトウェア開発宣言』の価値観に反対する人はほとんどいないと思う。
よりよい開発方法を見つけだそうとしている。
かつて、数々のアジャイルな開発手法が存在して（というか今も存在しており）、この宣言はそれらの開発者が集まって合意したものだ。
ところが、最近ではスクラムだけがもてはやされ、他の手法に全く触れられないことに違和感がある。
また、「うまくいかない原因の根本はそもそも開発チームの問題なんだっけ？」って問題そのものを議論せず、スクラムだけを導入すれば解決すると思い込まれていると思う。
私がスクラムについて違和感を持っているのは以下のような点だ。
※ただし、開発チーム以外を変えなくても導入できるのはメリットでもあり、それでチームの負荷を下げつつ他の問題に対処するのは悪い手ではないと思う
一方で、例えばXPは「開発が成功するためにチーム内外に向けてなんでもやれ」という視点が強く、「ビジネス上と技術上の責任を分ける」などのアドバイスの章も用意されている。
ただその分「ここに注意せよ」くらいしか書かれておらず、結局どうやるかは自分たちで試行錯誤しなければならないことは変わりがないが。
スクラム（というか開発手法全般）を不適切に導入した後の最悪のケースは、本当は他の要因で問題が起きているのに、その分析が全く行われずに、開発チームにだけ際限のない改善が要求されることだ。
例えば「みんなリファクタリングをしなきゃいけないことに気づいており、それが評価されないから新規プロジェクトに力を入れざるを得ない状況だと知っているが、それを誰も口に出さない。その状態で正確な見積もりをしようとしたり、開発スピードだけ効率を上げようとする」という状況は誰もが身に覚えがあると思う。
つまり、我々の所属するソフトウェア開発チームでは、目の前に存在する問題に対処してアジャイルチームになることが重要で、その方法はスクラムで主張されているような開発手法とは限らないし、むしろそのわかりやすさやきれいなドキュメントがミスリードである場合もある。
そのためには、まず現実の課題が何なのかしっかり把握して、フェアに議論することから始めるのが重要なんじゃないか。
最近自社で利用してる社内サービスの大型改修があるということで別案件に配属されたのだが、
そこに元から配属されてた先輩エンジニアのコミットログがどうにもおかしい。
先輩は数ヶ月くらい前から俺が担当するのとは別の新機能を3つほど任されてたのだが、
この新機能というのは実態としては別で運用されてる類似サービスとほぼ同機能で、使ってるフレームワークとかも同じ。
相違点はあれどほとんどは項目が減る、とか不要な機能がなくなる、みたいなところが中心で、大体はコピペで終わるはずだ。
複雑にデータが依存しあってるとか項目数が膨大とかそういうこともなく割と単純なCRUDだけのよくある管理機能。
正直自分ならユニットテストとかリファクタリングとか含めても3つ合わせて1日もあれば終わると思う。
その単純な新機能の開発に何故か先輩は数ヶ月かけていた。
毎日投稿される作業報告書を見るに、それ以外の作業実態もほとんどないみたいだった。
コミットログには、自分が出社して朝礼が始まるまでの5分くらいの間に終わる程度の修正を超細切れに2～3日に数回くらいコミットしてそれっぽく見せていた。
これは完全に社内の体制の問題なのだが、今たまたまその部署にいる上長があんまり実態の工数感とかわかってない人で、
んでその上社内運用のサービスってことで納期とか突っつかれることも少ないから適当に口でごまかして今の状況を作り上げたようだった。
ちなみにやってることは「保守要因だから待機が仕事なんだよ」っていうわけでもなく、ガチで業務時間の99%くらいYoutubeやらまとめサイトやら見てんじゃねえのって感じ。
うーん。。。。
俺だって在宅勤務中に一切Youtubeも5chも見なかったって言ったら嘘になるよ、いやぶっちゃけ割と見てる側だよ。
監視がないのを良いことに犬と散歩出たりお昼休み気持ち長めにとってちょっと遠めのレストラン行ったこともあるよ。
いやにしたって1日の作業に数ヶ月とかかけるのはいくらなんでも攻めすぎだって。。
俺は一応突っ込まれて困らない程度には成果物出してると思うよ。
ここまで極端だと「あの人数ヶ月ほぼ作業実態ないですよ、証拠はこれで～」とか誰かが上にチクリ入れたらどうするつもりなんだよ。
非定型業務の仕事は日々責任と時間に追われて正解のない問題に取り組み続けなきゃいけないのがしんどい
かといって定型業務の仕事は中～低知能者の労働者がマジョリティでコミュニケーションがしんどい
（べつにバカにしているわけでなく、むしろこちらがマイノリティの障害者っていう自覚はある。IQに差があると会話が成立しづらいって話よくあるよね）
高知能者向けの定型業務があれば迷惑をかけずに済んで三方良しと思うんだけど
ないかな
---
なるほど、リファクタリングマン・デプロイマンは良い線行ってるかも
コードレビューをずっとやっていると、伸びるタイプかそうでないかが提出してくるコードで分かるようになってくる。
ざっくり
を見る。
コードフォーマットで頻繁に同じような指摘を受けるタイプは明らかにエディタやコンソールといったツールが使えていない。
人間が作業の精度を上げるのではなく、100%の精度で作業してくれるツールにやらせれば良い。
些末なミスはツールが拾ってくれる方が高速で、正確で、なにより心理的負荷が低い。
リファクタリング機能やコードフィックスの提案を有するツールなら学習のペースも上がる。
コードフォーマットで消耗しているようでは、本来重要なはずの作業や学習に時間が取れないのは自明だろう。
命名を軽視する者は、作業の対象となっているコードがどんな責務を負うか、自身の書いたコードの内容すらも完全には理解していない傾向が強い。
(ここではあえてクラスやメソッドという表現を避けるが)扱うコードが何をするもので、何に依存し、どこから呼ばれるか。
どういったエラーが出うるか、エラーは今のレイヤで対処しておくべきものか、他のレイヤの責務か。
命名にはそういった情報が反映される。英語が苦手？プログラミングで使う語彙なんて極めて少ない。高校生ぐらいのレベルの英語ができれば十分だろう。
むしろ、先人が少ない語彙でどうやって事物を表現してきたかを学ぶべきである。
求められるのは正確さと一貫性であり、誰もボキャブラリーなんぞ求めていない。少ない語彙で正確に表現できるぐらいに対象のコードを整理しろ。
命名がうまくいかないのはお前の英語力が低いからではない。コーディング力か、コードが扱うドメインへの理解が弱いからだ。
