it-swarm-tr.com

Kaynak kodunu kontrol etmeden önce bazı iyi uygulamalar nelerdir?

Ekibim kaynak kontrolü için Team Foundation Server kullanıyor ve bugün teslim etmeden önce bazı hataları ve duman testi uygulamasını düzelttim ama bazı kodları yorumlamayı unuttum. (Bu kod kullanıcı arayüzünü biraz garip hale getirdi.)

Kodu kontrol etmeden önce hangi iyi uygulamaların olduğunu bilmek istiyorum - tekrar bu tür bir hata yapmak istemiyorum.

47
Anonymous

Yapma alışkanlığımdan aldığım bir şey, onları kontrol etmeden hemen önce kontrol etmek üzere olduğum her dosyanın farklarına bakmaktır.

149
crudcore

Yorumlanmış kodu asla giriş yapmamalısınız. Check-inlerden önce yorum yapmanız gereken bir kodunuz varsa, bunu yanlış yapıyorsunuz demektir.

Kurallara gelince:

  1. En son haberleri alın
  2. Birleştirme çakışmalarını düzeltme
  3. İnşa etmek

    3.1 Derleme hatalarını düzeltme

  4. Testleri çalıştırın

    4.1 Bozuk testleri düzeltin

  5. 1'e gidin (yeni bir şey kalmayana kadar)

Yalnızca tüm adımlar tamamlandığında giriş yapın.

Bakınız check-in dansı .


Diğer iyi uygulamalar:

  • Beklenen dosyalar olduklarından emin olmak için check-in yapılacak dosya listesini gözden geçirin.
  • Her dosya için değişiklikleri gözden geçirin (siler/eklemeler/farklar)
63
Oded

Burada çok fazla pantolon giymeye çalışmıyorum, ancak bu sorudaki varsayım (ve cevaplardan biri hariç tümü) çoğunlukla TFS, SVN, Perforce vb.Gibi Merkezi VCS için geçerlidir.
Yeterince adil, OP bunu kullanıyor.

Öte yandan, DVCS'yi (Mercurial ve Git gibi) kullanırken, genellikle check-in yapmak için beklememelisiniz ve cevaplarda belirtilen, diffs, en son, birleştirme vb.Gibi şeylerin çoğu gerekli değildir. . Kod incelemeleri ve testler gibi şeyler bile check-in işleminden sonra daha iyidir (belki de itmeden önce, bağlı olarak ...)
Burada gördüğüm tek istisna (şimdiye kadar) bir iş öğesiyle ilişkilendirmek. Tabii ki, iade hakkında yorum yapmak da iyidir ...

20
AviD

Diğer cevaplarda görmediğim üç şey:

Yeni dosyalar dahil et

  • Değişiklikçinizin bir parçası olmayan yeni dosyalar arayın
  • Perforce gibi SCM'lere özgü olabilir - değişikliğinizdeki her şeyi anlatmanız gerekir.

Değişmeyen dosyaları geri alma

  • Diğer insanların değişikliklerine baktığımda nefret ediyorum ve dokuz dosyadan oluşan bir changelist var ama sadece üçü değiştirildi.
  • Ayrıca boşluk veya başka anlamsız değişikliklerle dosyaları geri alıyorum.

Gönderdiğiniz taahhüdü kontrol edin

  • Yaptığınız işten sonra yapının yeşil kaldığından emin olun.
  • Taahhütlerimden sonra senkronize edeceğim, inşa edip çalıştıracağım ikinci bir makinem vardı, böylece bir şeyler ters giderse kolayca atlayabilir ve düzeltebilirdim.

Git'i kullandığımda iki şey var:

Atomik taahhütler:

  • Taahhüt için yalnızca bireysel işlevsel değişiklikleri yapın.
  • Taahhütleri mümkün olduğunca küçük yapın. Düzeltme, geri alma ve anlamalarını kolaylaştırın.
  • Kullanırım git add --patch Değişikliklerimi gerekirse birden fazla parçaya bölmek için.

Özetlerken farkları görüntüleyin

  • Her zaman git commit --verbose böylece taahhüt mesajımı yazarken yaptığım değişikliğin farkını görebiliyorum. (Ya da farkı göstermek için yamalı git-vim kullanıyorum.)
  • Bu, değişikliklerinizi gözden geçirmeyi ve tüm taahhüdü açıklamayı çok daha kolay hale getirir. Bazen bu aşamada istenmeyen değişiklikler yakalarım. (Değişikliğinizi tanımlamak, bunu düşünmenize yardımcı olur.)
8
idbrii

Lanet kelimeleri arayın ve değiştirin ;-)

7
Throwback1986

Ekibimin sunucularında uyguladığım bazı 'iyi uygulama' öğeleri oldukça basit. İlk olarak, check-in yapmadan önce, kodunuzda kimsenin çatışacağını hiçbir şeyin kontrol etmediğinden emin olmak için her zaman en son sürümü almalı ve yerel bir yapı çalıştırmalısınız. Ayrıca, sunucuda değil, yerel makinenizdeki kod çakışmalarına dikkat edin. En son kod indirilen kodunuz doğru bir şekilde oluşturulduğundan ve çalıştığından emin olduktan sonra bir sonraki adıma hazırsınız. Otomatik testleri çalıştırın ve düzgün çalıştıklarından emin olmak için check-in işleminize başlayın. Sonra, sadece emin olmak için, en son tekrar alın.

Bir TFS Yöneticisi olarak, tüm check-in'lerde yorum yapmayı zorunlu kılmak mümkündür. Zorlanmış olup olmadığına bakılmaksızın işiniz için her zaman check-in yorumları koymanızı tavsiye ederim. Bunu yapma seçeneğiniz varsa, zorlayın. Yorumların en azından kodunuzu en son ne zaman kontrol ettiğinizden beri değiştirdiğiniz şeyin genel bir özeti olduğundan emin olun. Bu şekilde, bir şeyler ters giderse check-in'lere bakabilir ve kabaca ne olduğunu görebilirsiniz. bu check-in sırasında değişti. Hatalı bir yapıda hata ayıklamayı çok daha kolay hale getirir.

Ayrıca, TFS Yönetici ayrıcalıklarına sahipseniz, check-in'lerde haddeleme derlemelerini zorunlu kılın (herkesin check-in'lerinin bir şeyleri bozduğunu hemen bildiğinden emin olmak için) ve sunucuyu geçişli bir check-in gerçekleştirecek şekilde ayarlayabilirsiniz ( teslim edilen kod yapıyı bozarsa, sunucu onu reddeder) veya basitçe bir hata oluşturmasını ve yapıyı bozan kişiye atamasını sağlayabilirsiniz.

Her şeyi iyi tutmak için açabileceğiniz veya kapatabileceğiniz veya şeyleri güzel ve temiz tutmak için TFS-Yöneticinize önerebileceğiniz birkaç seçenek daha vardır ... ancak bunlar büyük ölçüde tercih edilir

7
guildsbounty

Windows'tan check-in yapıyorsanız, kodunuzun görünmeyen ^ M karakterlerine sahip olup olmadığını kontrol edin - UNIX'teki editörler genellikle hata/uyarı verir.

Ayrıca sekmeleri deneyin ve değiştirin - farklı kullanıcılar sekmeleri 4'lü, bazıları 8 olan ve kod okunabilirliği için iyi olmayan farklı şekilde görecektir.

En iyi yaklaşım IMHO, kodunuzun kuruluşunuzun kodlama yönergelerine göre kontrol edilmesini sağlamaktır. Bir sürü kaynak kontrol sistemi bu işlevselliğe sahiptir.

4
Fanatic23

Şirketimde check-in yorumları kullanıyoruz. Bunlar ayrıntılı olmak zorunda değildir, ancak birisine değişiklik listenizdeki farkları göstermek ve onlarla konuşmak bazen testte kaçırdığınız garip yazım hatasını vurgular.

Yorumlarda incelemenin adını not etmediğiniz sürece kaynak kontrol sunucumuz check-in yapmanıza izin vermeyecektir (formda! Baş harfleri, örneğin! Bruce Wayne incelemenizi yaptıysa! BW). İnceleyen, incelemeye yardımcı olduklarını belirten bir e-posta alır. Bu açık bir sömürüye açıktır, ancak oldukça iyi çalışıyor gibi görünüyor.

4
tenpn

Mümkün olduğunda, bir check-in'i bir iş öğesiyle ilişkilendirmek istiyorum. Bu, yalnızca Neyin değiştirildiği değil, bunun NEDEN değiştirildiği hakkında bazı bağlamsal bilgiler verir. TFS'nin oldukça iyi bir iş öğesi izleme sistemi vardır, bu nedenle check-in sırasında bunu yapmak oldukça önemsizdir.

(bu, değişikliklerimin farklarını incelemeye ek olarak)

4
mpeterson

Yaptığım küçük bir şey, gerçekten değişmeyen dosyaları kontrol etmemektir. Bu dosyalar yanlışlıkla değiştirilmiş veya geri alınmış veya başka şekilde tartışılmış yeniden düzenleme işlemlerine katılmış olabilir.

Bu şekilde, değişiklik kümeniz (bir iş öğesiyle ilişkilendirilir) tam olarak iş öğesini tatmin etmek için gerekli dosyaları içerir.

3
John Saunders

Tüm cevapları burada birleştirmek ve eksiksiz bir kontrol listesi vermek için

  1. [check-in/check-out] doğrudan başkalarının çalıştığı akışa giriş yapmamalısınız. Bir akış stratejiniz olmalıdır: ör. geliştirici başına, başkalarını rahatsız etmeden bağımsız olarak check-in yapabileceğiniz ve check-out yapabileceğiniz bir akış: işiniz güvenli olacak, ancak kendi geliştirme akışınızda [yalnızca kendi geliştirme akışınızda] olacak. Her check-in ile, bir değişiklik kaydı ile ilişkilendirirsiniz, böylece değişiklikleriniz değişiklik kümesi adı verilen değişikliğe karşı atomik olur (böylece 'her şeyi' teslim etmek zorunda kalmadan bireysel rfc/böcek vb. Dağıtabilirsiniz).

  2. [o zaman takım akışınızla yeniden pazarlayın] Bu, kendi akışınızda diğerlerinden gelen değişiklikleri almanız anlamına gelir. Bu işlem sırasında birleştirme iletişim kutusunda tüm "farkları" görebilir ve bunlardan geçebilirsiniz veya ... binlerce varsa ve/veya kod değil, aynı zamanda örn. veri modelleri/siebel projeleri vs ... önemsiz olmayan birleştirme, önemsiz otomatik ve önemsiz manuel birleştirme güveniyor, son kategori zor olanları içerir. Hâlâ kendi akışınızda çalıştığınızı unutmayın.

  3. [tam rebase] Her şey yolundaysa, takım akışından aldığınız tüm değişiklikleri kontrol edin: kendi akışınız artık güncel

  4. [teslim et] şimdi çalışmanızı ekip akışına iletin. İstediğiniz her şeyi sunmak istemiyorsanız, ör. 1 belirli RFC dosya sürümleriyle RFC veya bir dizi RFC/kusur çözüldü.

  5. [test teslim] iyi gitmeli ama bu arada birisinin de değişiklik yapma olasılığı olduğu için: çalışmanızın ekip akışındaki en son değişikliklerle çalışıp çalışmadığını test edebilirsiniz. Farklılık gösteren aynı birleştirme iletişim kutuları ile.

  6. [tam teslim] tesliminizi tamamlayın ve işiniz artık takım akışında.

Daha karmaşık hale getirmek için: Hala teslim ettiğiniz iş = ok AMA zaten başka bir sürüm üzerinde çalışıyor olma şansı olduğundan, her zaman teslimattan sonra her zaman temel almalı ve diğer kullanıcıların yeniden basmak için hangi temel olduğunu belirtmelisiniz . Bu, diğer geliştiricilerin akıştaki en son sürümü değil, önerilen bir sürümü almasını sağlar (bu senaryoda çalışıyorsanız). Bu aynı zamanda Üçlü bir kontroldür, böylece takım akışındaki en son sürümler "kötü" bile olsa, yine de diğerlerinin yeniden oluşturduğu veya baktığı sürümler değildir ve yapılandırma yöneticiniz önceki sürümü bir sonraki sürüme geri alabilir teslimat.

  • histumness cevabı 2 kez olur: adım 2 ve 6'da
  • check-in dansı sırasında Oded'in cevabı: idem ama check-in/check-out'ta ekstra bir teslim ve geri çekilme katmanı, izole çalıştığınızdan emin olmak için ve hatalar daha sonraki aşamalarda bile kolayca çıkarılabilir
  • cevaplanan guildsbounty gelen cevap: en son olsun 2. adımdır. Yapı için: gerçekten bir yapıya sahip olup olmadığınıza bağlıdır ... benim dünyamda veri modelleri, Word belgeleri, gereksinim sayfaları, informatica, siebel'den yapılandırma verileri, vs .. ve evet de Java kod, .net kodu vb ... hepsi bir araya gelmesi gerekir. Yani burada gerçekten bir "yapı" değil, daha yüksek bir entegrasyon bu "örn." kodunuzdaki derleme, tüm diğer şeylerle bütünleşir, çünkü entegrasyon öğeleri olup olmadığından emin olamazsınız ve test ortamlarına bağlı olarak, bir şeyler derlenebilir veya daha yüksek teslimatlarda başka bir derleme yapılabilir. başka bir takımdan bir şeye ihtiyacı var.
  • guildsbounty'den yorum ve gerekli cevap: Ben VERSIONS ve değişiklik kümelerinde değişiklikler (ve tür: kusurlar, RFC, hotfi) entegrasyonu olmayan her ortamda olgun olmadığını düşünüyorum. Bence eğer bu kaos örneğin; dokunulan tam sürümler için tıklanabilir gönderilen hata ve rfc miktarıyla sürüm notlarını otomatikleştirin (örneğin hello.c'nin sürüm 1 ve sürüm 3 çok iyi teslim edilebildiğinden, ancak sürüm 2 teslim edilmemeli çünkü daha sonraki bir sürümün bir parçası olacaktır, ancak bazı noob zaten koydu) (bu yüzden de hello sürüm 3'ü almak istiyorsanız manuel bir karar anlamına gelir. AMA sürüm 3'ü çıkarmanız da hepsini çıkarmanız gerektiği anlamına gelir. Bu RFC/kusur tarafından dokunulan diğer sürüm, böylece tüm şeyi çıkarmak için bir araçla kolayca ve hızlı olmanız gerekir) (aynı RFC'nin parçaları üzerinde birden fazla geliştirici çalışsa bile) en azından karar vermek için etrafında bir şeyler yapmanız gerekir üzerinde vb ...). Ekstra dokümantasyon her zaman kullanışlıdır, ancak değişiklik kümelerini ilişkilendirerek tam daireyi elde edersiniz: sürüm <- değişiklik kümesi <- iş öğeleri <- bilet/rfc/kusur <- bir gereksinim. Anlamı: hangi gereksinimlerin tamamen veya tamamen teslim edildiğini bilirsiniz: bir gereksinimin birden fazla RFC'si veya hatası ya da başka bir şeyi vardır. RFC'nin birden fazla kişi için birden fazla iş öğesi vardır. bu iş öğesi, bir dizi sürümden oluşan bir değişiklik kümesine karşılık gelir (örneğin, tümleştirme akışındaki hello.c sürüm 1 ve 3, bu sürümün geliştirme akışınızdaki sürüm 1,2,3,4,5 DEĞİLDİR) Entegrasyon akışındaki 3 buna karşılık gelir) (dolayısıyla bir sürüm ağacı ve üzerinde çalışacak araçlar)
  • luis.espinal: dont break the build tekrar çifte kontrol edilir ve hala teslim edilir ... 'serbest bırakma yöneticileri ve yapı meister'leri için değişiklik setleri ve taban çizgilerini bilgi olarak görmesi gereken daha yüksek teslimatlar vardır. "Asla doğrudan ana dalda çalışma" evet, akış yapısı büyük veya basit olabilir, ancak özünde: geliştiricilerin kendi akışları vardır, bir yayın akışına teslim eden bir takım akışına teslim ederler. -> böylece tüm ekiplerden gelen teslimatlar (örneğin dokümantasyon ekibi, gereksinim ekibi, geliştirme ekipleri, test ekibi) takım akışlarında olacak ve bir sürüm yöneticisi veya yapılandırma yöneticisi bir sürümde olması gereken temel çizgileri kapacak ve Doğru test sürümleriyle doğru dokümantasyon Doğru kod sürümleriyle doğru gereksinimi olan dokümanlar/sonuçlar bir sürüm için aynıdır.

Örneğinizde, yorum yazmayı unuttuğunuzu belirtiyorsunuz. Hatalar olur. Etrafındaki konfigürasyon yönetim sistemi bununla ilgilenmelidir. Gerçekten biri olabilir örn. binlerce değişiklik gerçekleşir ve zaman içinde zincirlenen ve işlenen farklı sunuculardaki akışlar hiyerarşisinde "derlemeler" ve "entegrasyonlar" gerçekleşir. Dolayısıyla, kodunuz diğer kod ve sistemlerle entegrasyona ihtiyaç duyduğundan, yorum kodunuz 5 aydan sonra bir entegrasyon sunucusunda test edilse bile, yine de atomik olarak değişiklik kümenizi çıkarıp devam ettirmek mümkün olmalıdır. Yani en iyi uygulama az çok daha yüksek seviyededir. Konfigürasyon yönetimi akışlarının genel tasarımı buna dikkat etmelidir. Bireysel geliştiriciler için en iyi uygulama doğrulamak/birim testi yapmaktır. Ancak büyük resimden "çalışmasını sağlamak" için en iyi uygulama, sistemi takip etmek ve her zaman daha sonra zincirdeki çocuklar için ilgili değişiklik kümelerinin meta bilgilerini sağlamaktır.

3
edelwater

Aşağıdakilerden bazıları, SCM'nize bağlı olarak diğerlerinden (veya farklı formlarda) daha fazla geçerlidir, bu yüzden işte gidiyorlar:

  1. Derlemeyi bozmayın - sadece derleyen kodu kontrol edin.
  2. Check-in'lerinizi (ve muhtemelen SCM'nizin size bu seçeneği sunup sunmadığını kontrol edin) yorumlayın.
  3. Uzun süre hiçbir şeyi işaretlemeyin.
  4. Sık sık check-in yapın (mümkünse günde birkaç kez).
  5. Anlamlı bir şekilde etiketleyin.
  6. Düzenli olarak etiketleyin.
  7. Asla doğrudan ana branş üzerinde çalışmayın.
  8. Üretime yapılan her sürümün kendi etiketi olmalıdır (ve mümkünse ana şubeden salt okunur bir dal). Mümkünse UAT/Entegrasyon/Üretim öncesi test sürümleri için de aynısını yapın.
  9. SCM'nizde ve bir etiketten üretimde olanı tam olarak inşa edebilmelisiniz.

NOT : yukarıdaki öğelerin bazıları oldukça açık görünüyor, ancak aslında ana dalda kaç kişinin çalıştığına veya üretimde değişiklik yaptığına inanmayacaksınız - ve sonra manuel olarak sürüm kontrolüne gitmek için doğrudan deltalar oluşturun ... doğrudan ana dalda ... ve etiketlerle. Yıkanmamış koltuk altı suyuyla karıştırılmış fermente safra gibi tatlı ... evet, böyle.

2
luis.espinal

Kişisel bir kontrol listeniz olsun. Bir girişte batırdığınızda boş başlayın. İkinci doğa olduğunda listeden kaldırın.

Testleri yapın. Eğer geçerse kontrol edin. Eğer karışıklık yaşarsanız ve bir şey testleri geçerse, bir test yazın.

2
ctrl-alt-delor

Her zaman, her zaman, always, yaptığınız değişikliklerin derlemeyi bozmadığını kontrol edin. Özellikle önemsiz görünen ufak değişiklikler.

Bir kez hafta sonu için işten ayrılmadan hemen önce herhangi bir soruna neden olacağını düşünmediğim çok küçük bir değişiklik yaptım. Tabii ki, bu küçük değişiklik inşayı kırdı ve projemiz için her gece test çalıştırması yapılmadı. Soru-Cevap şefi bu konuda çok mutlu değildi ve haklı olarak da öyle.

1
gablin

Üzerinde çok çalıştığınız birim testlerinizi yapın. Yeşil iyidir.

1
Naftuli Kay

Kodunuzun doğru biçimlendirildiğinden emin olun (örn. Java için: kodunuzu seçin ve Eclipse'de Ctrl-Shift-F tuşlarına basın). Ancak tüm belge için aynısını yaparken dikkatli olun.

1
Rune Aamodt

Aşağıdakileri yapıyoruz ...

  1. Test - Çalıştığından emin olmak istiyoruz. En azından, hiçbir şey kırmadığını bilmek istiyoruz.

  2. Kod incelemesi veya en azından bir arkadaş kontrolü - Bu, bilginin yayılmasını ve insanların güncel tutulmasını sağlamanın harika bir yoludur. Ayrıca bir şeyleri kontrol etmeden önce hataları yakalamaya yardımcı olur.

  3. Önceden bildirim gönder - Check-in işleminden önce gruba önceden bildirim gönderilir. Amaç sadece başkalarının hangi dosyaların veya alanların değiştiğini bilmelerini sağlamakla kalmaz, aynı zamanda bu değişikliklerin onları etkilemesi beklenirse onlara dikkat çeker (dikkat etmeyi seçmeleri gerekir).

  4. Ön bildirim gönderildikten birkaç saat sonra check-in yapılır ve grup e-posta yoluyla bilgilendirilir. Gruptaki herkes bir hata veya özellik üzerindeki belirli çalışmanın ne zaman yapıldığını bilebilir.

  5. Check-in bildiriminin bir kopyası, hata veya özellikle ilişkili düzeltme kaydına yapıştırılır. Kayıtlar arasında arama yaparken, düzeltme/özellik ne gerektirdiğine dair bir fikre sahip olmanın çok kullanışlı olduğunu görüyoruz.

1
Sparky

Değişikliklerinizin bağımsız birimler olarak girebilecek bölümlerini arayın.

Çoğu zaman, kodda çalışan bir düzeltme veya geliştirme yaptığım zaman, birkaç değişiklik var. Bazıları benim için davranış davranışına özgüdür; diğerleri bu değişikliği daha temiz hale getirmek için yaptığım refactorings.

Her bir yeniden düzenlemeyi ayrı ayrı, kendi değişiklik açıklamasıyla kontrol etmeyi tercih ederim:

REFACTORING: X'i Y olarak yeniden adlandır

X daha önce mantıklıydı çünkü ... ama şimdi Y olmalı. Bu sayı 9 için çalışmakla ilgili.

Daha sonra, her iyi yeniden düzenleme kontrol edildiğinde, nihai davranış değişikliği genellikle önemsizdir.

Ayrıca, bazı değişiklikler birçok kod satırını etkiler, ancak çok ilginç değildir, diğer değişiklikler çok yerelleştirilmiştir, ancak önemli bir etkisi vardır. Bu değişiklikler birlikte teslim edilirse, farkları okumak zor olabilir. Bu yüzden onları ayrı tutuyorum.

Daha sonra, bir kişi değişim tarihini okurken, olayların mevcut duruma nasıl geldiği ve neden bu şekilde oldukları açıktır. Davranış değişikliğimi geri almak da çok önemli çünkü tonlarca başka düzenlemeyle karışık değil.

1
Jay Bazuzi

Çalışmam için yerel bir hg repo tutuyorum.

  • Ne zaman bir şey kontrol, fark bakmak ve tüm değişikliklerin kabul edilebilir emin olun.
  • Check-in'in önemli özelliğini not etmeye çalışıyorum.
  • Her taahhüt boyutunu tek bir anahtar özellikte tutmaya çalışıyorum.

Bunların en iyisi olduğunu iddia etmiyorum, ama benim için çalışıyorlar.

0
Paul Nathan

Birinden ödünç aldığınız bir şeyi iade ederken ne yapacağınızı yapın. Temiz ve iyi durumda olduğundan emin olun. Bir karışıklık yaptıysanız, kodu sahibine iade etmeden önce temizlediğinizden emin olun (çoğu durumda işvereniniz).

0
Jason

Teslim edilmesi amaçlanmadığını bildiğim bir kod yazdığımda, önce "// TEMP:" ve ardından "// END TEMP" ile bir satır ekliyorum. Bu, check-in önce diff yapıyor ile birlikte, yanlışlıkla bu kodu kontrol olmaz vaat ediyor.

0
user17815

Eklediğiniz veya değiştirdiğiniz her şeyi iyice test edin. Denemek için aklınıza gelebilecek her olası durumu deneyin. Testi KG'ye bırakmayın. Her seferinde küçük bir değişiklik yaptım ve sonra sadece güvenli tarafta olmak için bazı test durumlarını denedim ve hemen problem gördüm, bir sürü sandviçim olsaydı. Genelde kendime yüksek sesle söylerim "Bunu denediğim için gerçekten çok memnunum ..."

Değişiklikten sonra arayüzün garip hale geldiğini söylüyorsun. Giriş yapmadan önce programı çalıştırıp kullanıcı arayüzüne bakarsanız, sorunu fark eder miydiniz?

0
Ken