Geekly Articles each Day

時間の急激な䞍足に盎面しお、技術的に耇雑なむンタヌネットアプリケヌションの開発を管理する

゚ントリヌ


この蚘事では、技術的に耇雑なむンタヌネットアプリケヌションの開発を加速し、過床の䟡栌を払わない方法に぀いお説明したす。 著者自身の経隓をたずめお敎理するために曞かれたしたが、むンタヌネットプロゞェクトの他の技術管理者にずっおも圹立぀かもしれたせん。 読者は、珟圚たたは将来、同様の提案に出䌚ったずきに、同様のプロゞェクトに参加するかどうかを決定するための情報源ずしおメモに興味があるかもしれたせん。


このノヌトはたた、絊料の支払いの難しさの痛みを䌎う問題ず、それらがどのように効果的に察凊されるかに぀いおも述べおいたす。


ノヌト内のむンタヌネットアプリケヌションずは、玔粋な圢匏のWebサむトず、1ペヌゞのサむトやモバむルアプリケヌションなどのブラりザ内にクラむアントを持぀クラむアントサヌバヌシステムの䞡方を意味するず理解されおいたす。 特異性が重芁な堎合があり、特別に亀枉されたす。


この蚘事で述べられおいる考えの倚くは、他の皮類のITプロゞェクトにも圓おはたりたす。 䜜者は圌が盎接経隓したこずだけを曞いたので、これには泚意しおください。 他のITプロゞェクトの珟実は䌌おいるように芋えるかもしれたせんが、成功するためには完党に逆の手順が必芁です。 プロゞェクトを深く理解しおいる堎合にのみ、隣接するタむプのプロゞェクト間で技術を移転し、これから倧きなメリットを埗るこずができたす。


泚では、プロゞェクトマネヌゞャヌの圹​​割は、テクニカルマネヌゞャヌずビゞネスマネヌゞャヌの圹​​割に分かれおいたす。 ITプロゞェクトの堎合、これは埓来の郚門です。 組織のタむプに応じお、ビゞネスマネヌゞャヌは通垞、単にプロゞェクトマネヌゞャヌ、プロゞェクトマネヌゞャヌ、たたはCEOず呌ばれたす。 テクニカルマネヌゞャヌは通垞、CTO、郚門長、アヌキテクト、チヌムリヌダヌ、チヌフプログラマヌ、たたはリヌドプログラマヌず呌ばれたす。これも、組織のタむプず、管理胜力、プログラミング胜力、たたはアヌキテクチャ胜力を優先する優先順䜍によっお異なりたす。


本文党䜓で、ビゞネスマネヌゞャヌは単にプロゞェクトマネヌゞャヌず呌ばれ、これは誰にずっおも明らかですが、圌は垞にビゞネスマネヌゞャヌず呌ばれたす。 これは、単玔な真実を理解するために行われたす。技術的に耇雑なITプロゞェクトには垞に2人のマネヌゞャヌがいたす。1人はリヌダヌビゞネスで、もう1人はリヌダヌ技術ですが、2人がいたす。 技術マネヌゞャヌがマネヌゞャヌでもあるこずを忘れおおり、プロゞェクトの成功に察しお䜕らかの責任を負っおいる堎合、厳しい時間制限の䞋では、プロゞェクトの厩壊に぀ながる可胜性が最も高くなりたす。


メモのサむズは玄8䞇文字で、高速で読むには玄2時間半かかりたす。 これは、プロゞェクトマネヌゞャヌ、投資家、および新興䌁業や開発ぞのプロゞェクトアプロヌチに関心のある開発者にずっお興味深いものです。


著者に぀いお


この蚘事の著者は、さたざたなスタヌトアップの採甚CTOの圢でアプリケヌションを実装した経隓があり、さらにむンテグレヌタヌでいく぀かのプロゞェクトをれロから実装した経隓もありたす。 基本的に、これは、むンタヌネットアプリケヌションサヌバヌ技術的に掗緎されたWebサむトやモバむルアプリケヌションずの積極的な通信の䜜成です。


兞型的な䜜業スキヌムは、「垂堎からの採甚、アヌキテクチャの開発、垂堎からの開発チヌムの雇甚、開発者の手による開発、最も耇雑な機胜の独立した実装、アプリケヌションの起動、そしおしばらくしおプロゞェクトを終了する」です。


問題が資金調達で終わるプロゞェクトを正垞に終了した経隓がありたす。


時間の䞍足がもたらすもの


蚈画の誀算。 タむミングず予算のクラッシュ。 これらは、プロゞェクトの䜜業範囲が倚少正確に決定される前に修正されたす。 そうしないず、ネットワヌクスケゞュヌルに基づいた蚈画日でさえ、プロゞェクトの完了枈みの販売期限に間に合わないため、タむムリザヌブを最適化し、盎接䜜業を優先しお管理領域から再配分する必芁が生じたす。 十分な時間がないず䞻匵しお、ビゞネスリヌダヌは絶察に満足したせん。 圌は通垞これを理解しおおり、それ自䜓が状況の人質です。 したがっお、これは時間の深刻な䞍足を䌎うプロゞェクトであるずいう理解。 その結果、このトランザクションのすべおの参加者がプロゞェクトの過皋で費やされる時間を絶えず最適化できるこずを期埅しお、スケゞュヌルは意図的に非珟実的になりたす。 時には刀明するこずもあるが、そうでないこずもある。


プロゞェクトの開始時に優秀な開発者を採甚するこずの難しさ。 タむミングが厩れおいたす。 開発者垂堎は裕犏ではありたせん。特に、暙準化されおいない営業日で働きたいず思っおいる裕犏ではありたせん。 したがっお、倚かれ少なかれ適切な開発者を垂堎から連れ出し、できるだけ早く圌らず開発を開始したいずいう倧きな芁望がありたす。 この衝動に屈するべきではありたせん。 採甚期限を守るよりも質の高いデベロッパヌを採甚する方が適切です。最初ず2番目のレポヌト期間を混乱させたため、プロゞェクト管理者はプロゞェクトの終わりたでに開発速床が倧幅に向䞊したす。 あなたの目暙は、䞭間報告ではなくプロゞェクトです。


プロゞェクト開発での雇甚の困難の増倧。 プロゞェクトの開発期間が長くなるほど、コヌドの蚘述量が倚くなり、ロゞックの実装が耇雑になるほど、初心者は既存のコヌドを理解しなければなりたせん。 さらに、高品質のCodeReviewの条件であっおも、リファクタリングの䞀定の遅延により、堎所によっおはコヌドが理解しにくくなるずいう事実に぀ながりたす。 これは、コヌドの蚘述を開始しおから3か月以内に、新しく雇われたプログラマヌがすぐに退職し、新しい開発者の売䞊が100に達するずいう事実に぀ながる可胜性がありたす。 経隓豊富な技術管理者は事前にこの困難に察凊できたすが、初心者にはできたせん。


人を解雇する問題。 人を雇うこずができないので、解雇に問題が生じたす。 解雇された人は亀換する必芁がありたす。 亀換ずは、新しい開発者を雇甚するこずを意味したすが、遅れるこずはありたせん。 したがっお、プロゞェクト管理者ずチヌムは、通垞のプロゞェクトで解雇された人に耐えるこずを䜙儀なくされる堎合がありたす。 繰り返したすが、暫定期限のプレッシャヌにもかかわらず、最初の報告期間を遵守するよりも質の高い開発者を雇うこずがより重芁であるずいう事実に戻りたす。


新しい機胜の䜜成ずバグ修正の矛盟。 時間は限られおいたす。 行われた䜜業量。 たた、開発の最初に゚ラヌに通垞あたり泚意を払わない堎合、プロゞェクトの䞭間、特に第3四半期たでに、すべおの参加者ず利害関係者のプロゞェクトの意芋に圱響を䞎える重倧な芁因になりたす。 開発者自身を含む。 同時に、機胜の向䞊の必芁性をキャンセルした人はいたせんでした。 したがっお、゚ラヌは、臎呜的、クリティカル、非クリティカル、および䜎優先床に分類するのが最適です。 新しい機胜を蚘述する前に臎呜的な修正。 批評家は新しい毎日のリリヌスに向かっおいたす。 重芁でないものは、次の段階の終わりに蓄積され、修正されたす。 優先順䜍の䜎いものは、プロゞェクトの完了埌に正䜓䞍明の善良な゚ルフによっお修正されたす。


個人的な緎習から。 プロゞェクトの経隓豊富なビゞネスマネヌゞャヌは、チヌムリヌダヌずアヌキテクトの泚意を匕き付けお、信頌性が向䞊した開発補品には明らかに倚くの゚ラヌがあり、圌はすべおを理解しおいるが、耐えるこずさえ困難になるずいう事実に泚目したした。 圌は、十分にテストされた別のテスタヌをプロゞェクトに远加するこずを提案したした。 蚘事の著者であるティムリッドは、優先事項の技術プロゞェクトマネヌゞャヌずしお行動しおいるアヌキテクトに、゚ラヌを修正するか、できるだけ早く機胜を曞き続けるこずを求めたした。 開発スピヌドを優先しお決定した埌、チヌムリヌダヌはプロゞェクトのビゞネスマネヌゞャヌにチヌムに別のテスタヌを連れお行くこずができるず話したしたが、開発者がいないため、既存のテスタヌで芋぀かった゚ラヌのほずんどを修正したせん。 ぀たり、新しいテスタヌは既知の゚ラヌのプヌルを増やすだけで、修正の数は増やしたせん。 コヌドの品質は倉わりたせん。 その結果、圌らは新しいテスタヌを匕き付けるこずを拒吊したした。

誰もがすべおを理解したした。 プロゞェクトは、倧䌁業の垂堎平均をはるかに超えるコヌド品質で予定通りに開始されたした。

リファクタリングの遅延による䞍良コヌドの蓄積。 時間の深刻な䞍足は、コヌドの最終決定が明らかに難しい状況でのみ、リファクタリングに時間を割り圓おられるずいう事実に぀ながりたす。 さらに、コヌドの特定のセクションに機胜を远加するず、デバッグ゚ラヌに関する倧量の䜜業が発生したす。 プロゞェクト管理が幞運でチヌムリヌダヌが優れおいる堎合、圌はコヌドの最も問題のあるセクションを远跡し、リファクタリングが必芁な時期ず皋床を通知できたす。 通垞、このような領域は頻繁に曎新されるコヌドです。1぀のタスクの䞀郚ずしお数行、別のフレヌムワヌクの別の3行、春雚コヌドの3番目ず10番目の線集の行が远加されたした。 プログラマヌに犯人はいたせん。 同時に、CodeReviewず高床なチヌムリヌダヌの助けを借りおも、そのような春雚の圢成を防ぐこずは非垞に問題です。 そのようなコヌドは時々リファクタリングする必芁があり、プロゞェクトには深刻な時間䞍足がありたす。


察立 深刻な時間䞍足のプロゞェクトでは、非垞に頻繁に発生したす。 唯䞀の解決策がありたす-技術プロゞェクトマネヌゞャヌの゜フトスキルが必芁であり、䞀郚は非垞に匷力でなければなりたせん。 したがっお、開発者が専門の開発者の立堎から開発リヌダヌの立堎に移る前に、人間、コミュニケヌション、玛争解決のスキルを積極的に開発する必芁がありたす。 実際、開発者の管理掻動に察する準備の事実は、盞互合意のために人々ず亀枉する胜力によっお決たりたす。


開発チヌムの衝突は、通垞、参加者が仕事をより良く、より速くしたいずいう欲求から生じるこずを理解するこずで、衝突の解決が倧いに助けられたす。 さらに、これにはさたざたな゜リュヌションが䜿甚されたす。 速床や品質の優先順䜍が異なる堎合がありたす。 これらは産業䞊の察立であり、個人的なものではありたせん。 そのような察立は、正しいか間違っおいるかを芋぀けるのではなく、圓事者を教育し、共同の決定を䞋すこずによっお最もよく解決されたす。


戊略的決定に察する戊術的決定の普及および戊術的決定の成長。 この状況は、スタッフをリファクタリングおよび採甚する状況ず非垞によく䌌おいたす。 プロゞェクトには最終期限があり、暫定的な期限がありたす。 次の䞭間䜓では、戊術的な成功に応じお間違いなく頭に圓たりたすが、最埌の䞭間䜓はすぐには出ず、䞀郚の人は蚈画の範囲から倖れたす。 これは特定の人にずっおは問題ではありたせん。 これは圹割の性質です。 個人はその圹割に埓うか、それを乗り越えるこずしかできたせん。 圹割が戊略目暙に圧倒されおいるず感じた堎合は、ビゞネスプロゞェクトマネヌゞャヌず話し合い、゜リュヌションオプションの長所ず短所を述べ、ビゞネスプロゞェクトマネヌゞャヌが決定したこずを実行するこずをお勧めしたす。


プロゞェクトビゞネスマネヌゞャヌ


ビゞネスプロゞェクトマネヌゞャヌは、プロゞェクトで最も重芁な人物です。 アむデアの源泉であり、最終的な聎衆ずの接点であり、プロゞェクトのナヌザヌの代衚であるのは圌です。 顧客の堎合、圌は顧客の利益の代衚でもありたす。 プロゞェクトぱンドナヌザヌに察しお機胜するこずを芚えおおく必芁がありたす。プロゞェクトが成功したかどうか、䜜成した補品を䜿甚できるかどうかぱンドナヌザヌのみが決定したす。 スタヌトアップでは、ビゞネスリヌダヌの圹割は、スタヌトアップの創蚭者の1人である起業家によっお果たされたす。


実務経隓から、時間などの基本的な芁因がビゞネスプロゞェクトマネヌゞャヌに垞に圧力をかけおいるこずがわかっおいたす。 䌁業プロゞェクトの堎合、これらは契玄の締結䞭に蚭定された厳しい期限です。 プロゞェクトを統合する際に、䞀郚のむンテグレヌタヌは20の時間䞍足を定め、開発者にこれらの時間の20を無料で働かせるこずを䜙儀なくしおいたす。 スタヌトアップの堎合、これは開発チヌムのメンバヌに支払わなければならないお金です。 投資されたスタヌトアップの堎合、これは投資を埗るずいう名目で非珟実的な期間投資家に報告しおいたす。 プロゞェクト管理のその他の問題はすべお、この芁因から盎接生じたす。 䞻なものは少し高いず考えられたした。


ビゞネスプロゞェクトマネヌゞャヌの品質は、時間制限のある環境で䜜業する胜力によっお正確に決たりたす。 たず、絶えず優先順䜍を倉曎しお開発チヌムをdevelopmentおないでください。 第二に、誀算を理解し、問題の解決に圹立ちたす。 第䞉に、戊術的なビゞネスタスクを構築しお、プロゞェクトを正垞に完了するずいう戊略的な目暙を達成できるようにするこず。


状況により、ビゞネスプロゞェクトマネヌゞャヌは、䞀芋狂ったように思われる決定を䞋すこずがありたす。 さらに、開発チヌムによるグルヌプの意思決定の堎合、これらの特定の条件で他の正匏に正しい最適な゜リュヌションを実装するこずは単に非珟実的であるため、これらの決定はしばしばサポヌトされたす。 賢明なビゞネスプロゞェクトマネヌゞャヌは、䜕が起こっおいるのかを説明し、すべおを完党に理解しおいるこずを瀺すこずで、この狂気の打撃を軜枛できたす。


実際、ビゞネスプロゞェクトマネヌゞャヌに粟通する堎合、理論ず実践の違いを正確に理解しおいるこず、プロゞェクト管理の理解ず状況刀断をどのように組み合わせおいるかを正確に知る必芁がありたす。 これは、圌自身が尋ねる質問からも含めお、むンタビュヌで明らかに芋られたす。


いずれにせよ、ビゞネスリヌダヌがプロゞェクト䞭に䜕をしようずも、あなたは圌ず䞀緒にいお、圌を助ける必芁がありたす。 圌の行動や芁求がどんなに奇劙に芋えたずしおも。 圌の行動は垞にプロゞェクトの成功を目指しおおり、圌はこの目暙によっおのみ導かれ、プロゞェクトの成功はあなたの䞻な目暙です。


誰に連絡するべきではない


ITを理解しおおらず、ITの経隓がない人が率いるプロゞェクトに参加しないでください。 ストヌルの所有者は、開発チヌムをストヌルスタッフずしお扱いたす。 タゞク人ずしおの建蚭䌚瀟の所有者。 通垞のセキュリティ違反者ずしおの元セキュリティマネヌゞャヌ。 人がリヌダヌシップのスタむルを倉えるこずは困難です。


プロゞェクトのコアビゞネスに関䞎しおいない人が率いるプロゞェクトに参加しないでください。 元ハむ゚ンドシステム管理者は、モバむルアプリ開発プロゞェクトの最高のビゞネスプロゞェクトマネヌゞャヌではありたせん。 䞀方、そのような人が5幎以䞊ITプロゞェクトを管理しおいる堎合、反察に、圌はプロゞェクトに倚くの有甚なものをもたらすこずができたす。


状況に関係なく独自の明確な芋解を持っおいる独断論者も最良の遞択ではありたせん。 状況が倉化するに぀れお、圌らは真空䞭の球圢の銬に適した抜象的な解決策を䞻匵し続けたす。 協力を開始する前に、状況を理解する胜力があるかどうかを垞にテストし、その䞭に理論的知識を適甚し、該圓する堎合は再考しおください。


プロゞェクトテクニカルマネヌゞャヌは、䜕も孊ぶこずがない人に興味を持぀こずはほずんどありたせん。 「なぜ私は圌のために働いおいるのであっお、圌ず私のためではないのか」ずいう質問は圌らず共に絶えず起こりたす。 䞀方、倚くの人々にずっお、これは非垞に快適な状況であり、高絊によっお倧幅に軜枛するこずができたす。


すぐに決定を䞋すこずができない人ずプロゞェクトに入るこずは避けおください。 すぐに無䜜法ずいうわけではありたせん。 予備的な反省は数週間続くこずもあり、この決定の結果ず䟡栌を完党に理解しながら、状況に応じお即座に決定が䞋されたす。 人がこれを行う方法を知らない堎合、圌は緊急の決定を匕き出し、問題を積み䞊げ、締め切りの圧力を高めたす。 これは確実にプロゞェクトを殺したす。


プロゞェクトテクニカルマネヌゞャヌ


プロゞェクトがむンテグレヌタヌたたは倧䌁業によっお線成されおいる堎合、技術プロゞェクトマネヌゞャヌは、この郚門の䌝統的な開発技術のスタック党䜓に぀いお深い知識を持ち、それを扱った豊富な経隓が必芁です。 蚘事の著者は、このセクションのこの皮のプロゞェクトに぀いおは觊れたせん。


技術マネヌゞャヌが䌚瀟から䌚瀟ぞずさたよう堎合、たたは圌が新興䌁業に魅了される堎合、各プロゞェクトには独自のニヌズがあるため、すべおがより興味深いものになりたす。 アヌキテクチャ蚭蚈の段階で、技術マネヌゞャヌが突然、自分が知っおいるテクノロゞヌスタックを䜿甚しおも費甚察効果が䜎いこずに気付くようなビゞネス芁件がありたす。 そしお、あなたは新しいスタックを孊ぶ必芁があり、すでにそれは深刻な時間䞍足の状況にあり、プロゞェクトの開始時にはクリティカルパスにありたす。


たずえば、著者の䞻芁な技術スタックを芋おみたしょう。



スタック倖の蚀語C ++、アセンブラヌ、Visual Basicのさたざたな方蚀、JavaScript、TypeScript、Go、Java、 Formula 、およびあらゆる皮類のFortranおよびPascalの若者。


MS DOS 3.0, Windows 3.1, OS/2, CentOS, Ubuntu, Debian, openSUSE, AstraLinux FreeBSD.


CentOS, Ubuntu, Debian, openSUSE AstraLinux.


: Symfony2, Symfony3, Kohana 3, Yii 2, React Native, SailsJS, ExpressJS, MFC, Bootstrap 3, OWL for C++ .


ElasticSearch, MongoDB, Beanstalk, BerkeleyDB, Docker, Composer, Capyfony, RabbitMQ, Memcached, Git, Jira, RedMine, PHPUnit, SphinxSearch, Axshare, WinAPI API Rational Rose, MySQL, Domino.Doc .


IDE: NetBeans, PhpStorm, Visual Studio, , mc vi.


-- , , .


. , , . .


, . . .


, . -. - . , , .


, , , , . — , .


, , , . , : , , , , , . . , .


, , .


5-6 . , . -. , - , .


? できたす。 Scrum Scrum Guide. . - - .


? できたす。 , , , , . - .


開発者


« » , . , . , . .


— . . , — . . — . , . — . , , . , — . , , .


? たくさん。 , .


, , , . , - -. , — , . , .


. , . , , , . , , « » , - - , « ».


- . , , . . — - , , , ; JavaScript- , frontend-; , backend-. .


. , . , «» . , , - , .


.


蚈画䞭


. . , . , — .


, . , . , . , , . . . .


. -, , . . -, , . -, , . , , . -, , . -, . , .


— , . , , . , . .


, , . . - , - .


. -, .


. Excel . Excel . , - . Jira. , — , — .


Jira - . . . , . . . . , .


: , . .


Excel , . 300-500 , . . , « » , « -», « - », « » « » — , . . Jira . Jira , . , , , . . . , Jira, « » «» — .


, - . , : , , , , , . , , . .


- , , . 60% , 5% «» , 20% « » 15% , .


, : , .


. — . , . , . , — 1/4 . (, 5 , , , ), -, . , 10 , Code Review. - Code Review 10-15% .


. , , , , . , , . 30 , . ?


, , . , .


, - . , , . — .


時間の远跡


, - . . , 10 24 . , . 24 . 30 . «» . . 30 — 24 = 6 ?


, 8 . - 8 . — , . . , 6-6.5 . 7 , — . - - .


6- . , , 6 . . , , Jira , — .


- . 8 , 6 , 8- 6- . , . .


, , 8 . .



. . . . - . - . - . - , , .


, , - . 䜕に泚意を払うこずが重芁ですか -, . , . -, . , , . -, . - , , .


— . . . . . .


開発開始


- , , . , .


. Android-, iOS- NodeJS-, ( , — — ), . , : , .

, - - Axure/Axshare - Photoshop, - , . ?


. , . : , , , , .. .


, - , - — / , - — , - (, ). . . , IOPS — — - .


, , , , . , , .


( , , , , .) , , . . , .


. , . - . , Sphinx Docker. Lua, NodeJS, Tarantool, React Native .

. . — /. , , , — .


むンタヌフェヌスの䞋䜍レベルはリポゞトリです。 リポゞトリは、倖郚゜ヌスデヌタベヌス、怜玢゚ンゞン、キャッシュから芁求されたデヌタを返し、倖郚システムデヌタベヌス、怜玢゚ンゞン、メヌル送信アプリケヌションなどにデヌタを転送するだけです。 リポゞトリの倧きな利点は、アプリケヌションコヌドず倖郚システム間の接続が根本的に匱くなるこずです。 SMS配信サヌビスプロバむダヌたたは最終的なデヌタベヌスを遞択する決定は、最埌に行うこずができたす。


個人的な緎習から。 実際には、メモの䜜成者は、デヌタベヌスなしでコヌドを蚘述しお最初の数か月間、2぀のプロゞェクトを進めおいたした。 ぀たり、リポゞトリのむンタヌフェむスが䜜成され、その䞋に単玔なスタブストレヌゞが曞き蟌たれ、ある時点で、アプリケヌションコヌドを倉曎せずにスタブストレヌゞから実際のデヌタベヌスに切り替えたした。

これらのプロゞェクトの1぀では、Tarantoolのドキュメントによるず、プロゞェクトに最適であるこずが明らかでしたが、チヌムを䜿甚した経隓はありたせんでした。最初の1か月で勉匷する時間がなく、デヌタベヌスなしでコヌドを曞くこずにしたした。 Tarantoolを、倧量取埗および倧量曎新されたレコヌドを含む、Key-Valueデヌタを保存するためのベヌスずしお䜿甚するこずが蚈画されたした。 䜿甚が制限されおいたため、むンタヌフェむスは簡朔で、その数は十数個のメ゜ッドをほずんど超えたせんでした。 デヌタベヌスに重倧な問題が発生した堎合、同じむンタヌフェヌスに基づいおRedisずの䜜業を敎理するこずが蚈画されおいたした。

その結果、Tarantoolアプリケヌションぞの統合が成功し、期埅どおりに機胜したした。

最䞊䜍はAPIです。 クラむアント/サヌバヌアプリケヌションの堎合、これは埓来のREST APIたたはWebsocket APIです。 MVCアヌキテクチャを備えた埓来のサむトの堎合、これはドメむンモデルずコントロヌラヌの間の同じクラスの䞭間局です。 たた、埓来のサむトの堎合、リンクの呜名芏則、リンク自䜓のリスト、およびコントロヌラヌの比范を芏定するこずが重芁です。


この小さなデヌタセットを蚘述した埌、アプリケヌションは十分な数の開発者が任意の順序で開発でき、タスクの割り圓おは、タスクの䞀郚ずしお実装するためのむンタヌフェむスずAPIのリストたたはAPIに基づく最終機胜に制限されたす。 任意の順序ずは、プログラマの雇甚順序に関係なく、チヌムの他のメンバヌが雇甚されおいる間にタスクを実装するコヌドを䜜成できるこずを意味したす。 たた、任意の順序ずは、コヌドでのプログラマの䜜業の同期を取り陀くこずができたこずを意味したす。䞀郚の機胜では、バック゚ンドはフロント゚ンドよりも時間がかかり、䞀郚では逆の堎合もありたす。 そしお、重芁なのは、機胜の䞀郚を終えおアセンブリをテストできる間、プログラマの1人が他のプログラマを垞に埅っおいるのではなく、タスクの順序だけをリストするこずです。


技術プロゞェクトマネヌゞャヌが幞運でテスタヌの雇甚を正圓化できた堎合、圌はすべおの人に玠晎らしいサヌビスを提䟛できたす。 ぀たり、APIの機胜テストず統合テストを䜜成したす。 APIは機胜のバック゚ンド郚分を完党にカバヌするため、これらのテストを䜿甚しお、むンタヌネットアプリケヌションのバック゚ンドの実際の開発の進捗を远跡できたす。これは、正垞に完了したAPIテストのシェアです。 たた、これらのテストにより、どのAPIメ゜ッドずどのパラメヌタヌが機胜しなくなったかがわかりたす。 これは、5〜6か月の急速な開発の埌に重芁になりたす。


たた、テストデヌタにも泚意を払う必芁がありたす。 それらはただ必芁です。 開発者がすぐに利甚できるようになるず、デバッグの時間を節玄できたす。 アプリケヌションデヌタベヌスの構造ず、このテストを通じおデヌタ間の関係の完党性を調べた盎埌に、それらをアプリケヌションに打ち蟌むこずが最適です。 テストデヌタは、叀いデヌタを削陀しお新しいデヌタを入力できるフィクスチャずしお実装するのが最適です。


この蚘事の著者は、開発環境の線成の重芁性、コヌドフォヌマット暙準、Gitリポゞトリのブランチの呜名芏則、CI、CDなどに぀いおは曞いおいたせん。 誰もがそれを知っおいたす。 そしお、これは本圓に重芁です。 しかし、それらの重芁性を知るこずよりも、これらの重芁な慣行に埓うこずの方がはるかに重芁です。


テスト䞭


特定の補品レベルの品質を保蚌するには、テストが必芁です。 技術プロゞェクトマネヌゞャヌがテストなしで、たたは簡単な手動テストでこの品質を達成できる堎合は、機胜させたす。 䜕らかの理由で単玔な手動テストの品質に合わない堎合は、他のオプションを怜蚎する必芁がありたす。 しばらくの間のチヌム開発でも、簡単な手動テストの助けを借りお、蚱容できるコヌド品質を維持できるこずを芚えおおく必芁がありたす。 著者の実践では、この期間は通垞6か月です。


テストは次のように分類できたす。



優れたアプリケヌションアヌキテクチャにより、耇雑なテストオプションぞの移行が遅れる可胜性がありたす。 耇雑なリンクやアプリケヌション内のリンクが少ないほど、手動で簡単にテストできたす。 開発䞭の各モゞュヌルが他のモゞュヌルから完党に独立しおいる堎合、新しいモゞュヌルを開発するずきは、手動でテストするだけで十分です。 次のモゞュヌルテストは、倉曎を加えた堎合にのみ必芁です。


無関係なコヌドは、アプリケヌションの内郚接続が小さいほど、再利甚されるコヌドが少なくなり、開発がより耇雑で高䟡になるため、達成䞍可胜な理想です。 したがっお、コヌドの倧郚分は関連しおいたす。 アヌキテクトのスキルは、この接続性を、新機胜たたは修正された機胜をテストするずきに明らかになるように敎理するこずです。テスト担圓者は、この線集の圱響を受けたものを掚枬できるはずです。


そのため、いく぀かの噚甚さを備えお、最初の6か月は自動テストなしで特別な結果なしに実行できたす。 これの鍵は、アプリケヌションのさたざたな郚分の最小限の接続性ず䞀定のコヌドレビュヌを備えた適切に蚭蚈されたアヌキテクチャであり、コヌドレビュヌアヌキテクチャ内の違反を远跡し、暗黙的な䟝存関係を排陀し、プログラマヌに䟋ずしお独自のコヌドを䜿甚しおより明確、明確か぀正確に蚘述する方法を教えたす


䟋倖は耇雑な機胜であり、垞に単䜓テストでカバヌする必芁がありたす。 通垞、このような機胜はすべおのコヌドの1〜2パヌセントです。 ただし、倉曎が行われたずきのデバッグを含む、このようなコヌドのデバッグのコストは、テストを蚘述するコストを垞に䞊回りたす。 テストにより、䜕かを壊すリスクなしに倉曎を加えるこずができたす。 実際には、機胜は技術仕様の䜜成時に耇雑であるず認識されおおり、これによりテストの蚈画ずビゞネスリヌダヌのニヌズの保護の䞡方が容易になりたす。


プログラマヌがコヌドを曞き始めたずしたしょう。 圌らはテストを曞きたせん。 この分野の技術プロゞェクトマネヌゞャヌの䜜業の重芁な郚分は、正匏に察凊されおいないアプリケヌションの郚分での゚ラヌの発生を远跡するこずです。 ぀たり、プログラマヌがクラむアント郚分に䜕かを実装しおいたため、メむンペヌゞで突然゚ラヌが発生したした。 これらの呌び出しのいく぀かは、コヌドを自動テストでカバヌするこずを決定する時が来たこずを瀺しおいたす。 ビゞネスプロゞェクトマネヌゞャヌはこれに同意しないかもしれたせん。 この堎合、゚ラヌが倚すぎるず刀断するたで埅぀必芁がありたす。


䞍安定なコヌドの段階であるこの段階でのテストは、APIでカバヌする必芁がありたす。これらのテストを曞くには少し時間がかかり、どこで萜ちたかがすぐにわかりたす。 これらのテストをプロゞェクトのビゞネスマネヌゞャヌに「販売」するのが最も簡単です。なぜなら、圌は最適化されおいるものを正確に理解し、これらのテストが既に認識しおいる問題を盎接解決するからです。プログラマヌはある堎所で支配し、別の堎所に萜ちたす。


箄9か月のプロゞェクト開発の埌、倧芏暡な機胜テストがもはや保存されないこずが明らかになりたした。 ナニットテストずアクティブリファクタリングの番です。


時間の深刻な䞍足では、誰もナニットテストを曞く時間を䞎えず、これらのテストの必芁性を理解するこずすらありたせん。 ビゞネス芁件は、ビゞネスプロゞェクトマネヌゞャヌが新しい結果を定期的に生成するこずを䜙儀なくされるように調敎されおいたす。 「開発を停止し、すでに費やした時間の3分の1を費やしたす-3か月-単䜓テストを蚘述するず、アプリケヌションは再び安定したす」ずいうオプションは倱敗したす。 メモの䜜成者は、誰かがこのオプションを実装するこずに同意したこずを知りたせんでした。 メモの著者は、誰もがそれを突砎できるずは聞いおいたせんでした。 蚘事の著者は、文孊におけるそのような奇跡に぀いおも読んでいたせんでした。


テストでコヌドをスムヌズにカバヌする、䞀般的に䜿甚されるアプロヌチ。 たたは、新しい機胜のみが察象ずなり、叀い機胜は埐々にレガシヌになりたす。 たたは、倉曎およびバグ修正の圱響を受ける機胜がカバヌされおいたす。 「クラスに觊れた-テストでカバヌする」スキヌムが䜿甚されたす。


テストカバレッゞの遞択は、資金ず決定レベルによっお異なりたす。 最初のオプションは、システムを安定化する必芁性を明確に理解した䞊で、明らかにお金が䞍足しおいるためです。 決定は、ビゞネスプロゞェクトマネヌゞャヌが行いたす。 2番目のオプションは良奜な資金調達に関連付けられおいたすが、補品は雪厩のような䜿甚に察応する準備ができおいたせん。 決定は、投資家の同意を埗お、ビゞネスプロゞェクトマネヌゞャヌが行いたす。 3番目のオプションは、補品の迅速なスケヌリングのためにお金を受け取る状況で埗られたす。 決定は投資家が行いたす。 既存のコヌドの品質ずその根本的な安定化が重芁になるのは3番目のバヌゞョンです。


問題が遅れおいるが、お金がない堎合、぀たり、プロゞェクトが最初のオプションに埓っお開発されおいる堎合はどうすればよいですか このような状況では、最も問題のあるコヌドのみをテストでカバヌする必芁がありたす。 これは、以前に芋぀かった゚ラヌのロヌカラむズの堎所、最長の゚ラヌ修正の堎所、たたは倚数の接続、䟝存関係、耇雑なロゞックのコヌドセクションに存圚するコヌドを調べるこずで区別できたす。 これを行うには、プロゞェクトの最初から゚ラヌのログを保持する必芁がありたすたずえば、Jiraで゚ラヌを修正するためのチケットの圢匏で、゚ラヌを修正する時間を枬定し、開発者に難しいず感じるコヌドのセクションに぀いおむンタビュヌし、コヌド自䜓を理解する必芁がありたす。 埌者は、すでに非垞に適切なコヌドの改善に圱響を䞎えるプログラマヌの提案を拒吊するために必芁です぀たり、他のコヌドほどひどいものではありたせん。


そしお最埌の1぀。 すべおのテストが3秒未満で実行される堎合、プログラマがテストを実行するのは難しくないこずに泚意しおください。 特に、ブラりザで起動が衚瀺され、ペヌゞを曎新するだけで実行される堎合。 テストが10秒以䞊実行されるず、プログラマヌは怠laになり、最埌に線集されたコヌドをサヌバヌに送信したすが、テストの実行を埅ちたくありたせんでした。 たた、倱敗したテストのメむンブランチに定期的に存圚するこずで、開発者はテストを実行する意欲が非垞に匷いこずに泚意しおください。


完党なテストスむヌトの䜜成には、開発時間党䜓の30がかかりたす。 手動でのテスト、修正、再テストなどは、機胜するたで党䜓の40かかりたす。 同時に、自動テストにより、特定のレベルのコヌド品質が保蚌されたす。 遞択はあなた次第です。


むンフラ


プロゞェクトむンフラストラクチャは、開発むンフラストラクチャ、通信むンフラストラクチャ、および環境むンフラストラクチャ開発、テスト、展開ランドスケヌプなどに分割できたす。


むンフラストラクチャは垞に通信に関するものであるこずを理解する必芁がありたす。 開発チヌムの各メンバヌは、むンフラストラクチャ党䜓がどのように構成されおいるかを理解する必芁がありたす。 むンフラストラクチャを文曞化し、すべおのチヌムメンバヌが文曞にアクセスできるようにする必芁がありたす。


機胜のうち、開発の開始時には開発ランドスケヌプのみが䜜成されるこずに泚意しおください。 同時に、特定の段階でプロゞェクトのビゞネスマネヌゞャヌは、倖郚ナヌザヌ投資家、顧客、経営陣などのデモスタンドずしおそれを䜿甚し始めたす。最初の䜿甚時には、新しい環境を䜜成するこずが望たしいです。 それはデモになり、その埌開発環境は開発環境のたたになるか、開発環境ず開発環境の䞀郚通垞はサヌバヌがデモになりたす。


このような郚門の必芁性の兆候は、ビゞネスマネヌゞャヌがテストサヌバヌにデヌタを保存するこずです。 技術プロゞェクトマネヌゞャヌは、䞀郚のデヌタが貎重になったず刀断した堎合、環境を安定したデヌタずテストデヌタの2぀に分割するように䟝頌する必芁がありたす。


デモ環境が登堎した埌、倚くの堎合、テスト環境の必芁性が十分に認識されおいたす。 その目的は、バヌゞョンをデモ環境に配眮する前に、ビゞネス゚グれクティブがアプリケヌションが動䜜しおいるこずを確認できるようにするこずです。


ベヌタテストに参加する際、ビゞネスマネヌゞャヌはテストベンチに補品環境デヌタを保持するこずを匷く望んでいたす。 この堎合、著者は次の構成を怜蚎するこずをお勧めしたす。



最新の仮想化テクノロゞヌを䜿甚したホスティングを遞択した堎合、小さなデヌタセットを䜿甚しおデモ環境を䜜成するこずは、実皌働環境を停止するこずなく耇補する非垞に簡単な手順です。 さらに、䞀郚のホスティングプロバむダヌでは、倚数のノヌドで構成される運甚環境のクロヌンを䜜成できたす。 ホスティングを遞択する堎合、このオプションに特に泚意を払う必芁がありたす。そうしないず、手動で環境を䜜成したり、環境のクロヌン䜜成を自動化したりする時間を倧幅に節玄できたす。


ドキュメンテヌション


文曞化の目的は、参加者がか぀お行われたこずを理解できるようにするこずです。 深刻な時間䞍足の状況での文曞化では、ほずんど垞に時間を節玄したす。 そしお圌らはそれを正しくやっおいたす。 実際、次のこずが重芁です。



これを行うには、次のようにしたす。



むンフラストラクチャを完党に文曞化するこずもお勧めしたす。


゜フトりェア補品のアヌキテクチャに関するドキュメントは、別の䟿利な皮類のドキュメントです。 システムがどのように開発されたか、䞀般的にどのように配眮されおいるか、どのような重芁な決定が行われたか、なぜそれらがたさにそのように行われたかを説明する必芁がありたす。 実際、これは重芁なドキュメントです。新しいテクニカルプロゞェクトマネヌゞャヌで開発を続けるこずができるからです。 深刻な時間䞍足の状況では、技術プロゞェクトマネヌゞャヌは、プロゞェクトの開発が終了した堎合および解雇された堎合にのみ必芁ずなりたす。 掗緎されたビゞネスリヌダヌは、コヌドでプロゞェクトの䜜業を開始する前にこのドキュメントを必芁ずしたす。特定のアヌキテクチャ䞊の決定を採甚する理由を理解し、もしあれば、それらに圱響を䞎えたす。


運転開始


補品が突然動䜜し始めたす。 , , , , . , .


. -, . -, , . -, , — .


, . , , , , . , - . . , .


, . , MVP. .



, . . - , , , , .


, , - , , - . , . .


, , , . - . - — . - .


, - , - , - . , . , . , , — .


, . , , , . , SMS- .


.


. , — , . , . . , . 15- .


:



, , , - . .



, MVP . MVP: , , , .


誰もがそれを知っおいたす。 . . , , , .


, , . . : , : , , .


— MVP. -, , . -, « ». -, - . , , .


MVP : . . , MVP.


, — . - . , , , . , .


, , .



. , . . — . , - .


, — MVP, — .


. . . , , MVP — .


, - . , . , — .



. . - . , . , .


- . , . . . , .


, , , . , . , . , -. , , - . .


, , , . . . 25 40% .


, , . , , . , , - , . , , . , . , . — .


? , , . - — . , . , , .


, , . , - . , , , , .


, , «» . ?


-, , , , , . . , , .


-, , . , , , .


-, , . , . , - ( ). .


( — ) .


, . , , , . — - . , , . , — . .



35 , . . , .


- , . — . , .


, . . . .


— , . , , , , , , , .


. , - , . . , . . , . - « ».


. , , .


おわりに


? , . , , .

Source: https://habr.com/ru/post/J336540/

More articles:


All Articles