質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Node.js

Node.jsとはGoogleのV8 JavaScriptエンジンを使用しているサーバーサイドのイベント駆動型プログラムです。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

Q&A

解決済

11回答

6377閲覧

システム・ソフトウェアの設計力はどのように身につける?

退会済みユーザー

退会済みユーザー

総合スコア0

Ruby

Rubyはプログラミング言語のひとつで、オープンソース、オブジェクト指向のプログラミング開発に対応しています。

Node.js

Node.jsとはGoogleのV8 JavaScriptエンジンを使用しているサーバーサイドのイベント駆動型プログラムです。

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

PHP

PHPは、Webサイト構築に特化して開発されたプログラミング言語です。大きな特徴のひとつは、HTMLに直接プログラムを埋め込むことができるという点です。PHPを用いることで、HTMLを動的コンテンツとして出力できます。HTMLがそのままブラウザに表示されるのに対し、PHPプログラムはサーバ側で実行された結果がブラウザに表示されるため、PHPスクリプトは「サーバサイドスクリプト」と呼ばれています。

JavaScript

JavaScriptは、プログラミング言語のひとつです。ネットスケープコミュニケーションズで開発されました。 開発当初はLiveScriptと呼ばれていましたが、業務提携していたサン・マイクロシステムズが開発したJavaが脚光を浴びていたことから、JavaScriptと改名されました。 動きのあるWebページを作ることを目的に開発されたもので、主要なWebブラウザのほとんどに搭載されています。

6グッド

25クリップ

投稿2017/09/20 23:34

編集2017/09/21 00:32

主にJavaScript(Node.js、TypeScript含む)を使っているのですが、設計力というのはどのように身につけていけば良いものなのでしょうか?
※PHPやObjective-cの経験はあります。

教えてくれる人がいないため、本などで学ぶ訳ですが、いまいち、設計力が身についている実感も自信もありません。

MVCの概念、デザインパターン、オブジェクト指向、ドメイン駆動開発、関数型プログラミング、テスト駆動開発となんとなーく浅いですが勉強はしてきましたが、ちゃんと理解出来ているのかも謎ですし、身についているかというと中途半端ですし、なんというか、ダメダメなのです。

頭の中のごちゃごちゃしたものを整理しますと、こんなところでしょうか!

1.何をすれば、どうすれば設計力が身につくのか?
2.設計力がどのくらい身についているかを知る判断基準は?
3.そもそも、目指すべき良い設計とは?
4.設計の手順は?

尚、ここでの設計力という言葉が指す対象範囲は、インフラとかDBとか含まない範囲とします。(言葉を適切に使えなくてわかりにくいかもしれませんが、すみません。)

ぼやけた質問で恐縮ですが、よろしくお願いいたします。

なんとなく分かっていること

  • テストしやすいコードは良いよね(疎結合、副作用を伴わない)
  • 何か変更をする必要が出てきたときに、あっちもこっちも修正しないといけないコードは良くないよね。(凝集度の高い1つのファイルを修正すれば、他を修正しなくても全部解決!)
  • 設計から離れるかもしれないけど、読みやすいコードはいいよね。(Lintツール、整形ツールが味方さ!)
ykws, ai_2013_dev, rkojima, chromitz, shimitei👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答11

0

ベストアンサー

一定ラインまで育ったプレイヤーがそれ以上のステップに進むには反省が必要になります。
上手くなるに従って、殆どのプレイヤーには変な癖がついてしまいますのでそれを取り払う事が必要です。

  • スポーツ選手はコーチにフォーム等を見てもらいながら修正・矯正していく
  • 演奏家は自分の弾いた曲を録音して、駄目な所や苦手な所を反復練習する
  • 棋士は対局後、譜面を再現し直しながらこの手は良かった悪かったと検討する
  • 格ゲーの上級者は対戦後、キーディスプレイのリプレイを見ながら注視すべき箇所や判断の問題点を洗い出す

この辺は脳モデルの話なんで割愛


成長の方法

プログラミングの世界もこれの例に漏れず、
作ったものに対して評価、何が良かったのか悪かったのかの分析をするべきです。

以下は詳細設計に絞って解説していきます。

TypeScriptやPHPはオブジェクト指向寄りの言語なんで、基本的には1ファイル1クラスでしょう。
従って、多くのファイルをまとめるディレクトリの切り方が詳細設計の力量として現れてきます。

ディレクトリの切り方はプロジェクトの立ち上がりにしか経験出来ないものなんで、
既存のプロジェクトやGitHub等に上がっているディレクトリの切り方をひたすら批評していきましょう。
自分でしょぼいCLIツールみたいなものを沢山作ってみるのも良いと思います。

  • このプロジェクトのディレクトリの切り方はかっこいいな
  • このプロジェクトのディレクトリの切り方は糞、俺の方がもっとこう…ってあれ?

実現出来ないから修正してたら結局同じ構成になったんだが

…等と言った試行錯誤が必要です。
この時に重要なのは評論家で終わらずに実際に作ってみて良くなったのか良くなかったのかを振り返ることです。
私も自分のGitHubに上がっているプロジェクト群を見て目を覆わんばかりのゴミプロジェクトの山で恥ずかしく感じます。
恥ずかしいってことは、今は成長してるわけですね。


成長の実感

プログラミングの世界の技術力は目に見えず感覚でしかわからないものなので、
将棋の指し手の筋の良さと同じく絶対的な数値というのはわからないものです。
コンピュータ将棋が流行って+1000という数値で表せてしまった、みたいな画期的な技術が必要でしょう。

投稿2017/09/21 01:20

miyabi-sun

総合スコア21158

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 23:14

いつもご回答ありがとうございます!あまり人のコードをGitHubなどで読んだりすることがないので、そういった習慣を築いていきたいと思います。まずは時間確保のための時間再配分からですね。
guest

0

求められている回答にならず、申し訳ないのですが参考までに。

物事が習得出来ているかどうかを判断する方法として、「人に教えることが出来るか」という基準があります。
「人に教えることが出来る」という状況であれば、十分理解しており、そして質問されることがあっても回答出来るだけの知識が必要となるため、習得出来ていると判断しても良いと思います。

なんとなく分かっていることに書かれていることが、ソートコード寄りに書かれているのでそういう話であれば
デザインパターンなどが知識ベースであり、それを実践で使えれば問題ないと思います。

投稿2017/09/21 00:17

YasuhiroMiyake

総合スコア1336

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 00:21

ご回答ありがとうございます。確かに人に教えられるかどうかというのは、自分に身についてるかどうかの判断基準になりますね。ろくに人に教えられるものなどほとんどないので、一つずつ人に教えられるレベルまで見につけたいと思います。
YasuhiroMiyake

2017/09/21 00:32

既にteratail で多くの回答を書かれているようなので、その分野については自信を持っても良いと思います。 私は自分自身が何が理解出来ていて、何が理解出来ていないのかを知りたくて、teratail を見ています。 英語が使えれば、本当はstack overflowにも挑戦したいのですが・・・。(日本語版も出ましたがまだユーザが少ないので)
guest

0

質問はコーディングの設計力のことのようですね。
私にとってその意味での設計力とは、以下の2点です。

1.設計のパターンを多く知っていること
2.場合によって利用価値の高いパターンを取捨選択できること

それを踏まえて以下質問に答えてみます。

1.何をすれば、どうすれば設計力が身につくのか?

2.設計力がどのくらい身についているかを知る判断基準は?

他人のコードを読んでください。GitHub等であれば無数のコードに触れられるでしょう。
まず読んで理解できるかどうかが第一関門で、理解できないようであれば、自分の中に足りないパターンがあるということです。
いいと思ったパターンは取り入れ、悪いと思ったパターンは改善案を自分で考えてみて下さい。

どんな人の書いたコードでも、そこで利用されているパターンやその人特有の癖のようなものを読み取れるようになれば、かなりのものだと思います。

3.そもそも、目指すべき良い設計とは?

4.設計の手順は?

一律に良い設計というのはなかなか難しいものです。
良いと思う設計パターンを場合に応じて取捨選択し利用していくということが「良い設計」の判断基準かなと思います。
そのためにも、自分の中でどれだけ良いパターンを知っているかが良い設計をするための条件となります。

ただ、コード自体の可読性などであれば「良いパターン」ということが分かり易いのですが、保守性など、時間が経過しなければ理解できないものもあります。

重要なことは、より良い設計に向けて感度を上げて、それを忘れないことだと思います。
例えば、以前は理解できなかったパターンも、保守の場面になってみると「ああいうパターンにしておけばよかった」と思えることも多いはずです。
そういったパターンについても、後から反省し自分のものにできるかどうかが成長を左右すると思います。

投稿2017/09/21 04:01

akabee

総合スコア1947

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 12:00

ご回答ありがとうございます。確かに後から「書き直したい!」と思うことは度々あります。それを学びの機会にすれば良いですね!
guest

0

主観の影響が大きい質問内容なので、一つの意見としてみてもらえれば。

1.何をすれば、どうすれば設計力が身につくのか?

  • 数を多くこなす
  • 他のシステムがどんな設計で動いていそうか考えてみる(自分だとこう作るかなー。みたいな)
  • 他のシステムに触れる

2.設計力がどのくらい身についているかを知る判断基準は?

  • 一つの要件に対して、いろんな設計方法を上げられる
  • 個々の設計方法についてのメリット・デメリット(+出やすい問題)を理解している
  • 多くのシステムで採用されている(基本とされている)手法を取り入れている
  • 他の人に見て(聞いて)もらう

3.そもそも、目指すべき良い設計とは?

抽象的ですが「変更がしやすく、システム的に破綻の起きにくい構成となっていること」かなと思います。

テストしやすいコードは良いよね
何か変更をする必要が出てきたときに、あっちもこっちも修正しないといけないコードは良くないよね。

これらも変更しやすくするためのテクニックと考えています。
テストがある = 変更に問題がないかすぐに確認ができる(心理的な障壁の低下)
変更箇所が少ない = 影響範囲を限定しやすい

投稿2017/09/21 00:31

rkojima

総合スコア421

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 23:11

ご回答ありがとうございます。「変更がしやすく」というのはイメージしやすいのですが、「システム的に破綻の起きにくい構成」というのは例えば、どういったことになりますでしょうか?
rkojima

2017/09/22 02:26

なんとなくですが、気を付けているところを箇条書きしてみました。 - バグが入り込みにくいこと - データの整合性が保たれること(バリデーションチェックなど) - 不正な操作を受け付けないこと(インジェクション/CSRFなど脆弱性対策) - 権限のないユーザーがリソースにアクセスできないこと(権限チェック) > インフラとかDBとか含まない範囲 だいぶ↑から外れてしまっていますね・・・ 改めて考えてみると漠然としたイメージしか持っていないことに気づき、他の回答者様の意見がとても参考になっています。
guest

0

そもそも論ですが、システム・ソフトウェアの設計って どのようにデータ構造を作るか?それをどう利用するか?であって、コードがどうとかでは無いと思います。

MVCの概念、デザインパターン、オブジェクト指向、ドメイン駆動開発、関数型プログラミング、テスト駆動開発

上記は実現方法なので、先に根っこを押さえたほうが良いかと。

投稿2017/09/21 01:31

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 09:52 編集

ご回答ありがとうございます。根っこというと?
退会済みユーザー

退会済みユーザー

2017/09/21 11:58

システム・ソフトウェアの設計を言い換えると、以下となります。 ・要件を、入力/出力に落とし込み、それを実現するためのデータ構造を作る ・その入力/出力を満たすための処理を作る hayatomo さんの質問内容から、実現方法に目が行っていて、設計に目が行っていないように思えましたので、まず「設計とは」にあたる上記2項から押さえたほうが良いのでは?というのが回答主旨です。 実際には、実現方法を想定しない設計なんて無いので、実装を知ることは重要なのですが、設計力を向上させるのであれば、実現方法を学ぶより、データをどのように持ち。それをどう処理するか?といった設計そのものを学ぶほうが良いと思います。
退会済みユーザー

退会済みユーザー

2017/09/21 23:16 編集

補足ありがとうございます。「データをどのように持ち。それをどう処理するか?といった設計」というのは、OOPやDDDがデータモデリング含め、カバーしているところではないのですか?もっと違うレイヤーでの設計のことでしょうか?
退会済みユーザー

退会済みユーザー

2017/09/22 00:13

要件を入力/出力に落とし込むというのは、その要件が「どのような値」として表現され「どのような制限がかかるのか」を整理することを意味するので、レイヤーとしては少し違うように思います。 実作業としては、実現方法を意識しながら上記の落とし込みを行うので、実現方法と落とし込み作業は密接な関係にありますが、システム・ソフトウェアの設計の本質という意味では、別レイヤーであると考えます。
退会済みユーザー

退会済みユーザー

2017/09/22 00:28

他の方の回答を見てみたのですが、私だけシステム・ソフトウェアの設計という言葉の捉え方が違うようですね^^; akabee さんの使用した「コーディングの設計力」という言葉がしっくりきますが、その「コーディングの設計力」に対しての質問であれば、私の回答は的はずれなものになります。 逆に、私の捉えている意味での「システム・ソフトウェアの設計」に関する質問なのであれば、hayatomo さんの意識は、実装方法に引っ張られすぎています。
退会済みユーザー

退会済みユーザー

2017/09/22 00:32

補足ありがとうございます。「「どのような値」として表現され「どのような制限がかかるのか」を整理することを意味する」というのは、OOP、DDDでカバーされているように私には感じられるのですが、ニュアンスレベルでレイヤーが少し違うという話でしょうか?
退会済みユーザー

退会済みユーザー

2017/09/22 00:45

私の捉えている「システム・ソフトウェアの設計」という意味でコメントしますが、例えば、「請求書発行システム」を構築するとして、入力値として「宛先の郵便番号」等々が必要となります。 「宛先の郵便番号」は「数字で表現」され「ある規則性にのっとり」、「送付先会社のデータの一部」として扱われます。 「システム・ソフトウェアの設計」の段階では、上記程度の整理が必要であり、それを取り回すための処理(オブジェクトにする等)といった事は、意識しません。(いや、実際はするんでややこしいんですけど^^;) 伝わりますかね?
退会済みユーザー

退会済みユーザー

2017/09/26 05:08

なるほど。OOPやDDDには分析は含まれないという前提での話ですかね。
guest

0

1.何をすれば、どうすれば設計力が身につくのか?

数を熟すことですが、結果(実装や運用してみて等)のフィードバックは必須。

2.設計力がどのくらい身についているかを知る判断基準は?

結果からじゃないでしょうか。手戻りが無かったか?システムが安定しているか?保守性に問題無いか?等

3.そもそも、目指すべき良い設計とは?

終着点は無いのでは。次はもっと良い物をと考え工夫していく事じゃないですかね。

4.設計の手順は?

手順というか設計力と言われているものにも関係しますが、如何に本質を捉えられるかが鍵だと思います。
その為に、多角的な視点からシミュレートして、本質と言えるかどうかをブラッシュアップする。

※あくまで、主観に過ぎないですけど。

投稿2017/09/21 01:16

sazi

総合スコア25138

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 23:13

ご回答ありがとうございます。「結果」から上手く言ってるかどうかを判断する、「結果」から学ぶというのはまさにその通りで身に沁みますね。ちなみに、「手順というか設計力と言われているものにも関係しますが、如何に本質を捉えられるかが鍵だと思います。その為に、多角的な視点からシミュレートして、本質と言えるかどうかをブラッシュアップする。」とありますが、ここでの本質というのは何のことをさしているのでしょうか?
sazi

2017/09/22 02:24 編集

本質とは、「欠くことができない、根本の性質・要素。」です。 システムの設計においては、本質であっても要件に無いものは不要ですから、省けば良いですが、本質を捉えていれば、逆に省くのではなく要件が不足している場合もあります。 また、クラス設計に当てはめると、本質はスーパークラスです。目的ごとに継承して拡張するなど、拡張性に富んだものになります。 その為には、見えている事象から、隠れているものを明らかにし、本質ではないものを分離することが必要になります。 その方法として、視点を変え、幾つものシミュレートをし、本質を炙り出すのです。
guest

0

初めまして!

今更かもしれませんが、
自分も今まさに設計を学んでいるところで同じ悩みを抱えています。

参考になるか分かりませんが、自分がやっている方法としては、
・設計やオブジェクト思考に関する本(理論と実例が載っているもの)を読む
・1章読む毎にその章で言われていることから自分のプロジェクトで使えそうなものをピックアップして、
その理論に従ってリファクタリングする
というものです。

一度本を読んで、その後ゼロから設計しようとして見たのですが、
経験が無いためかどこから着手して良いかわからず結局進みませんでした。

そこで上記のように、既存プロジェクトの設計を見直す(リファクタリングする)ことから始めて見ました。

最初は「設計」というより、読みやすいコードを書くためのリファクタリングから始めましたが、徐々にクラスを分割したり、デザインパターンを使ってみたりと難易度をあげています。
やっていくうちに、うまくクラスを分割出来て、書籍にあるような理論通りにできることもあれば、うまくいかずえ調べた上でやり直すことも出て来ます。
そういった経験を通して少しずつですが本で読んだ設計の理論が実践レベルに落とし込まれて来ている感覚があります。

あとは出来る人に叩いてもらい改善する経験が無いのでそこが今の課題です。

上記の方法で全体を網羅的に学ぶことは出来ないかもしれませんが、
一個ずつ身についていっている感覚は得られるので、最初の入りとしては良いのかな、と思っています。

私はプログラミングを始めてまだ数ヶ月程度なので、レベル感的に上記のやり方は質問者様に合っているか分かりませんが、何かしら参考になれば幸いです。

(ちなみに、今は「現場で役立つシステム設計の原則」という本を読んで実践しています)

投稿2017/09/26 19:05

YorihiroKatsuki

総合スコア70

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/26 23:41

ご回答ありがとうございます。増田さんの本は私も読みました。ワークショップにも参加したかった。。。
退会済みユーザー

退会済みユーザー

2017/09/26 23:42

設計やオブジェクト思考に関する本(理論と実例が載っているもの)を読む ↑ 他にオススメの本はありましたか?
guest

0

こんにちは。
一つ具体的な提案をあげてみます。

「なんとなく分かっていること」のことを知っているのであれば話は早いです。
それを雑に一言でまとめると「再利用性の高い設計」と表現することができます。
そして、最も身近であろう再利用性の高いコードとは、ズバリ「フレームワーク・ライブラリ」です。
今まで使ってきたライブラリの中で「使いやすかったAPI」を思い浮かべて下さい。それがどのように実装されているのかをソースコードから読み解いてみることを提案します。使いやすいAPIは大抵が良い設計となっているものです。
さらに、机上で学んできたオブジェクト指向やデザインパターン等を「どのように実戦投入しているのか」を知ることができるため、書籍等では理解しにくい「その設計を用いる理由」に強い説得力を得られます。百聞は一見に如かずというやつですね。
大規模ライブラリに対して本腰を入れてガッツリ構造を読み解くも良いですが、Node.jsなどはソースコードへのアクセスが容易い文化なので、例えば何かのライブラリを利用する度にさらっとそのインターフェースの設計や内部構造を探るクセを付けてみると、設計手法やノウハウなどを最速で身につけることができるようになります。

投稿2017/09/21 01:56

tamoto

総合スコア4103

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 23:19

ご回答ありがとうございます!既存の良いフレームワークから学ぶというの、過去にやってきたような気もします。iosフレームワークを参考にjsのオレオレMVCフレームワークを勉強がてら作って見たり。サーバーサイドのphpではLaravelが好きです。ところで、Node.js界隈でコードリーティングにオススメのライブラリーやフレームワークは何かありますでしょうか?
tamoto

2017/09/22 02:53

すみません、自分はnodeは専門外なので、あまり深くまで触れているものが少ないです。 少し古いかもしれませんが、.NETからのつながりで読んだrxjsが、やはりよく設計されたフレームワークでしたね。
退会済みユーザー

退会済みユーザー

2017/09/26 05:06

rxjsは近々勉強してみたいと思っていたところなので、設計面にも着目してみたいと思います。ありがとうございます!
guest

0

個人の主観、環境、経験、流行がものをいうと思います。
あとは属している企業のナレッジ、財産、開発力も影響を受けますね。
いい設計を突き詰めるとキリがないので、
アンチパターンを考えてみると面白いかもですね。

投稿2017/09/21 08:42

Tak1016

総合スコア1408

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 09:53

ご回答ありがとうございます。アンチパターンから学ぶというのは一つの手ですね!
guest

0

「設計」というのはある程度のセンスが必要になってくると思います。センスがない人にいくら教えても、ある程度までは行けるかもしれませんが、どこかに壁があるようで、その壁を乗り越えられないようです。

情熱だけでもダメですし、資質だけでもだめで、まとめ上げていく能力が必要になってきます。

どうやって身につけていくか?はなかなか難しいですが、経験が押し上げてくれる部分は結構あると思います。しかし経験を積むには年数が必要になります。それを飛び越えて力をつけるには並大抵の努力ではなかなか難しいでしょう。

まあ、前を向いてひたむきに進めば、気がついたときにはかなりの実力がついている、だろうと信じて頑張るしか無いですね。

努力と我慢ができないのであれば、そこそこでお茶を濁すか、早々に別の道を探すかのいずれかと。

まあ、偉そうなこと言ってますが、私も結構お茶を濁してきた方です(笑)。

投稿2017/09/21 08:37

PineMatsu

総合スコア3579

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 11:54

ご回答ありがとうございます。一言でまとめると設計力を高めるには時間がかかるから辛抱強く努力し続けろということでしょうか。
guest

0

私もhayatomoさんと同じような設計してます。

つまり、適用できるパターンを知っていて使えるようにしておくこと、テストしやすいようにしておくことです。

また、私の場合はコーディング力が無くこまごまとバグを作るので、バグの原因がソースコードが読みずらかった(=設計が悪い)とみなして改善することです。

どこまでを求めているか分かりませんが、私の場合は結構これだけでそこそこ満足がいくコードに変化していくのが面白いです。(疎結合やネーミングルールなども、自然とこのやり方で、問題として浮かび上がってきます。)

あとは、他の人みてこの人はなぜこんなまずい設計をしたのだろうと考えます。そして、その人の欠点分野についてのパターンを書籍などで調べ、場合によって非公式のリファクタリングをして反面教師とます。(設計が上手い人のは参考になりますが、書籍などの方が身になるなと感じています。)

スキルを細かく上げていくと膨大な量になりそうなので、私は少しずつ身に着けていくつもりでいます。

投稿2017/09/21 08:09

iwamoto_takaaki

総合スコア2883

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

退会済みユーザー

退会済みユーザー

2017/09/21 23:21

ご回答ありがとうございます。自分の方向性は間違ってなさそうで安心いたしました。テストしやすいコードを意識する。パターンの引き出しを増やし、適材適所で使えるようにする。頑張ります!
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問