タグ

コードに関するlight940のブックマーク (51)

  • 新入社員に心掛けておいてほしいこと

    初めに 私は昨年の6月に社畜と化し、一か月ほどの研修の後に実務と並行しながら社内の研修業務を行ってきました。 その中で新人プログラマ、とくに今まで学生で一人での開発を行っていた方に対して今後複数人で開発を行う状況(まぁ就職してからってことですね)になった時に気を付けてほしいことを毎回言うのも大変なのでドキュメント化しました。 良い名前をつけよ コードを書いているとき、コードを読みながら書いています。しかし、コードを読んでいるときに必ずしもコードを書いているとは限りません。つまり、コードを読んでいる時間>コードを書いている時間なのです。つまりコードは「読み返す事」を前提に書いています。 読むのはあなたとは限りませんので、誰もがわかりやすい名前を付けましょう。特にパブリックなメソッドやパブリックな変数に対してはより時間をかけていい名前を付けましょう。 特に新人の方が陥りやすい考えとして「長い名

    新入社員に心掛けておいてほしいこと
  • webpack(v1)とbabelでES6コードをさくっと書く - getalog

    最低限のコストで最近よく聞くいい感じのjsを書きたい時の構成をずらーっと書いてみる 準備するもの node/npm (最近はrbenvクローンのnodenvがいい感じ、操作は同じ) webpack babel .babelrc .babelrcを設置しとくとbabelのデフォルト設定がこいつの中身で書き換わる Reactを使わないなら、presetのreactはいらない export defaultされたパッケージをimportした時に.defaultで引くのを許せるなら、add-module-exportsはいらない(後述) Reactいる { "presets": [ "es2015", "stage-0", "react" ], "plugins": [ "add-module-exports" ] } いらない { "presets": [ "es2015", "stage-0"

    webpack(v1)とbabelでES6コードをさくっと書く - getalog
  • プロとしての行為 Act as Proffesional

    心底、プログラマとして生きていくのが幸せなんだなと思える人に出会ったことのある@HIROCASTERでございませう。 プログラミングが上達するベストプラクティスってあるんでしょうか? 大学でコンピュータ教えている教授なんかは、そのあたり教えてくれるんでしょうか? あなたの先輩は教えてくれましたか? 昔ながらの職人がいう、見て、まねて、盗め。ですかね? 僕の経験で、いくつか書いてみました。 毎日コードを書くとにかく毎日コードを書いている。 息を吸うように、歯磨きををするように、顔を洗うように、事を取るように毎日コードを書いている。 テストコードも書く動くソフトウェア側のコードだけでなく、テストコードも書いている。 必然と設計も考える癖が付くわけで…。 ソフトウェア全体を仕上げるまで書く例えば、小さなメソッドだけでなく、クラス全体を。 ソフトウェアとして動作するまで全体を。 全体を仕上げるま

    プロとしての行為 Act as Proffesional
  • もうすぐエンジニア2年生になる人から新卒エンジニアへ贈るあれこれ - Qiita

    前書き Qiitaなので当は技術的なことを書いたほうがいいと思うけれど、技術的なこと以外もいろいろ書いていこうと思う。いわゆるポエムである。 チームで開発するということについて 自分は就職するまで一人でコード書いてわいわいすることのほうが多かったので、チームで開発するということがよくわからなかった。 就職して実際に先輩たちとコードを書いたり、デザイナーさんやディレクターさんともろもろお話するようになって、気をつけておけばよかったなーと思うことをいくつか書いておく。 メモを取ろう 自分の頭の記憶には限界がある。その時点で覚えてても、席に戻ったら忘れてると思う やる事をメモしておいて、報告する前にそのメモを見直すと、やり忘れで恥ずかしい思いをしなくて良くなる。 タスク管理は一箇所に集約しよう わたしの会社では依頼がRedmineGitHubのIssueで飛んでくる(プロジェクトによる)。正

    もうすぐエンジニア2年生になる人から新卒エンジニアへ贈るあれこれ - Qiita
  • http://harold-spm.com/javascript-jyoutatsu/

  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

    最近、あまりプログラミングが得意でない人のサポートをする形で、長い時間にわたってペアプログラミングを行っている。そのなかで、気がついた悪い習慣と成長するための良い習慣というものをまとめてみる。 この記事のバックグラウンドとなる体系的知識がになりました。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング あわせて読みたい 経営者マインドが足りない!vs. 現場に任せてくれない!の対立をなくすカードゲームをつくった話 新人プログラマに知ってもらいたいメソッドを読みやすく維持するいくつかの原則 新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡 ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習 あきらめるにはまだ早い!ソースコードの品質向上に効果的なアプローチ 心理的安全性ガイドライン(あるいは権威勾配に関する一

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
  • PHP向け静的解析SaaSの主観的比較 (Scrutinizer, SensioLabsInsight, CodeClimate) - Qiita

    PHP向け静的解析SaaSの主観的比較 (Scrutinizer, SensioLabsInsight, CodeClimate)PHP 静的解析というのは、自動テストを実行せず、コードを解析してソースコードの複雑さやバグの起こりやすさを検出してくれるサービス。テストがなくても即座に導入できる手軽さがあり、テストとは違う面でソースコードの品質を高めるのに役立ってくれる。 CI(Continuous Integration)の一種ではあるが、特にContinuous Inspectionと呼ばれることもある。「全自動コードレビュー」と言う方が近いだろうか。 Travis-CIで各種OSSを組み合わせて似たような処理を実行させることもできるが、設定が面倒くさいし、レポートをどうするか考える必要もある。特化型SaaSの方はこの辺をよく考えてくれている。 PHPに対応したInspection系のS

    PHP向け静的解析SaaSの主観的比較 (Scrutinizer, SensioLabsInsight, CodeClimate) - Qiita
  • なぜひどいコードを書いてはいけないか - hitode909の日記

    ひどいコードは何やってるか分からない ひどいコードが何やってるか分かっても、なぜそうなってるのか、そこを変えるとどうなるか分からない ひどいコードは新たな変更に耐えられず書き直されることになる ひどいコードを書き直すには、ひどいコードがどうなっているか理解し、どこを変えるとどうなるのか理解する必要がある ひどいコードはたいていひどいテストコードが支えていて、テストコードがあったとしてもひどいコードと同様の問題があり、頼れるものが何もない どんなにひどいコードでも、書いた人を憎んではいけない。たとえ自分の書いたコードだとしても、先輩の書いたコードだとしても、ソフトウェアとしてひどい物にはひどいと言っていくことが大切で、だからと言って人に向かってひどいと言ってるわけではない。 最高の仲間たちが日々変化する難しい問題に対処していいコードを書いたり、ときにはひどいコードを書いている、という😇的な

    なぜひどいコードを書いてはいけないか - hitode909の日記
  • XcodeSwiftSnippets でコーディングを速くしよう! - Qiita

    == はじめましてこんにちは! スタートアップの Liaro で iOS アプリエンジニアをしている @131e55 です. 今回は Swift でコードを書く際に便利な XcodeSwiftSnippets を紹介します. XcodeSwiftSnippets とは Xcode のスニペットとは, よく利用するコードのひとまとまりを予め定義しておいて, 少ないタイプ数で入力できる補完機能です. スニペットは自作することもできますが, 誰もがよく使うようなコードが XcodeSwiftSnippets にまとめられているので導入するだけで便利なスニペットを利用できます. 導入方法 以下のリポジトリを git clone または zip のダウンロードをします. https://github.com/burczyk/XcodeSwiftSnippets 取得したフォルダ内の plist フォ

    XcodeSwiftSnippets でコーディングを速くしよう! - Qiita
  • GitHubの草を連続40日間生やしてみたけどやめた - スペクトラム

    https://github.com/ksss rebuild.fmの#120を聞いて、jQueryの作者が始めた「毎日コードを書く」というやつを40日間やってみた。 rebuild.fm John Resig - Write Code Every Day よかったこと アウトプットがふえた 毎日コードを書くというルールなので、 アウトプットは多くなった。 手持ちのリポジトリを大幅に整理したり、PRも10件ぐらい飛ばした。 毎日コードを書くと、コンテキストスイッチのオーバヘッドが小さくなるというのは当で、 お風呂に入っている時にアイデアが思いつく事もあった。 無意識領域の脳リソースをうまく使うことができてるのかもなあと思った。 よくなかったこと インプットがへった アウトプットのために使う時間を必ず確保するので、アウトプットからインプットへコンテキストスイッチするオーバーヘッドは増加した

    GitHubの草を連続40日間生やしてみたけどやめた - スペクトラム
  • [Swift] TailorでSwiftのコードを静的解析! | DevelopersIO

    はじめに 加藤 潤です。 今回はSwiftの静的コード解析ツールであるTailorをご紹介します。 Tailorとは Swift用の静的コード解析ツールで下記のような特徴を持っています。 クロスプラットフォーム(Mac OS X、LinuxWindows) CLIで解析を実行し、解析結果のレベルに応じてカラーリング表示 Xcodeのビルド時に解析を実行し、Issue Navigatorに結果を表示 MITライセンスで公開されている また、コーディングスタイルガイドラインとしては下記が採用されています。 The Swift Programming Language GitHub Ray Wenderlich Coursera インストール Java 8をインストール Tailorを使うにはJava 8以上が必要です。 インストールされていない場合はこちらからインストールしてください。 筆者

    [Swift] TailorでSwiftのコードを静的解析! | DevelopersIO