僕はコードを読むのは得意な方だけど、それが過ぎてコードを書かなくてもシニアソフトウェア開発者になってしまった。実はコードをちゃんと読めるソフトウェア開発者って希少価値が高いのではないか、と思ったので自分がどんな感じでシニアになったのかをまとめてみた。似た様な人の参考になれば幸いだ。 同意。僕は未だ書く方はほとんど機会なく成果もないけど、コードを読み尽くして、負荷試験や本番で挙動を把握し続け、メトリクスでとことん確かめていった結果、Sr. Engineer になれた。 https://t.co/KXtMdEaRr8 — Ryosuke Iwanaga (@riywo) April 16, 2021 コードを書かなくてもシニアソフトウェア開発者になれた 僕は今 Amazon の Sr. Systems Development Engineer という職種で働いている。いわゆるソフトウェア開発職
ここのところちょっと時間に余裕があり、暇を見つけてはQiitaの質問に答えるという取り組みをやっています。以前StackOverflowでも同様の取り組みをちょっとだけしてたことがあります。 9日間で35個の質問に回答してみて、正直に思うのは「質問の質が悪すぎるなー」ということです。ただ、どう質が悪いのか上手く言語化できず悶々としていました。 そんな折、今朝googleのおススメ記事に飛び込んできたQuaraのこちらの回答を読んで、「これこれ！こういうことよ！」という気持ちになったため、これから質問する人に向けてこの内容を少し嚙み砕いてまとめてみます。 ベテランはどうデバッグをしてるのか （自分をベテランと言っていいのかはさておき）日頃からコードを書いていると、デバッグには、その時使っている言語やフレームワークによらず、ある程度の行動パターンがあることに気付いてきます。 デバッグには難しい
コードを書く仕事をしてると、読むことも多い。読んでる時間のほうが多いかもしれない。いま書かれてるコードを読むことも、もちろん多いし、何年も前に書かれたコードを読む機会も割とよくある。 コードを読むと、そのコードを書いた人の考えや、そのときの状況が感じられて、おもしろい。特に、何年も前に書かれたコードを読むときは、コーヒーを片手に（そのときはこんな感じだったんだろうなぁ）って想像しながら読んで楽しい。 ふと、どういうコードから、自分がどういうことを想像するのかを書いてみようと思った。 前提 今、目の前で書かれているコードを読んでレビューしてるときの話じゃなくて、何年も前に書かれたコードを読むときの話をしようと思う。だから、そのコードが良いとか良くないとか、こうするべき「だった」とかは考えない。今後の自分がどう書きたいかなぁ？くらい。 また、そのコードを書いた人が良いとか良くないとかでもない。
OSS 観光名所を貼るスレ - ぽ靴な缶
これは はてなエンジニアアドベントカレンダー2023 2日目の記事です。 はてなエンジニア Advent Calendar 2023 - Hatena Developer Blog はてなエンジニアのカレンダー | Advent Calendar 2023 - Qiita トップバッターは緊張するけど、順番が回ってくるまで長い間ソワソワするのも嫌、という理由で例年2日目を狙うようにしている id:pokutuna です。今年も成功しました。 観光名所とは 目を閉じれば思い出す、あのコード... あの Issue... あなたが Web 系のエンジニアであれ、趣味で開発している方であれ、必要に応じてライブラリやフレームワークのコードを読むのはよくあることでしょう。公開の場で開発されているソフトウェアは、ソースコードだけでなく、開発コミュニティでの議論やバグ報告なども見ることができます。 リポ
AtCoder高橋社長がLINEのコーディング試験を見て驚いた理由―。「競プロとこんなに違うとは……」 | 外資就活ドットコム
AtCoder高橋社長がLINEのコーディング試験を見て驚いた理由―。「競プロとこんなに違うとは……」2022/10/06 ITエンジニア志望者にとって、時に「避けては通れない道」となるコーディング選考。実際に人気企業では、どのような試験や採点が行われるのだろうか。今回はLINE株式会社の協力の下、外資就活ドットコムの会員が参加（＊1）する模擬コーディング試験を開催。LINEが実際の選考で出すような問題を、参加者に解いてもらった。 その解答内容を題材に、LINEの新卒採用でコーディング試験を担当する大澤和宏さんと、特別ゲストのAtCoder高橋直大社長の対談を実施。2人の言葉から、「良い解答」「そうでない解答」の差、そしてコーディング選考と競技プログラミングの違いなどが見えてくる。【藤崎竜介】 ＊1 AtCoderで中級者とされる茶色もしくは緑色レベル、かつ2024年卒業予定の学生を対象に
JJUG CCC 2019 Fall #ccc_c5
私は長年 Pull Request のコメント数が多くて何回もレビューを往復することが多くて大変つらかったが最近ものすごく単純なコツに最近きづいたのでそのことをシェアしようと思う。 Pull Requestレビューの悩みこれはならない人はならないので、共感してもらえる人は少ないかもしれないが自分の悩みは Pull Requestのコメント数でこれが本当に多い。何がつらいって、レビューのコメントが多いという事は、マージに時間が掛かるということだ。最初にコードを書いてテストして完成させるのは２時間もかかってないのに大抵レビューで何往復もして時間を取られるのが本当につらいし、進捗がでないもの嫌だし、時間かかるし、自分が最近解決したい問題の中でも筆頭の問題だった。 何が悪いのだろう？すごく嫌なので物凄く考えたがうまくいかなかった。例えば、英語のスペルミスも良くしたし、ログやコメントの英文にレビュー
ソースコードの複雑さ、不具合のリスクを定量化したコードメトリクス1というものがあります。 コードメトリクスは計算方法によっていくつか種類があり、メジャーなものだと以下のものがあります。 Cyclomatic Complexity（循環的複雑度） Cognitive Complexity（認知的複雑度） Maintainability Index（保守容易性指数） Lines of Code（コードの行数） これらのコードメトリクスを計算し、CodeLensに表示するVisual Studio拡張機能2を作成しました。 tackme31/howmessy: How messy is your code? 以下のようにコードメトリクスをもとにコードが複雑かどうかを判定し、CodeLensに表示してくれます（デフォルトではCognitive Complexityをもとに計算します）。 今のところ
概要 django flameworkでの開発中にサーバー関連で何度もスタックしまして、同様に嵌る人が多かったので、そもそもどのようにdjangoがWebサービスを提供しているのかという切り口で俯瞰してみようと思いました。 なお、この記事はdjangoのモジュールの中身について解説するものではありません。あくまでサーバー周りの話です。 記事の目的・まとめ djangoのデプロイ手順を覚えるのは大変なので、まずはざっくりと全体像を掴んでスタックしたときにどこを調べたらよいか把握するための記事です。一応、個別のファイル設定についても記載していますが細かい部分は最新のドキュメントを参照ください。 図でまとめるとこんな感じです。 ここから細かい話&実際の手順になります。何の話をしてるのかわからなくなったら図に戻ってください。 前置き：djangoの動き方は1つではない djangoの動かし方は開発
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コードが読めるソフトウェア開発者 - As a Futurist...
Qiitaの質問に答えまくって気付いた初心者に足りないバグ解決スキル - Qiita
何年も前に書かれたソースコードを読むときの頭の中 - Mitsuyuki.Shiiba
こわくないソースコードリーディング生活 / JJUG CCC 2019 Fall
Pull Request のコメント数を減らすアホみたいなコツ｜牛尾 剛
メソッド上にコードの複雑さを表示するVisual Studio拡張機能を作りました - Qiita
djangoは誰が動かしているのか？（デプロイのための俯瞰） - Qiita