はじめに
“The Zen of Python” というものがあります。 これは、Pythonプログラマが持つべき心構えを金言として簡潔にまとめたものす。 ”Zen” は日本語の「禅」で、ちょっと大げさにいうなら「哲学」とも言えるかも知れません。 私もたまにプログラムを書くのですが、腑に落ちることがいくつもあります。
“The Zen of Python” はプログラマに限らず、回路設計者にとっても結構当てはまる普遍的なことも書かれているので紹介したいと思います。
また、これにインスパイアされて、私がこれまで行ってきたアナログ回路設計を通じて、いろいろ思ったことを “The Zen of Circuit Design” として、さらにこれまでの技術者人生で思ったことを “The Zen of Engineering” としてまとめてみましたので、合わせて紹介させて頂きたいと思います。
The Zen of Python
全部で 20条 (正確には 19条) あるのですが、そのなかで私のココロに響いたものを抜粋して紹介します。
(青字部分は私のコメントです)
■Beautiful is better than ugly.
醜いより美しいほうがいい。
■Simple is better than complex.
複雑であるよりは平易であるほうがいい。
■Flat is better than nested.
ネストは浅いほうがいい。
→ 回路図も階層が深くなるよりフラットな方が読みやすいです。
■Readability counts.
読みやすいことは善である。
→ 回路図も同じだと思います。
■In the face of ambiguity, refuse the temptation to guess.
曖昧なものに出逢ったら、その意味を適当に推測してはいけない。
→ 他人が書いた回路を読むときには特に当てはまります。
その回路を書いた人が側にいるなら直接聞き、いなければ残っているドキュメントを
熟読し、それもなければ納得できるまで熟考しましょう。
■There should be one — and preferably only one — obvious way to do it.
何かいいやり方があるはずだ。誰が見ても明らかな、たったひとつのやり方が。
→ ベターな解は数多ありますが、ベストの解はただ一つだと思います。
■If the implementation is hard to explain, it’s a bad idea.
コードの内容を説明するのが難しいのなら、それは悪い実装である。
■If the implementation is easy to explain, it may be a good idea.
コードの内容を容易に説明できるのなら、おそらくそれはよい実装である。
→ 「コード」 を「回路」に置き換えると、まさしく真理だと思います。
以上、抜粋した 8個について書きましたが、全てを知りたい方は以下のサイトなどをご覧下さい
プログラマが持つべき心構え (The Zen of Python) #Python – Qiita https://share.google/RXsFqc1qgVmCaWxSc
The Zen of Circuit Design
これまで行ってきたアナログ回路設計の様々な経験を通して辿り着いた私の 「禅」を、”The Zen of Python” 風に書いてみました。
■良い回路は美しい。
しかし逆は必ずしも真ではない…
■必要かつ充分が目指すべき回路である。
要求を満足するのに不足はなく、かつ要求に対して過剰でないことが目標。
■回路図へのコメントやドキュメントは、それを見る誰かへのメッセージである。
誰かの中には何年後かの自分も含まれる。
■トラブルが高尚な原因で起こることは稀である。
大概は設計者の不注意や勉強不足、思い込みが原因である。
■懸念していた個所がトラブルになることはあまりない。
何度も疑いの目で見られた回路は大概は大丈夫だが、問題の多くは見向きもされなかった回路
で起こる。
■その回路がそうなっていることには理由がある。
深く考えずに無邪気に既存の回路を改変すると痛い目に会う。
そして多くの場合、自分だけではなく他人をも巻き込む…
■新規回路の開発は魅力的だ。
しかし新規の回路は非常にリスキーだ。
■既存回路の踏襲は安全だ。
しかし既存の回路は確実に陳腐化する。
■故きを温ねて新しきを知る。
生き延びてきた既存回路には、それなりの裏付けと実績がある。
既存の回路を学ばずして新しい回路が生まれることはない。
The Zen of Engineering
“The Zen of Circuit Design” では回路設計についての 「禅」 を書いてみましたが、それをちょっと拡張して回路設計という仕事を通じて思った エンジニアリング についての「禅」 をまとめてみました。
■主観ではなく客観で判断しよう。
自分の判断を過信するな。
それほど自分は賢くない。
■学びて想わざるは即ち暗し、想うて学ばざるは即ち危うし。
これまで身につけた技術を踏襲するだけで新たな創造しないのは暗愚。
しかし創造に拘って過去を省みないのはなお危険。
■すべては費用対効果とリスクから客観的に判断するべきである。
客観的な判断をする上では、信念や情熱や思い入れはノイズでしかない…
■研究開発は足し算だが、製品設計は引き算である。
研究開発は夢をみて、製品設計は現実をみる。
■5分考えて 30分時短しよう。
無計画に実行して手戻りで30分ロスするより、5分考えて手戻りさせない方がよっぽどマシ。
■行き詰まったら一段高みから俯瞰してみよう。
その位置では見えなかった答えが見つかることもある。
■とにかくよく考えよう。
たった一度考えただけで完璧な答えを出したと考えるのは思い上がりだ。
練ると必ず改善の余地があることに気づく。
蛇足
これは補足ではなく蛇足です。 これまでのサラリーマン人生で感じたことを書いてみました。
ちょっと(かなり?)毒が入っているかも知れません…
■必達目標は有益だが、単なる努力目標は無益だ。
前者はその目標に間に合わせるように全力を尽すが、後者は結局努力しないので達成される
ことはない。
■失敗談を聞くのは多くの場合有益だが、成功談を聞くのは多くの場合無益だ。
柳の下に二匹目のドジョウはいた試しはない。
その人が成功したのは単に運が良かっただけかもしれない…
■忙しいと言い訳する奴に限って時間を無駄遣いしてる。
自分の時間だけならまだしも、他人の時間までも…
■ゴールを決めない会議は時間の無駄。
何を議論してどういう結論を出すのかのシナリオがない会議は、会議時間×集めた人数分の
工数のロスでしかない。
■素人ラグビーの組織は最悪。
玄人はボールを前に進めてタックルを受けたらやむなく後にパスするが、素人はタックル
される前にボールを後へパスするので、決して前には進まない。
上から言われたことをそのまま下に振る中間管理職しかいないと、下っ端だけが苦労する…
■上司が議論にピリオドを打とうとする時は、自分の不利を悟っている時
理屈で勝てそうもない時は、力づくで収めにかかる…
■上司があなたに難しい仕事をさようと説得するときには、必ず梯子を用意する。
部下を何人かつけるとか、私もフォローするとか…
でもあなたがウンと言ったらその瞬間に梯子は消失し、あなたはもう降りることはできない…
コメント