タグ

プログラミングに関するcubed-lのブックマーク (139)

  • 継承は禁止するべき

    キチガイに刃物、ゴミプログラマに継承。危険なものは取り上げるべきだ。 オブジェクト指向プログラミングにおける継承は強力な手法であるが、これを正しく使えるプログラマは残念なことに極めて少ない。たいていの場合、継承を使うことで却ってプログラムの保守を困難にしてしまう。継承のアンチパターンの最たるものは、単なるメソッドやメンバ変数の共有のために継承を使うパターンだ。これを行うとデータが密結合になってバグの原因になり、プログラムを把握することも極めて困難になる。 そもそも、熟達したプログラマの感覚では、業務で書くアプリケーションの実装に継承を使うべき局面などほとんど無い。ライブラリ等のより低レベルな処理で仕様が確定しているものについては、継承が効果的となる場合もあるが、複雑なアプリケーションのロジックに継承を使うのはほとんどの場合、時期尚早な抽象化となる。 また、凡庸なプログラマが継承で実現したい

    継承は禁止するべき
  • コードレビューの目的と考え方 - osa_k’s diary

    まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高(大きな損失を生む問題・後からの修正が困難な問題) 優先度中 優先度低(システムに大きな影響を与えない問題・後からの修正が容易な問題) レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

    コードレビューの目的と考え方 - osa_k’s diary
  • 自分の書いたコードが他者によって書き換えられることにショックを受けてしまうひともいるって話「まずこういう感情を理解する必要がある」

    irof @irof 自分の書いたコードが書き換えられることにショックを受ける人ってのはたくさんいて(もしかしたら多数派かも)、コードというかなんでもなんだろけど、「訂正」された、誤っていたと捉える。そもそも誤りでもないんだけど、仮に誤りだったとして、だからどうしたと、、、まだ掘らなきゃか。 2020-09-06 10:52:42

    自分の書いたコードが他者によって書き換えられることにショックを受けてしまうひともいるって話「まずこういう感情を理解する必要がある」
  • 長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方..

    長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方とブラウザでの動作確認を軽く教えた 次男も感化されたようで長男の真似をし始め、今は簡易な動作のHTMLファイルであれば作れるようになっている ある日、二人の空気が険悪だった(大喧嘩したあとの空気だった) まずは長男に事情を訊いてみると、とあるプログラムの方針で対立したとのこと それは「じゃんけんゲーム」だった 画面でグーチョキパーのいずれかを選びボタンを押すと、相手(CPU)の「手」と勝敗が表示されるというものだった 次男はまずCPUの「手」を乱数で決定し、画面に入力された「手」と比較して勝敗(と引き分け)を決める、素直な処理だった 長男はそれに飽きたのか、まずは乱数で「勝ち」「負け」「引き分け」を乱数で最初に決めてしまい、その後で結果に応じたCPUの「手」を決定するというロジックだった 次男はこれが気に入

    長男がプログラム(でゲーム)を作りたいと言い出したので、Javascriptの書き方..
    cubed-l
    cubed-l 2020/07/28
    それぞれにコードを書かせて比較させると良いんじゃない。確率を学んでいる年齢か否かで教え方は変わると思うが。
  • プログラミング言語はひとつマスターすれば他もできる? - t-hom’s diary

    プログラミングでは、ひとつの言語をマスターすれば、どんな言語でも使えると言われている。 この言説には賛否あるけど、ある意味正しくて、ある意味間違いだと思う。 より正確に言えば、新しく学ぶ言語と既にマスターしている言語に共通する概念についてはスムーズに移行できるということだ。 たとえば変数・分岐・繰り返し・比較演算なんかは、大半の言語が備えている共通概念である。言語によって作法やスタイルが異なるだけで考え方は同じなので、新しく学習する言語でこれらを使いこなすのは難しくない。 仮にVBAを100%マスターしているなら、Pythonの学習範囲はPython特有の部分だけで済む。 まあそうは言ってもなかなか一つの言語をマスターするのは難しい。 VBAの学習割合が少なければ、Pythonをマスターするための学習範囲はより広くなる。 じゃあまずはVBAを極めよう!と考えるかもしれないがそれも早計である

    プログラミング言語はひとつマスターすれば他もできる? - t-hom’s diary
  • ドラゴンボールZ ドッカンバトル | バンダイナムコエンターテインメント公式サイト

    AppleAppleのロゴは、米国およびその他の国で登録されたApple Inc.の商標です。App StoreはApple Inc.のサービスマークです。 Google Play および Google Play ロゴは、Google LLC の商標です。 ©バードスタジオ/集英社・東映アニメーション ©Bandai Namco Entertainment Inc. ※画面は開発中のものです。

    ドラゴンボールZ ドッカンバトル | バンダイナムコエンターテインメント公式サイト
  • 何でもかんでも揃えようとしないでほしい

    プログラマなんだけど、なんでも揃えようとしてる人がうざい よくあるのが、JSON とかオブジェクト系の記述するところで、 「:」とか「=>」みたいなのの位置 揃えられると一見すると見やすいが、金額みたいに揃ったみやすさが必要ないところでされると面倒 10行並んでたら1つ変えたのが原因で10行とも変えないといけなかったりする 面倒だけどツール使えば揃えること自体は楽にできるからこれはまぁいい だが、バージョン管理ソフトでの変更行数が無駄に増えるのでパット見たときに結構大きな変更してるように見えたりするからちょっとイヤ さらに grep かけようにも空白数が不定だから正規表現にしないといけない 正規表現書くの面倒だしそもそも遅い 大規模プロジェクトだと待ち時間が大きく変わってくる んだけど、まあここまでは別にいい 他でも十分ある宗派の違いだし、まだ理解できる この揃えるときに aaa : {

    何でもかんでも揃えようとしないでほしい
  • プログラムにコメント書かない文化もあるよって話|NZ MoyaSystem

    以下の記事を読んで。 530000micro.hatenablog.com 僕が勤めている会社では、原則、プログラムにコメントを書かないのがルールです。 人生で初めてプログラムに触れてからこのかた、プログラムには必ずコメントを書けと指導されて来ましたし、自分自身も、後輩たちにちゃんとコメント書けよと言い聞かせてきました。そんなわけで、最初に全然コメントのないソースコードの山を見たときは、正直「ゲッ、なんじゃこりゃ……」と面らったのは確かです。 ところが、「なぜうちのプログラムにはコメントがないのか?」と同僚に尋ねてみると、実に納得の行く回答が返ってきたのでした。 なぜコメントが必要なプログラムを書くのか? 同僚いわく、「コメントが無くても読めるようなプログラムを書け」という思想が根底にあるのだそう。 適切に関数や変数が命名され、スコープがきちんと管理され、ロジックの流れが整理されているコ

    プログラムにコメント書かない文化もあるよって話|NZ MoyaSystem
  • ソーサリアン~内部解析からわかったこと~ by PI.

    このドキュメントは、Y.ROMIさんが発行された同人CD「PC88ゲームの世界」 CD-ROM向けに、2000年6月に執筆、脱稿したものです。 その版をもとに記述ミスなどを修正したものを、ここに掲載します。 はじめに 筆者は、PC-88史上に残る名作である(株)日ファルコムのARPG、「ソーサリアン」をシャープ製パーソナルワークステーションX680x0シリーズへ移植した経験をもつ。この移植は全くのアンオフィシャルなものであり、あくまで個人の範囲内で独自に行ったものであることを予めお断りしておく。 さて、この移植にあたり、筆者らはバイナリレベルで60KBにもおよぶPC-8801mkIISR版「ソーサリアン」のほぼ全プログラムを解析するという作業を行った。この結果、今まで知られていなかった事実や、またソーサリアンのメインプログラマーである木屋 善夫氏(現在、日アプリケーション(株)に在籍)

    ソーサリアン~内部解析からわかったこと~ by PI.
  • 休日に家でプログラムを書いていようがいるまいが、ヤバイ人はヤバイ

    noon @n00nw0rks 仕事でしかプログラム書かない人は嫌だ、と思っていた時期が私にもありました。なお「仕事でしかプログラム書かないけど能力が高い」人に出会い考えが変わりました。仕事でしか書かないかどうかは能力に関係していることも多いが、してないこともあり、結局やる気も能力もないのが嫌というだけでした 2015-05-22 17:34:36 noon @n00nw0rks 逆に趣味でコード書いててもアレな人はアレで、以前「技術だけで飯ってきたいっすわーマネジメントとかやりたくないっすわー偉くなりたくねぇ~」ってミサワしてた趣味でコード書く人が、同じ口で「俺は<某技術分野>については勉強しても分からないから仕事は回すな」とか言っててホゲーッてなった 2015-05-22 17:41:54 noon @n00nw0rks 社会人一年生のころにいた会社が当にしゃれにならんくらい技術

    休日に家でプログラムを書いていようがいるまいが、ヤバイ人はヤバイ
  • [速報]マイクロソフト、コードを書くのに最適化したツール「Visual Studio Code」発表。Windows、MacOS、Linuxに対応、無料提供。Build 2015

    マイクロソフトは米サンフランシスコで開催中のイベント「Build 2015」で、開発用のコードエディタ「Visual Studio Code」を発表しました。WindowsだけでなくMacOSLinuxにも対応。無料で提供。 Visual Studio Codeはプログラミングのためのコードエディタで、Gitによるソースコード管理、IntelliSense、コードリファレンス、デバッガなどの機能を搭載。 Windows対応はもちろん、MacOS Xにも対応。

    [速報]マイクロソフト、コードを書くのに最適化したツール「Visual Studio Code」発表。Windows、MacOS、Linuxに対応、無料提供。Build 2015
  • ソフトウェアの技術革新って必要なのかな?

    プログラマの間では昔から、この手法は処理が遅いだとか、無駄が多いだとか、再利用を心がけろだったりとか 様々なやり方で、ソフトウェアをチューンナップして処理速度を上げるためのやりとりが際限なく 繰り返されているけど、だいたいどれもハードウェアの技術革新によって記録は塗り替えられてないかな。 そりゃ、ミドルウェアレベルでは全てのパフォーマンスに影響してくるので、ちまちまとした 改良が加えられるべきなんだけど、ソフトウェアレベルではどうなの? I/Oに引きずられるから、I/Oの処理は最低限に抑えるってのが昔から定説だけど それもSSDの登場で、かなり緩和された感があるし、結局プログラマの努力って ハードウェアの努力には追いつかないし、無駄なのではないかと思ってる。 10年前を支えたプログラム技術で今も生きているものってある? オブジェクト指向とかプログラムのわかりやすさを追求したものは別でね。速

    ソフトウェアの技術革新って必要なのかな?
  • エンジニアの面接でコードレビューさせてる

    (あんま多くないみたいだから多分すぐ身バレしそうだけど書く) エンジニアの面接で実際にコードを書かせる会社が最近は多いみたいだね。でもウチでは特に面接で書かせない。というか今まで書いてきた、関わってきたコードなんて書類で大体分かるでしょ? それよりも、ウチではコードレビューをさせてる。 選考用にわざと少し突っ込みドコロの多いコード(30〜50行程度のコードを3〜4ファイル)を渡して、もちろんファイル構成自体へのレビューも含めて、どんな意見をその人が出せるかを問う。 レビュー用のコードは複数言語用意してて、一番得意な言語を選んでもらってる。 時間は1時間。資料と赤ペン、そしてネットに繫がったパソコンを渡して、いくらでもググってもらって構わない環境でレビューを紙に赤して貰う。 「コードレビュー」ってものに対しての認識だとか、コードを管理するための能力もある程度分かるし、すごく良い選考制度だと思

    エンジニアの面接でコードレビューさせてる
  • プログラマとして30年以上の経験から得た教訓 | POSTD

    私は、プログラマとして30年以上仕事をしてきた中で、学んだことがあります。そのいくつかを以下にご紹介します。もっと挙げることもできますよ。 実物を見せないと、顧客の希望は分からない。 このことは最初の仕事で学びました。顧客は、実物を見るまでは、何が当に必要なのかがよく分かりません。言葉で長々と説明するよりも、機能検証のためのプロトタイプを提示する方が確実に役立ちます。 十分な時間があれば、あらゆるセキュリティは破られる。 現代社会において、セキュリティを保つことは信じられないほどの難題となっています。プログラマは常に完璧を求められますが、ハッカーは1回でもハッキングができれば成功なのです。 セキュリティが破られた場合、事前にその状況に備えた対策を講じているかどうかで結果が変わってくる。 最終的にセキュリティが破られることを想定する場合、その時に起こることに備えて対策を立てておく必要があり

    プログラマとして30年以上の経験から得た教訓 | POSTD
  • 動的型言語は静的型言語に比べてテストが増えるのか?

    自分も合っているかどうか分からない話で、それなりに重要だと思うので編集自由でまとめてみます。 とりあえずは、自分とmakotokuwataさんのTLをRT含めてまとめてみました。 時間順なので多少会話が前後します。 他の人の意見が聞いてみたいので、含めるべきツイートがある場合は自由に追加してください。

    動的型言語は静的型言語に比べてテストが増えるのか?
  • 『霧島、火消しやめるってよ』これ書いたらエンジニアをやめるべきコード9選 - paiza times

    2014年7月30日より開催中のpaizaオンラインハッカソン(略してPOH![ポー!])Lite「天才火消しエンジニア霧島 もしPMおじさんが『丸投げ』を覚えたら」ですが、たくさんのご参加ありがとうございます。引き続き開催中ですので、まだチャレンジしていない方は是非チャレンジください。 今回の物語では、主人公霧島京子の発注元にあたる1次請けSIerPM火村氏に、いかにアホなコードを書かせるかという事で色々悩んだのですが、ネタとしては面白いが可読性が悪すぎてヒントにならないという事でお蔵入りしたコードを紹介ます。 ■しょうもなさ過ぎてお蔵入りに… 今回は、これまでのオンラインハッカソンVol.1、Vol.2よりも難易度を下げて、より参加しやすい形を目指して、タイトルもPOH Liteとしました。物語の中で提示される元受PMの火村氏が書いたコードを読めば「愚直な解き方はある程度分かる」とい

    『霧島、火消しやめるってよ』これ書いたらエンジニアをやめるべきコード9選 - paiza times
    cubed-l
    cubed-l 2014/08/21
    ちょっと笑った
  • オブジェクト指向は禁止するべき - きしだのHatena

    プログラムがまだ不慣れな人が「プログラムちょっとわかるようになったけど、まだぜんぜんオブジェクト指向とかできてません」のように言ったり、ちょっと慣れた人が「このソース、ぜんぜんだめ。オブジェクト指向ができてない」にようなことを言ったり、まるで、オブジェクト指向ができてるかどうかがよいプログラムかどうかを表すことになってるようだ。 Javaのアルゴリズムのに、「Javaなのにオブジェクト指向ができていない」のような書評がついているのを見たときには、お前は何を求めてるんだと思ったりもした。 そのようなオブジェクト指向は、窓から投げ捨てるべきだ。オブジェクト指向はプログラムのよしあしの基準にならない。 むだにHogeインタフェースとHogeImplクラスがあったり、むだにnewするだけのcreateメソッドがあったり、どこで値が設定されてるかわからないオブジェクトがひきまわされてたり、ソースコ

    オブジェクト指向は禁止するべき - きしだのHatena
  • [iOS] 新言語SwiftがObjective-Cよりも良いところ - Qiita

    さきほどWWDCにて新言語 Swiftが発表されました。 The Swift Programming Language (iBooks Store) で言語ガイドが公開されていたのでザッと目を通してみました。 Objecitve-Cと比較してSwiftがイケてそうなところをパッと気になったところだけ書いていってみます。 変数/定数の型推論がある Objective-Cのように明示的に型を書かなくても型を推論してくれます。 推論で問題ないケースも多いと思うのでタイプ数がかなり減らせそうですね。 ( 変数を宣言する際はvar、定数を宣言する際はletで宣言します。 ) // 型推論 var name = "Shinji Ikari" // 変数の型は推論によりString型になる var age = 14 // 変数の型は推論によりInteger型になる let height = 141.5

    [iOS] 新言語SwiftがObjective-Cよりも良いところ - Qiita
  • ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習

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

    ペアプログラミングして気がついた新人プログラマの成長を阻害する悪習
  • dfltweb1.onamae.com – このドメインはお名前.comで取得されています。

    このドメインは、お名前.comで取得されています。 お名前.comのトップページへ Copyright © 2020 GMO Internet, Inc. All Rights Reserved.

    dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
    cubed-l
    cubed-l 2014/02/14
    面白そう