Ayrıntılı bir teknik plan oluşturma

  • 12 dakika

Belirtim, inşa etmeniz gerekenleri tanımlar. Teknik plan, nasıl oluşturabileceğinizi tanımlar. Bu ünite, kurumsal brownfield senaryoları için gelişmiş planlama tekniklerini kapsar.

Planla ilgili temel bilgileri gözden geçirme

plan.md dosyası, spec.md'daki üst düzey gereksinimlerle bunu izleyen somut uygulama görevleri arasındaki boşluğu köprüleyen tasarım belgeniz olarak görev görür. Kapsamlı bir teknik plan şu şekildedir:

  • Mimariye genel bakış: Bileşenlerin nasıl etkileşime geçtiğini gösteren üst düzey görünüm.
  • Teknoloji yığını ve önemli kararlar: Rasyonaliteleri olan teknoloji seçimlerinin açık belgeleri.
  • Uygulama dizisi: Uygulama adımlarının mantıksal ilerlemesi.
  • Anayasa doğrulaması: Önerilen çözümlerin proje ilkelerine uygun olup olmadığını açıkça kontrol edin.
  • Varsayımlar ve açık sorular: Varsayımların ve çözümlenmemiş soruların belgeleri.

Bu temelleri göz önünde bulundurarak, kurumsal geliştirme için gelişmiş planlama konularını inceleyelim.

Endişelerin ayrılması - belirtim ve plan karşılaştırması

Belirtim ve teknik plan arasındaki endişelerin ayrılması çok önemlidir. Belirtim kararlı ve "neye" odaklanmış durumda olsa da, farklı "nasıl" yaklaşımları üzerinde denemeler yaparken plan gelişebilir.

Belirtiminizin bir iç çalışan portalı için belge yükleme özelliği gerektirdiğini varsayalım. Belirtim kullanıcı gereksinimlerini tanımlar: dosya boyutu sınırları, desteklenen biçimler, karşıya yükleme geri bildirimi ve erişim denetimleri. Teknik plan, bu gereksinimleri somut mimari kararlara çevirir: hangi Azure depolama hizmetinin kullanılacağı, API'nin nasıl yapılandırıldığı, uygulanacak kimlik doğrulama mekanizması ve dosyaların nasıl doğrulandığı. Azure Blob Depolama'dan Azure Dosyalar'a geçiş gibi bir teknolojiden diğerine geçmeye karar verirseniz, spec.md büyük ölçüde değişmeden kalırken plan.md güncelleştirirsiniz. Özellik gereksinimleri değiştirilmez; yalnızca uygulama yaklaşımı değiştirilir.

Plan yapısını ve içeriğini inceleme

Kapsamlı bir teknik plan, uygulama yaklaşımınızı toplu olarak tanımlayan birkaç önemli bölüm içerir.

Mimariye genel bakış

Mimariye genel bakış, bileşenlerin nasıl etkileşime geçtiğini gösteren üst düzey bir görünüm sağlar. Belge karşıya yükleme özelliği için mimari şunları açıklayabilir:

"Çok bölümlü dosya yüklemelerini işlemek için yeni bir arka uç API uç noktası /api/documents/upload uygulayın. React ön ucu, dosya seçici ve ilerleme göstergesine sahip yeni bir DocumentUpload bileşeni içerir. Kullanıcı bir dosya seçtiğinde, ön uç karşıya yüklemeden önce boyutu ve türü doğrular. Arka uç dosyayı alır, yeniden doğrular, Azure Blob Depolama'da depolar ve meta verileri SQL veritabanına kaydeder. Karşıya yükleme başarılı olduktan sonra, arayüz belge listesini yenileyerek yeni dosyayı gösterir.

Bu özet, kod düzeyi ayrıntılarına geçmeden genel akışı oluşturur. Herkesin ana bileşenleri ve etkileşimlerini anlamasını sağlar.

Teknoloji yığını ve önemli kararlar

Plan, teknoloji seçimlerini ve rasyonalitelerini açıkça belgelemektedir. Bu bölüm, belirli kitaplıkların veya hizmetlerin neden seçildiği konusunda gelecekteki karışıklığı önler.

Örnek teknoloji kararları:

  • Arka uç: Blob işlemleri için Azure.Storage.Blobs SDK v12 ile .NET 8 Web API'sini kullanın.
  • Ön uç: Kullanıcı arabirimi tutarlılığı için Ant Design'ın Upload bileşeniyle React 18.
  • Kimlik doğrulaması: Portalın kimlik doğrulama bağlamında mevcut Microsoft Entra ID belirtecini kullanın.
  • Depolama: Azure Blob Depolama adlı employee-documents kapsayıcısı.
  • Veritabanı: DocumentMetadata tablosuyla mevcut SQL veritabanını genişletin (sütunlar: Id, UserId, FileName, BlobUrl, UploadDate, FileSize).

Her karar hem belirtim gereksinimlerine hem de anayasa ilkelerine uygun olmalıdır. Anayasanızda "Tüm bulut kaynakları için Azure hizmetlerini kullanma" zorunlu kılınıyorsa, plan açıkça Azure Blob Depolama'yı seçer ve bu ilkeye başvurur.

Uygulama sırası

Plan, uygulama adımlarının sırasını özetler. Daha sonra oluşturulan görev listesi kadar ayrıntılı olmasa da, bu dizi kurulumdan tamamlamaya kadar mantıksal bir ilerleme sağlar.

Belge karşıya yükleme özelliği için tipik bir uygulama dizisi:

  1. Veritabanı şema güncelleştirmesi: Uygun dizinler ve kısıtlamalarla DocumentMetadata tablosu oluşturun.
  2. Arka uç API geliştirme: Dosya doğrulama, blob depolama tümleştirmesi ve meta veri kalıcılığı ile POST /api/documents/upload uç noktasını uygulayın.
  3. Ön uç bileşen oluşturma: Dosya seçimi, istemci tarafı doğrulama ve karşıya yükleme ilerleme göstergesi ile "DocumentUpload" bileşenini oluşturun.
  4. Tümleştirme: Ön uç bileşenini arka uç API'sine bağlama, yanıtları işleme ve belge listesini güncelleştirme.
  5. Güvenlik sağlamlaştırma: Sunucu tarafı dosya türü doğrulaması, boyut sınırları ve kimlik doğrulama denetimleri uygulayın.
  6. Hata işleme: İstemci ve sunucu tarafı hataları için kapsamlı hata iletileri ekleyin.
  7. Test: Yükleme akışı için API yöntemleri ve tümleştirme testleri için birim testleri oluşturun.

Bu dizi, bağımlı bileşenler (veritabanına yazan API) uygulanmadan önce temel öğelerin (veritabanı şeması) mevcut olmasını sağlar. Her adım önceki çalışmayı kullanarak tümleştirme sorunları olasılığını azaltır.

Anayasa doğrulaması

Plan, önerilen çözümleri anayasaya karşı açıkça denetleyen bir doğrulama bölümü içerir. Bu doğrulama, mimari kaymayı önler ve proje ilkeleriyle tutarlılık sağlar.

Anayasanızda "Tüm veri depolama alanı Azure hizmetlerini kullanmalıdır" ve "API'ler hem istemci hem de sunucudaki girişleri doğrulamalıdır" ifadesi varsa, plan doğrulama bölümü şunları onaylar:

  • "Azure Blob Depolama'yı kullanmak Azure hizmetleri gereksinimini karşılar."
  • "Hem React bileşeninde (istemci) hem de .NET API'sinde (sunucu) doğrulama uygulamak, derinlemesine savunma güvenlik ilkesiyle uyumlu hale gelir."
  • "Microsoft Entra Id kimlik doğrulaması gereksinimi, mevcut portal kimlik doğrulama bağlamı kullanılarak karşılanır."

Bu doğrulama bir denetim noktası görevi görür. Plan anayasayı ihlal eden bir şey önerirse, yapay zeka genellikle bunu işaretler veya inceleme sırasında fark edeceksiniz. Plan aşamasındaki anayasa çakışmalarını ele almak, daha sonra yeniden çalışma yapılmasını önler.

Varsayımlar ve açık sorular

İyi inşa edilmiş planlar varsayımları ve çözümlenmemiş soruları belgeler. Bu saydamlık, uygulama başlamadan önce olası sorunları belirlemenize yardımcı olur.

Örnek varsayımlar:

  • "'employee-documents' Azure Blob Depolama kapsayıcısının mevcut olduğunu ve özel erişim için yapılandırıldığını varsayalım."
  • "Mevcut SQL veritabanının meta veriler için yeterli depolama kapasitesine sahip olduğunu varsayalım."
  • "Karşıya yüklenen dosyaların virüs taramasının bu yinelemenin kapsamı dışında olduğunu varsayın."

Örnek açık sorular:

  • "Yöneticilerin diğer kullanıcıların karşıya yüklenen belgelerini silme özelliğine sahip olması gerekir mi?"
  • "Tüm belge erişim girişimleri için denetim günlüğüne ihtiyacımız var mı?"
  • "Belgeler karşıya yüklenirken sistem e-posta bildirimleri göndermeli mi?"

Bu varsayımların ve soruların belgelenmesi kapsam sapmasını önler ve proje katılımcılarının kodlama başlamadan önce önemli kararları ele almalarını sağlar. Uygulama sırasında bir varsayımın yanlış olduğu kanıtlanırsa planı uygun şekilde güncelleştirebilirsiniz.

/speckit.plan kullanarak plan oluşturma

GitHub Spec Kit, GitHub Copilot Chat'teki komutu aracılığıyla /speckit.plan planlar oluşturur. Bu komut, kapsamlı bir teknik tasarım oluşturmak için giriş olarak hem spec.md hem de constitution.md kullanır.

Komutu çağırmadan önce yapay zekanın ihtiyaç duyduğu diğer bağlamı göz önünde bulundurun. Mevcut kod tabanınız, teknoloji tercihleriniz ve altyapı kısıtlamalarınız planı etkiler. Bu bağlamı önceden sağlamak daha doğru ve eyleme dönüştürülebilir sonuçlar üretir.

Bir iç çalışan portalı senaryosundaki belge karşıya yükleme özelliği için aşağıdakine benzer bir bağlam sağlayabilirsiniz:

Mevcut portal, React ön ucu ve .NET 8 Web API'si arka ucu kullanıyor. Karşıya yükleme özelliğini bu teknoloji yığınına tümleştirmemiz gerekiyor. Dosya kalıcılığı için Azure Blob Depolama'yı kullanın. Tüm karşıya yükleme işlemleri için Microsoft Entra Id kimlik doğrulaması gerektir. Portalda meta veri depolama için kullanılabilecek bir SQL veritabanı zaten var."

Bu bağlam, geçerli yığınınızla uyumlu olmayan bir yeşil alan çözümü önermek yerine mevcut mimarinize sorunsuz bir şekilde uyan bir plan oluşturmak için yapay zekaya yol gösterir.

Planlama komutunu çağırma

Visual Studio Code'da GitHub Copilot Sohbet'i açın ve /speckit.plan yazın. Yapay zeka daha fazla bilgi isterse mimari bağlamınızı sağlayın. GitHub Copilot, plan.md dosyasını oluşturmak için şartnameyi, yapıyı ve bağlamınızı işler.

Yapay zekanın çeşitli yaklaşımları dikkate alması, bunları anayasanıza göre denetlemesi ve çıkışı tutarlı bir tasarım belgesine göre oluşturması planlama aşaması biraz zaman alabilir.

Planı gözden geçirme ve doğrulama

Plan oluşturmak yalnızca ilk adımdır. Kritik gözden geçirme, planın doğru, eksiksiz ve projenizin gereksinimlerine uygun olmasını sağlar.

Belirtim gereksinimlerinin kapsamını doğrulama

Planı sistematik olarak spec.md dosyasına karşılaştırın. Belirtimdeki her gereksinim, plandaki bir uygulama yaklaşımına eşlenmelidir.

Örneğin, spec.md "50 MB'ı aşan dosyalar için hata iletisi görüntüleme" gerekiyorsa, plan bu doğrulamanın nerede ve nasıl gerçekleştiğini açıklamalıdır. Plan bu doğrulamayı atlarsa, plan eksiktir veya belirtim netleştirme gerektirir.

Teknik standartlara uygun olup olmadığını denetleyin

Planın teknoloji seçeneklerinin kuruluşunuzun standartlarına ve en iyi yöntemlerine uygun olduğundan emin olun. Ekibiniz belirli kitaplıkları veya desenleri standartlaştırıyorsa, plan bu tercihleri yansıtmalıdır.

Dikkate alınması gereken sorular:

  • Önerilen mimari mevcut sistemlere uygun mu?
  • Seçili kitaplıklar ortamınızda kullanılmak üzere onaylanıyor mu?
  • Teknoloji seçimleri kurumsal güvenlik ve uyumluluk ilkeleriyle uyumlu mu?
  • İzlenmesi gereken benzer işlevler için oluşturulmuş desenler var mı?

Azure ortamında belge karşıya yükleme özelliği için Azure Blob Depolama'nın onaylı bir hizmet olduğunu, kimlik doğrulama yaklaşımının kurumsal kimlik standartlarıyla (Microsoft Entra Id kullanımı gibi) uyumlu olduğunu ve önerilen SQL şemasının veritabanı adlandırma kurallarına uyduğunu doğrulayın.

Anayasaya bağlılığı doğrulama

Plan, önerilen çözümlerin anayasa gereksinimlerine uygun olduğunu açıkça doğrulamayı içermelidir. hiçbir ilkenin ihlal edilmez emin olmak için bu doğrulama bölümünü dikkatle gözden geçirin.

Anayasanızda "Tüm gizli diziler Azure Key Vault'ta depolanmalıdır" gerekiyorsa ve plan Azure Depolama bağlantı dizelerinin appsettings.jsondepolanmasını öneriyorsa, bir çakışma vardır. Plan, bağlantı dizelerinin çalışma zamanında Key Vault'tan alınmasını sağlayacak şekilde revize edilmelidir.

Planlama sırasında bulunan anayasa ihlallerini düzeltmek kolaydır. Kod gözden geçirme veya üretim dağıtımı sırasında bulunan anayasa ihlalleri maliyetli ve kesintiye neden olur.

Planı tekrarla ve geliştir

Planlar genellikle ilk nesilden sonra iyileştirme gerektirir. İlk denemede mükemmellik beklemeyin. Plan kalitesini geliştirmek için GitHub Copilot'un açıklama özelliklerini kullanın.

Belirsizlikleri ve boşlukları giderme

Planda "uygun hata işlemeyi uygulama" gibi belirsiz deyimler varsa, ayrıntılar için basın. Hangi hatalar oluşabilir? Her hata nasıl işlenmelidir? Kullanıcılara hangi hata bilgilerinin günlüğe kaydedilmesi ve görüntülenmesi gerekir?

GitHub Copilot Sohbeti'ni kullanarak aşağıdaki soruları sorun: "Karşıya yükleme uç noktası hangi belirli hataları işlemelidir?" veya "Azure Blob Depolama kullanılamıyorsa ne olmalıdır?" Yapay zeka, belirsiz bölümleri somut belirtimlere genişletebilir.

Teknik fizibiliteyi doğrulama

Kısıtlamalarınız göz önünde bulundurulduğunda önerilen mimarinin teknik olarak uygun olduğunu doğrulayın. Plan, 30 saniyelik zaman aşımına sahip bir Web API'siyle zaman uyumlu olarak 50 MB'lık dosyaların karşıya yüklenmesini önerirse bir sorun oluşur. 50 MB'ın üzerindeki dosyalar için öbekli karşıya yüklemeler veya daha fazla zaman aşımı gerekebilir.

İlgili uzmanlığa sahip ekip üyelerine danışın. Plan veritabanı şeması değişiklikleri öneriyorsa, veritabanı yöneticisiyle birlikte gözden geçirin. Yeni Azure kaynakları gerekiyorsa altyapı mühendislerine sağlamanın mümkün olduğunu doğrulayın.

İşlevsel olmayan gereksinimleri göz önünde bulundurun

Planın teknik özelliklerden işlev dışı gereksinimleri karşıladığından emin olun: performans, güvenlik, ölçeklenebilirlik, bakım, erişilebilirlik.

Belgeyi karşıya yüklemek için planın şunları içerdiğini onaylayın:

  • Performans: Karşıya yüklemenin ne kadar sürede tamamlanması gerekiyor? Eşzamanlı karşıya yükleme hacmi üst sınırı nedir?
  • Güvenlik: Dosyalar kötü amaçlı yazılım için nasıl taranır? Erişim nasıl denetlendi? Denetim günlükleri nerede depolanır?
  • Ölçeklenebilirlik: Sistem artan karşıya yükleme hacmini nasıl işler? Depolama kapasitesi sınırları nedir?
  • Bakım: Çalışanlar kuruluş dışına çıktığında karşıya yüklenen dosyalar nasıl temizlenir?
  • Erişilebilirlik: Karşıya yükleme kullanıcı arabirimi Web İçeriği Erişilebilirlik Yönergeleri (WCAG) 2.1 AA standartlarını karşılıyor mu?

Plan bu önemli noktalardan herhangi birini atlarsa, bunları açıkça ekleyin. İşlevsel olmayan gereksinimler, planlamada ele alınmıyorsa uygulama sırasında sık sık düşüncelerin ardından gelir.

Fizibiliteyi ve eksiksizliği değerlendirme

Planın uygulama için yeterli rehberlik sağlayıp sağlamadığını değerlendirin. Çok belirsiz olan planlar ("Dosya yükleme uygulaması") yararlı olmaz. Çok açıklayıcı ("Tam olarak 47 kod satırı kullan") planlar aşırı kısıtlayıcıdır.

Doğru ayrıntı düzeyi, tüm esnekliği ortadan kaldırmadan net bir yön sağlar. Plan şu soruları yanıtlamalıdır:

  • Hangi bileşenlerin oluşturulması veya değiştirilmesi gerekiyor?
  • Bu bileşenler nasıl etkileşim kurar?
  • Hangi teknolojiler ve kitaplıklar kullanılır?
  • Uygulama sırası nedir?
  • Hangi doğrulama adımları doğruluğu sağlar?

Bu özelliğin plandan nasıl uygulanabileceğini öngöremiyorsanız daha fazla ayrıntıya ihtiyaç duyarsınız. Plan kodu sizin için yazıyor gibi görünüyorsa, çok ayrıntılı olabilir.

Eksik öğeleri tanımlama

Plandaki boşlukları arayın. Yaygın eksiklikler şunlardır:

  • Hata işleme: Sistem ağ hatalarını, depolama hatalarını veya veritabanı sorunlarını nasıl işler?
  • Performansla ilgili dikkat edilmesi gerekenler: Karşıya yükleme hızı, eşzamanlı kullanıcılar veya depolama sınırlarıyla ilgili herhangi bir endişe var mı?
  • Test stratejisi: Uygulamayı doğrulamak için hangi testlerin yazılması gerekir?
  • Geri alma yaklaşımı: Dağıtım sorunlara neden oluyorsa, değişiklikleri nasıl geri döndürebilirsiniz?

plan.md el ile düzenleyerek veya daha fazla bağlam sağlayarak ve ilgili bölümleri yeniden ekleyerek bu boşlukları giderin.

Geliştirilmiş bağlamla yeniden oluşturma

İlk plan hedefi ıskalarsa, daha belirli bir bağlam verin ve yeniden oluşturun. Örneğin, plan yeni bir veritabanı kullanmayı öneriyorsa ancak var olan bir veritabanını kullanmanız gerekiyorsa şu açıklamayı yapın: "Var olan EmployeePortal veritabanını kullanın. Yeni bir tane oluşturmak yerine bu veritabanına bir DocumentMetadata tablosu ekleyin."

Bu güncellenmiş bağlamı ekleyerek planı /speckit.plan yeniden oluşturun. Yapay zeka yaklaşımı buna göre ayarlar.

Planı el ile düzenleme

plan.md bir Markdown dosyası olduğundan, doğrudan düzenleyebilirsiniz. Yapay zeka 90% doğru ancak küçük ayarlamalar gerektiren bir yaklaşım önerirse, her şeyi yeniden oluşturmak yerine dosyayı düzenleyin.

Örneğin, plan belirli bir blob kapsayıcı adı öneriyorsa ancak kuruluşunuzun adlandırma kuralları varsa kapsayıcı adını doğrudan plan.md'da güncelleştirin.

Ekip üyeleriyle işbirliği yapma

Ekip ortamlarında gözden geçirmek üzere plan.md paylaşın. Üst düzey bir geliştirici veya mimar, uygulama başlamadan önce mimari kararları doğrulayabilir. Bu eş gözden geçirme otomatik denetimlerin kaçırabileceği sorunları yakalar.

Ekibin incelemesi, ortak bir anlayış oluşturur. Bir özellik üzerinde birden çok geliştirici çalıştığında, planı birlikte gözden geçirmek herkesin yaklaşımı bildiğinden ve devam eden diğer çalışmalarla olası çakışmaları belirleyebildiğinden emin olmasını sağlar.

Mimari kararları belgeleyin

Planlar yalnızca oluşturacakları değil, gelecekteki geliştiricilerin karar bağlamlarını anlamasına yardımcı olmak için neden belirli mimari seçimler yaptığınıza da belge vermelidir.

Kayıt alternatifleri dikkate alınıyor

Birden çok uygulanabilir yaklaşım arasından seçim yaparken, göz önünde bulundurdığınız alternatifleri ve neden diğer kişilere göre birini seçtiğinizi belgeleyebilirsiniz.

Dosya depolama için üç yaklaşımı göz önünde bulundurabilirsiniz:

  • Azure Blob Depolama: Maliyet verimliliği, ölçeklenebilirlik ve mevcut Azure ortamıyla tümleştirme için seçilir.
  • Azure Dosyaları: Büyük dosya depolama maliyeti ve gereksiz Sunucu İleti Bloğu (SMB) protokolü ek yükü nedeniyle reddedildi.
  • SQL Veritabanı FILESTREAM: Veritabanı boyutunu ve karmaşıklığını artırmaktan kaçınmak için reddedildi.

Bu belge, gelecekteki geliştiricilerin neden daha basit yaklaşımların kullanılmamış olduğunu sorgulamasını önler. Karar mantığı zaman kaybından ziyade korunur.

Varsayımları yakalama

Planlar mevcut sistemler, altyapı ve kuruluş kısıtlamaları hakkında varsayımlarda bulunur. Bu varsayımları açık hale getirin.

Belge yükleme için örnek varsayımlar:

  • Azure Blob Depolama kapsayıcısı employee-documents , geliştirme başlamadan önce altyapı ekibi tarafından sağlanır.
  • Mevcut portal kimlik doğrulaması, kullanıcı kimliği için güvenilebilen doğrulanmış Microsoft Entra Id belirteçleri sağlar.
  • SQL veritabanı, depolama genişletme gerektirmeden başka bir meta veri tablosu için yeterli kapasiteye sahiptir.
  • Ağ altyapısı, ara sunucu veya güvenlik duvarı kısıtlamaları olmadan 50 MB HTTP yüklemelerini destekler.

Uygulama sırasında herhangi bir varsayım yanlışsa, planı yeniden ziyaret edebilir ve buna göre ayarlayabilirsiniz. Belgelenmiş varsayımlar, koşullar değiştiğinde etki analizini basit hale getirir.

Gelecekteki evrim planı

Özelliğin nasıl gelişebileceğini göz önünde bulundurun ve mimarinizin olası uzantıları barındırdığından emin olun.

Belge yükleme için gelecekteki olası gereksinimler şunlar olabilir:

  • PDF ve DOCX dışındaki diğer dosya türlerini destekleme.
  • Çalışanlar arasında dosya paylaşımı uygulama.
  • Belge sürümleme ekleniyor.
  • Birden fazla dosyanın toplu yüklenmesini etkinleştirme.
  • Virüs taramasını tümleştirme

Mimariniz bu uzantıları zorlaştırıyorsa, ilk tasarımı ayarlamanın gerekli olup olmadığını göz önünde bulundurun. Şu anda gelecekteki özellikleri uygulamazsınız, ancak gelecekteki değişiklikleri acı verici hale getiren köşelere kendinizi boyamaktan kaçınabilirsiniz.

Uygulama sırasında planı paylaşma ve koruma

Plan, uygulama süresince sizin referansınız olur. Geliştiricilerin, kodlarının belgelenen mimariyle uyumlu olduğundan emin olmak için plana düzenli olarak başvurması gerekir.

Planı paydaşlarla paylaşma

Planı sonlandırdıktan sonra doğrulama için ilgili paydaşlarla paylaşın:

  • Ürün yöneticileri: Planın tüm belirtim gereksinimlerini karşıladığını doğrulayın.
  • Güvenlik ekibi: Güvenlik denetimlerinin kuruluş standartlarına uygun olduğunu onaylayın.
  • Altyapı ekibi: Önerilen Azure kaynaklarının sağlanıp yapılandırılabilmesini sağlayın.
  • Mimari ekibi: Kurumsal mimari ilkeleriyle hizalamayı doğrulayın.

Bu paydaş incelemesi, uygulama başlamadan önce sorunları yakalar. Güvenlik ekibi geri bildirimi önerilen kimlik doğrulamasının yetersiz olduğunu gösterirse, kod yazmadan önce planı güncelleştirirsiniz.

Planı gerektiği gibi güncelleştirin

Planlar canlı belgelerdir. Uygulama sırasında bir yaklaşımın istendiği gibi çalışmadığını fark ettiğinizde, planı yeni yaklaşımı yansıtacak şekilde güncelleştirin.

Karşıya yükleme ilerleme durumunu tarayıcı localStorage'da depolamayı planlıyorsanız ancak bunun özel gözatma modunda sorunlara neden olduğunu fark ederseniz, bunun yerine planı bellek içi durumu kullanacak şekilde güncelleştirin. Mantığın korunması için değişikliğin neden gerekli olduğunu belgeleme.

plan.md'i gerçek uygulamayla senkronize halde tutun. Plan ve kod ayrıştığında, plan başvuru belgeleri olarak değer kaybeder.

  • Güvenlik yaklaşımları kuruluş gereksinimlerini karşılıyor mu?
  • Veritabanı şeması tasarımı adlandırma kurallarına uyuyor mu?

Plan veritabanı kullanmayı öneriyorsa ancak mevcut portalınızda zaten bir veritabanı varsa, bu büyük olasılıkla fazla olabilir. Plan, ekibinizin kaçın ettiği bir teknoloji öneriyorsa, planın nedenini belgele veya ayarla.

Kaçınılması gereken yaygın planlama tuzakları

Plan oluştururken ve gözden geçirirken şu yaygın hatalardan kaçının:

  • Planlama aşamasını atlama: Plan olmadan doğrudan belirtimden koda atlamak mimari hata riskini artırır. Planlamaya yatırılan süre, yeniden çalışma yapılmasını engelleyerek kar paylarını öder.

  • Planları gözden geçirmeden kabul etme: Yapay zeka tarafından oluşturulan planlar, son tasarımlar değil başlangıç noktalarıdır. Her zaman kritik bir şekilde gözden geçirin ve kendi bağlamınıza göre doğrulayın.

  • Aşırı kısıtlayan uygulama: Planlar yol göstermelidir, her ayrıntıyı dikte etmemelidir. Uygulama sırasında geliştiricilerin uygun taktik kararları vermeleri için yer bırakın.

  • Anayasa çatışmalarını göz ardı etme: Plan anayasa ilkelerini ihlal ederse, çatışmayı hemen ele alın. İlkenin düzeltilmesi gerekiyorsa planı uyumlu olacak şekilde ayarlayın veya anayasayı güncelleştirin.

  • Planları güncelleştirmeyi unutma: Uygulama yeni bilgiler ortaya çıktığında plan.md güncelleştirin. Eski planlar gelecekteki geliştiricileri yanıltıyor ve belgelerinizin değerini azaltıyor.

Özet

Teknik plan, belirtiminizi eyleme dönüştürülebilir mimariye dönüştürür. Teknoloji yığınınız ve altyapınız hakkında uygun bağlamı kullanarak /speckit.plan planlar oluşturun. Tüm belirtim gereksinimlerini karşıladığından, anayasanızla uyumlu olduğundan ve yeterli uygulama kılavuzu sağladığınızdan emin olmak için planları kritik olarak gözden geçirin. Görev oluşturma ve uygulama konusunda yol göstermek için doğrulanmış planı kullanın. plan.md anlayışınızla gelişen ve geliştirme yaşam döngüsünün tamamı için değerli bağlam sağlayan canlı bir belge olarak değerlendirin.