開発フロー研修 @ Wantedly - Qiita
Githubでの開発 - Issue, Commit, Pull Request, Mention, Code Reviewに関する基本的なルール ゴール 「 チーム で 長期にわたって 生産性を上げる 」 前提 みんながサービス・プロダクトについて自主的に考える組織 エンジニア全員がそれぞれオーナーシップを持ってよりプロダクトを良くすることを考える いわゆるPM職の不在 = コードは書かずに、マネージだけする人がいない これは組織による。(e.g. 外注やディレクター職の存在) けれど、Wantedlyは、多少変化しつつも、より良いサービスを生み出すために、役割の程度の差はあれ全員がプロダクトについて考え責任を持ったほうが良いと考えている。 理想型 図:「青と黄色」のチーム構成が従来の縦割り+統括チーム、「緑(金)色」のところが目指すべきマイクロサービスチーム マイクロサービスチームは、
Gitつらい - 恋しい日々
GUIクライアントを使っている人にGitの扱い方を教える機会というのがここ数年たびたびあって，最初のうちはGUIアプリわからんし，，，とかいってぽーいとぶん投げていた．途中から良くないなと思いGUIアプリとかも見ながらやってたんだけど，いろいろつらい． どういうことかというと，Gitってソース管理の複雑性を解決しないまま，そのまま複雑なソフトウェアとして落とし込んでいて，使う側に学習を強いるアーキテクチャだと思っていて，根本的にはこれがつらい．ソフトウェア書いてるとソースコードの管理が簡単じゃ無い問題なのわかってるから，使い方覚えるモチベーションもあると思うけど，ソフトウェア書いてない人たちが使おうとすると，なぜ複雑なのかを覚えたり学んだりするところからになる．これは通常であれば完全に無駄なコストで，ノーメリットであると言える．もちろんそういうのすっ飛ばしてコマンドだけ教えても良いのだけれ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
