Proje neredeyse bitti, ancak usul spagetti kodu. Yeniden yazıyor muyum yoksa göndermeye devam mı ediyorum? [kapalı]

Ben acemi bir web geliştiricisiyim (bir yıllık deneyim).

Mezun olduktan birkaç hafta sonra, sahibi teknik eleman olmayan bir şirket için web uygulaması yapmak için bir iş teklif ettim. Beni bir hizmet şirketi tarafından talep edilen yüksek geliştirme maliyeti fikrinin çalınmamasından ve uzun süredir devam ettirmek için uzun süredir devam ettirecek projeyi sürdürmek için güvenebileceği genç birisine sahip olmam için beni işe aldı. ).

O zamanlar olduğu gibi ukala, bilgisayar bilimi diplomasına sahip bir şey yapabileceğimi düşündüğüm teklifi kabul ettim.

Çekimleri çağırıyordum. Bazı araştırmalardan sonra PHP'ye yerleştim ve düz PHP ile başladım, nesne yok, sadece çirkin prosedür kodu. İki ay sonra, her şey dağınık hale geliyordu ve ilerleme kaydetmek zordu. Web uygulaması çok büyük. Bu yüzden hayatımı kolaylaştıracak bir MVC çerçevesini kontrol etmeye karar verdim. İşte PHP topluluğundaki havalı çocuğa rastladım: Laravel. Onu sevdim, öğrenmesi kolaydı ve hemen kodlamaya başladım. Kodum daha temiz ve daha düzenli görünüyordu. Çok iyi görünüyordu.

Ancak yine web uygulaması çok büyüktü. Şirket, açıkça dağıtmak istedikleri ilk sürümü sunmam ve müşterileri aramaya başlamam için baskı yapıyordu.

Laravel çalışmak için eğlenceli olduğu için, bu endüstriyi neden ilk tercih ettiğimi hatırlattı - boktan eğitim sistemine takılıyken unuttuğum bir şey.

Böylece geceleri küçük projeler üzerinde çalışmaya başladım, metodolojileri ve en iyi uygulamaları okudum. OOP'u tekrar ziyaret ettim, nesneye yönelik tasarım ve analizlere geçtim ve Bob Amca'nın Temiz Kod kitabını okudum .

Bu, gerçekten hiçbir şey bilmediğimi fark etmeme yardımcı oldu. Yazılımın nasıl inşa edileceğini bilmiyordum. Ancak bu noktada çok geç oldu ve şimdi neredeyse bitti. Kodum hiç temiz değil, sadece spagetti kodu, bir hatayı düzeltmek için gerçek bir acı, tüm mantık kontrolörlerde ve nesne odaklı tasarım az.

Bütün bu projeyi yeniden yazmak zorunda kalacağım konusunda bu ısrarcı düşünceye sahibim. Ancak, yapamam ... Her şeyin ne zaman biteceğini sormaya devam ediyorlar.

Bir sunucuda konuşlandırılmış bu kodu hayal edemiyorum. Artı, kod verimliliği ve web uygulamasının performansı hakkında hala hiçbir şey bilmiyorum.

Bir yandan, şirket ürünü bekliyor ve artık bekleyemez. Öte yandan, kendimi gerçek kodla daha ileriye giderken göremiyorum. Bitirebilir, sarar ve konuşlandırırdım, ama tanrı yalnızca insanlar kullanmaya başladığında neler olabileceğini bilir.

Yeniden yazıyor muyum, yoksa sadece gemiyi denemeye devam mı ediyorum, yoksa kaçırdığım başka bir seçenek var mı?

Pek çok CS eğitiminin aşil topuğuna rastladınız: size araç ve teknikleri öğretiyorlar, ancak ticareti değil. Yazılım oluşturma, yalnızca yıllarca alıştırma yaptığınız ve yazılımınızı kullanma deneyiminizle edindiğiniz bir yazılımdır (kullanıcılar öğretmenlerden çok daha sert eleştirmenlerdir). Yapı yazılımı da oldukça sık bir iş, iş hedefleri teknik hırsları geçersiz kılabilir.

Her şeyden önce, gemi. İşletme sahibine yazılımı gösterirseniz ve gönderilmeye hazır olduğunu düşünüyorlarsa, o zaman gemi gönderin. Eğer o noktaya gelmediyse, ama kapat, bitir. Önemli olan tek şey gerçekten kullanılan yazılımdır. Para kazanan tek yazılım işi, ürünü olan şirkettir.

İkincisi, birçok değerli şey öğrendiniz, bu yüzden size öğrettiği deneyimleri takdir etmelisiniz :

1. Bir plan veya mimarisiz sling kodu felaket için bir reçetedir
2. Programlamada kod yazmadan çok daha fazlası var
3. Teknik olmayan işletme sahipleri genellikle teknik kararların (işe alınacak olanlar gibi) etkisini anlamamaktadır ve geliştiricilerin kendilerine açıklama yapması söz konusudur.
4. Sorunların çoğu, mevcut çerçevelerde çözdüğünüzden çok daha iyi çözüldü. Var olan çerçeveleri ve ne zaman kullanmaları gerektiğini öder.
5. Okuldan yeni çıkmış, rehberliği az olan büyük bir projeye atanmış insanlar bir kase makarna kodu üretme eğilimindedir. Bu normal.

İşte size nasıl devam edeceğiniz konusunda daha fazla öneri:

1. İletişim, iletişim, iletişim. Emin değilseniz ve birden fazla yol görseniz bile, projenin durumu ve nasıl devam edeceğiniz hakkında fikirleriniz konusunda çok açık ve açık olmalısınız. Bu, işletme sahibine ne yapılması gerektiğine dair bir seçenek bırakmaz. Bilgiyi kendine saklarsan, seçimlerden mahrum kalırsın.
2. Tam yeniden yazma işleminin cazibesine karşı koyun. Siz yeniden yazarken, işletmenin ürünü yok. Ayrıca, bir yeniden yazma nadiren düşündüğünüz kadar iyi olur. Bunun yerine bir mimari seçin ve kod tabanını aşamalı olarak taşıyın. Korkunç bir kod temeli bile bu şekilde kurtarılabilir. Size yardımcı olmak için refactoring hakkında kitaplar okuyun.
3. Otomatik test / birim testi hakkında bilgi edinin . Kodda güven oluşturmak zorundasınız ve bunu yapmanın yolu onu otomatik testlerle örtmektir. Bu yeniden düzenleme ile el ele gider. Testlere sahip olmadığınız sürece, manuel ve kapsamlı bir şekilde test edin (kodunuzu kırmaya çalışın, çünkü kullanıcılarınız bunu yapar). Bulduğunuz tüm hataları günlüğe kaydedin, böylece onları önceliklendirebilir ve düzeltebilirsiniz (tüm hataları düzeltmek için zamanınız olmaz, hiçbir yazılım gerçek dünyada hatasız gönderilmez).
4. Bir web uygulamasını nasıl dağıtacağınızı ve çalışmaya devam edeceğini öğrenin. Kitap Web İşlemleri: Zamanında Verilerinizin iyi bir başlangıçtır.

Bu, düzeltmek için bana atılan diğer tüm sistemlere benziyor.

Sakin ol, bu birçok insanın başına gelir. Derinlere atılan ve hiç tecrübesi olmayan, yardımı olmayan, desteği olmayan ve rehberliği olmayan bir genç, başarının tarifi değildir. Küçük bir programcının işe alınmasını ve sıfırdan iyi bir performans sergileyen, iyi performans gösteren ve bakımı kolay bir sistem kurmak için işe alması ve beklemesi ne olursa olsun gerçekçi değildir. Tüm bunlar kıdemli bir programcıda gerçekleşirse cehennem şanslısınız.

Bence temiz gelmek zorundasın. Bu eğlenceli olmayacak. Elinden gelenin en iyisini yaptığını söyle, işe yarıyor (çoğunlukla), ama iyi performans göstermeyeceğinden ve çok fazla böcek olacağından endişeleniyorsun ( her zaman hatalar var). Üst düzey bir programcı tarafından gözden geçirilmesi ve göz kamaştırıcı performans / güvenlik sorunlarını çok hızlı bir şekilde çözebilmeleri gerekir. Ya da konuşlandırıp parmaklarını geçebilirler. Tamam ya da duman çıkacak. Belki sorunları ortaya çıktıkça düzeltebilirsiniz. Büyük bir kullanıcı tabanınız varsa, belki de değil.

Veya bu durumda çoğu insanın yaptığını yapabilirsin: parayı al, kaybol ve onları bırakmalarına izin ver. Etik seçimin ne olduğunu çözmek için size bırakacağım.

Düzenleme (bu soruya oy verebileceği için daha fazla içerik ekleyebilirim)

Programcı olma sevincinin bir kısmı, teknik olmayan kişilerin (muhtemelen yöneticiniz, kesinlikle işin geri kalanı) ne yaptığınız hakkında hiçbir fikirleri olmamasıdır. Bu hem iyi hemde kötü. Kötü yanı, yazılım geliştirme projelerinin nasıl yürüdüğünü sürekli açıklamanız gerektiğidir. Planlama, gereksinimler, kod incelemeleri, test etme, dağıtma ve hata düzeltme. Öyle işinizi testinin önemini açıklamak ve bir kenara test etmek zamanını ayarlamak için. Sen var burada yere basman. İnsanlar önemini anlamayacaklar ( "kullanmaya başlayamaz mıyız?") ancak teste başladıklarında (canlı ortamda değil!) faydaları hızla anlayacaklardır. Sizi işe alma nedenlerinden biri, yazılım geliştirme hakkında hiçbir şey bilmedikleri için onları eğitmek size kalmıştır. Burada test etmenin ve hata ayıklamanın önemini vurgulamanız gerekiyor - unutmayın, programcılar değiller, sıfıra bölme ve kırık bir html etiketi arasındaki farkı bilmiyorlar.

Genellikle, ortaya çıkan sorunların çoğu aslında böcek değildir. Kullanılabilirlik sorunları, cevapsız şartlar, değişen şartlar, kullanıcı beklentileri (neden bunu cep telefonumda kullanamıyorum?) Ve sonra gerçek gerçek hatalar olacaklar. Canlı yayına girmeden önce bunları ütülemeniz gerekir - sık sık birkaç gün sonra bir sürü hata giderilebilir veya giderilebilir. İnsanlar mükemmel bir sistem beklerlerse çok acı çekecekler. Böcek bekliyorlarsa, önümüzdeki birkaç hafta boyunca hayatınız çok daha kolay olacaktır.

Oh ve kullanıcı testlerini birim testleriyle veya sistem testleriyle karıştırmayın.

• Birim Testi - kod işlevim doğru değeri döndürüyor mu
• Sistem Testi - X'e tıkladığımda hata veriyor mu
• Kullanıcı Kabul Testi (UAT) - program şartlara uygun mu? Sizden yapmasını istediklerinizi yapar mı? Yaşayabilir mi?

Yapmanızı istediklerinin gereklerini yazmadıysanız , UAT çok daha zor olacaktır. Burası birçok insanın düştüğü yer. Sistemin kağıda yazılmasını istediklerini elde etmek hayatınızı çok kolaylaştıracak. "Neden X yapmıyor?" Diyecekler. ve "Y yapmamı söylemiştin" diyebilirsiniz. Program yanlışsa düzeltin. Gereksinimler yanlışsa, dokümanı düzeltin, bir veya iki gün daha isteyin (hayır, ısrar), değişikliği yapın, belgeleri güncelleyin ve yeniden test edin.

Birkaç kez bu süreçten geçtikten sonra Agile'ye bakmaya başlayabilirsiniz .. ama bu başka bir dünya :)

TL; DR Testi iyi

Sıfırdan başladığınızda, İkinci Sistem Sendromu nedeniyle neredeyse kesinlikle aynı miktarda veya daha fazla hata yapacaksınız . Yeni hatalarınız farklı olacak, ancak hata ayıklama için gereken süre benzer olacaktır ve bu yüzden uygun olmadığına dair umutsuzluk duyacaktır. Ayrıca, ilk sürüm devreye girerse , şirket için ciddi bir sorun olacak olan, yeni özelliklerin üretilmesine ya da yeni özelliklerin devreye alınmasına neden olacaktır . Joel Spolsky , herhangi bir şirketin veya geliştiricinin yapabileceği "en kötü tek stratejik hata" olarak adlandırıyor .

Önerilen yaklaşım, bakım sırasında ilk karışıklığı yavaşça temizlemek içindir. Ve sadece uğruna canlandırmaya çalışmayın bile. Ayrıca, yöneticiler genellikle para israfı olarak (ki sık sık olduğu gibi) görürler ve yeni hataların ortaya çıkması için gereksiz risk getirirler. Bir kez acı içinde hata ayıkladığınızda, güzel olmayabilir, ancak işe yarayacaktır. Öyleyse başka nedenlerden dolayı dokunmanız gerekene kadar bekleyin (bir hata düzeltmesi, yeni bir özellik veya yalnızca pazarlama tarafından istenen bir değişiklik olabilir). Ardından ayarlanması en zor olan parçaları temizleyin. Bu genellikle Boy Scout Kuralı olarak adlandırılır .

Ve bu noktada müdürle tartışmanız gerekmez. İsteğe ilişkin tahminde yalnızca istenen minimum yeniden düzenleme işlemini dahil edin. Biraz para kazanmayı başarabildiğiniz zaman, deneyim kazanmayı öğreneceksiniz çünkü şirket gerçekten düzeldi ve gelecekte problem yaratmak istemiyorsanız ve hızlıca kesmek için herhangi bir olasılık kabul etmeyin.

Son olarak, önerilen bir okuma daha: Büyük Top Çamur .

Nerede ilk okuduğumu unuttum, ama başkalarının söylediklerini biraz daha kuvvetli bir şekilde yankılanmak istedim:

Kargo bir özelliktir.

Mükemmel bir şekilde çalışan , yeni hatalar ortaya çıkaran vb. (Muhtemelen çirkin, kirli) kodları "temizleyen" birinden daha kötü bir şey yoktur . Gerçek dünyada önemli olan işinizi yapmaktır. Bunu sen yaptın. Gemi. Kaputun altında çirkin olsa bile mükemmel şekilde çalışan bir projenin yeniden tasarımlarında kaybolmayın. Bunu düzeltirken, artımlı olarak yapın ve mümkün olduğu kadar az sayıda gerilemeye sahip olmanız için kendinize iyi bir deneme odası hazırlayın.

Her proje seni öncekinden daha akıllıca bırakır. Her projeden sonra, baştan başladığında çok kullanışlı olacak daha fazla deneyim kazanmış olacaksınız. Her şeyi tekrar ziyaret etmemek ve öğrendiklerinizi uygulamanın zor olduğunu biliyorum. Ama hatırla:

Mükemmel, iyinin düşmanıdır.

Müşteri için artık iyi bir yazılıma sahip olmak, asla piyasaya sürülmeyen mükemmel bir yazılımdan daha iyidir.

Bu sadece ilk projendi. Gelecekte, öğrendiğiniz her şeyi baştan uygulayabileceğiniz çok daha fazla proje olacak.

Ben [...] Bob Amca'nın temiz kodunu okudum.

Bütün bu projeyi yeniden yazmak zorunda kalacağım konusunda bu ısrarcı düşünceye sahibim.

Bu kitap, çok uygun bir şekilde "Gökyüzündeki Büyük Yeniden Tasarım" adlı bir bölüme sahiptir.

Her şeyi yeniden yazmaya çalışmayın, çünkü olası bir vakada, vaktiniz varsa, yine de aynı problemlerle karşılaşırsınız. Yeniden tasarlamayı bitirdiğinizde, yeni şeyler öğrenmiş olacaksınız ve ilk bölümlerinin çok profesyonel olmadığının farkına varacaksınız, böylece tekrar yazmak isteyeceksiniz.

Yeniden tasarlama ve yeniden yazma iyidir, ancak yalnızca çalışan bir sistemde aşamalı olarak yapılırsa. Başka bir kullanıcının belirttiği gibi, üzerinde çalıştığınız sırada kodunuzu azar azar yeniden takarak Boy Scout Kuralını izleyin.

Iyi gidiyorsun.

Kodunun işe yaradığını ve neredeyse gönderilmeye hazır olduğunu söyledin, değil mi? Ve kodunuzun büyük ölçüde geliştirilebileceğini algılıyorsunuz. İyi.

İkileminiz bana serbest konuşma konusundaki ilk deneyimimi hatırlatıyor (çok dilli bir POS sistemi oluşturmak için üniversitedeki 2. yılımda işe alım). Koddan hiç memnun kalmadığım, ölçeklenebilirlik istediğim, daha iyi tekerlekler yeniden icat etmek istediğim için sonsuz bir sorgulama yaptım ... Ama projeyi geciktirdim (yaklaşık 12 ay gibi) ve ... ne? Bir şeyi konuşlandırdıktan sonra hala çok fazla prova, test, yama vb. Gerekir.

Profesyonel kod tabanlarıyla çalışma deneyiminiz var mı? Pek çok kod tabanı, kodları korumak için ilginç ve doludur. Büyük bir program oluşturmaya çalışarak yazılımın karmaşıklığını keşfetmeye bir alternatif, başkalarının yazdığı eşit dağınık kodları korumak / genişletmek olacaktır.

Tamamen yeniden yazım gördüğüm tek durum, takımın eşzamanlı olarak yeni bir araç zinciri / çerçeve benimsemesidir.

Altta yatan mantık (programın yaptığı, işlevler, sınıflar ve diğerleri gibi nasıl ortaya konduğu gibi değil) ses ise, o kadar iyi çalışacaktır, yani spagetti kodunun bunun anlamına gelmediğini düşünürsünüz. konuşlandırılmamalı.

Müşterinizin kullanabileceği bir şey edinmesine izin vermelisiniz. Ardından, sizden geliştirmeyi / işlevsellik eklemenizi istediklerinde, bir yeniden düzenleyicinin gerekip gerekmediğine karar verirsiniz ve müşterinize "söz konusu yeni özelliği entegre etmek için bazı teknik çalışmalar yapılması gerektiğini" bildirmeniz tamamdır. Bu sayede onlara daha fazla paraya mal olacağını ve daha uzun süre beklemek zorunda kalacaklarını anlayacaklar. Ve onlar anlayacaklar (ya da çıkarabilirsiniz).

Her şeyi yeniden yazmak için daha iyi bir zaman, başka bir müşteri sizden benzer bir şey yaratmanızı istediğinde olur.

Kısacası, konuşlandırıldığında her şeyin herkesin yüzüne patlayacağını göstermediğiniz sürece, konuşlandırmayı geciktirmek profesyonelce olmaz ve sizin ya da müşterinizin yararına olmaz. Hataları giderirken veya yeni özellikler eklerken küçük refactorler yapmayı öğrenmek sizin için değerli bir deneyim olacaktır.

Sorunuza cevap olarak söyleyeceğimlerin çoğu başkaları tarafından söylendi. Joel Spolsky tarafından "Yapmanız Gerekenler, Kısım I" ("mimarlık astronotları" ile ilgili bazı yayınları ile birlikte) okuyun. Unutma ki "mükemmel, iyinin düşmanıdır". Artımlı olarak refactor öğrenin. Nakliye önemlidir, vb.

Ekleyeceğim şey şudur: Küçük bir başlangıç ​​bütçesi / zaman dilimi ile çalışan tek bir yeni mezun tarafından yapılabilecek bir şeyle görevlendirildiniz. İyi, yapılandırılmış, prosedürel programlamadan daha karmaşık bir şeye ihtiyacınız olmamalıdır . (Ve, FYI, "prosedürel programlama" kötü bir kelime değildir. Çoğu durumda bir düzeyde bir zorunluluktur ve çoğu proje için tamamen yeterlidir.)

Sadece gerçekten emin yapmak yapılandırılmış, prosedürel programlama. Kodunuzdaki tekrarlama mutlaka büyük, polimorfik yapılara ihtiyacınız olduğuna dair bir işaret değildir. Basitçe, tekrarlanan kodu almanız ve onu bir alt programa koymanızın bir işareti olabilir. "Spagetti" kontrol akışı basitçe küreselden kurtulmak için bir fırsat olabilir.

Projenin yasal olarak polimorfizm, uygulama mirası vb. İçin çağrılan yönleri varsa, projenin boyutunun belki de küçümsendiğini öneririm.

Sahip olduğunuz ikilemle gerçekten ilgileniyorsanız, "Yalın Başlangıç" bölümünü de okumalısınız. Burada verilen tavsiyelerin çoğu, bu kitabı okursanız daha fazla yankılanacaktır. Temel olarak, kaynak yazma hızı sizin en kötü düşmanızdır ve hiçbir şey sizin ve kuruluşunuz için son kullanıcı / müşteri geri bildirimlerinden daha değerli değildir. Bu nedenle, ürününüzü geçerli bir duruma getirin (Minimum Uygun Ürün - veya MVP) ve daha sonra (kodun gerçekte nasıl göründüğüne bakılmaksızın) kapıdan gönderin. Müşterilerinizin gelecekteki değişiklik setleri ve sürümlerini dikine almasına izin verin, tersi değil. Bu yaklaşıma odaklanırsanız, hem patronunuz hem de uzun vadede daha mutlu olacaksınız.

Başkalarının ayrıntılı olarak açıkladığı nedenlerden dolayı, projeyi bitirme ve göndermenin zamanı geldiği kadar acı verici bir zamandır.

Sadece uygulamayı test etmenin de "bitirmenin" bir parçası olduğunu vurgulamak istiyorum . Önemli işlevsellik parçalarının tamamı yerine getirilmediyse ve doğru sonuçlar onaylanmadıysa, konuşlandırıldığında insanların bu uygulamada sorun yaşayacağına dair endişeleriniz doğrulanır.

Birim testleri ve otomatik üst seviye testleri mükemmeldir ve bu uygulamayı yeniden düzenlemeye (veya yeniden yazmaya) başlamadan önce elinizden gelenin en iyisini yapmanız gerekir. Ancak şu anda , her testi "elle" yapmanız ve doğru işlevi "gözle" onaylamanız gerekse bile, temel olarak test etmeniz gerekir. Bu testleri daha sonra nasıl otomatikleştireceğinizi öğrenebilirseniz, bu, ürünün bir sonraki sürümünde çalışmaya başlama zamanı geldiğinde yardımcı olacaktır.

Bazı insanlar, alfa testi kullanıcısı olarak yeni bir yazılım projesinin önünde oturmak ve işleri tersine çevirmek için bir şeyler yapıyorlar. Yani, bir şeyleri kırmakta iyidirler. Böyle yetenekli bir insanın sizinle birlikte çalışabilmesi için yeterince şanslıysanız, önce uygulamayı deneyebilmelerini sağlayın; Bu görevi kendiniz yapmak zorundaysanız, o zaman:

• Metodik olun.
• Her özelliği dene.
• Uygulamanızla ilgili deneyimsiz bir kullanıcı gibi davranın. Aptalca hatalar yapın ve yazılımın bunları nasıl idare ettiğini görün.
• Yaptıklarınızı bir yere yazın, böylece sorunları çözdüğünüzü düşündükten sonra tekrar deneyebilirsiniz.

Sorunuz: "Yanlış başladım, baştan başlamalıyım mı" diyor, ek metin ise "Tamamlandı proje, ancak yanlış yaptım, baştan başlamalıyım" diyor. Yalnızca soru başlığı için: Yaptığınız programlama işi miktarı, gereken toplam çalışmaya kıyasla küçükse, baştan başlamak mantıklı olacaktır. Sorun karmaşık ve kötü bir şekilde anlaşıldığında ve sorunun gerçekte ne olduğunu bulmak için epey zaman harcanması çok olur. Kötü bir başlangıçla devam etmenin bir anlamı yok, eğer atmak ve her şeye baştan başlamak, bu sefer problemi iyi anlamakla, aslında daha hızlı bitireceğiniz anlamına gelir.

Kişisel olarak yapacağım şey bu:

1. İstifa et, bir bahane bul ve pes et (hatta maaşının bir kısmını geri ver, böylece kötü görünmüyorsun)
2. Kodunuzu mümkün olduğunca temizleyin
3. İyi tasarımınız, iyi fikirleriniz vb.

Neden hepsini sana öneriyorum?

Çünkü geleceği düşünün. Gelecekte, belirli kişilerin bu kodu alması için zaman olacaktır. Senin ve yeteneğin hakkında her türlü varsayım ve kararları verecekler. Ne zaman yazdığın umrunda değil, durumu umursamıyorlar. Sadece içinde neyi onaylamak istediklerini onaylamak için neyi görmek istediklerini görmek isterler.

Sizi olumsuz yönde etkilemek için bulabilecekleri kötü isim ne olursa olsun markalı olacaksınız. Gelecekte sizlerin teknik yetenek, beceri, bilgi, üslup açısından durum tamamen farklı olsa da ve durum çok farklı olsa da, bu kod size karşı mümkün olan her şekilde kullanılacaktır. Sizinle, kodunuzla ve tasarımınızla ilgili tüm kötü şeyleri söyleyebilecekleri bir mahkeme gibi ve bunun farkında bile değilsiniz, böylece kendinizi açıklayabilir ve savunabilirsiniz. (ve çok sık, onların tekrar tekrar derinden yanlış olduklarını öğrenebilirsiniz). Pes etmek.

İnan bana, seninle ilgili çok fazla varsayım yapan insanlar var, çünkü her hangi bir amaç için bir amaç için bir şey yaptın. Onlara, A durumunda böyle yaptıysanız, B durumunda yapacaksınız. Çok basit düşünüyorlar.

İki öneri daha, yapmadıklarından en az birine bahse girerim.

1) Bir hata izci koyun ve patronunuza kullanmayı öğretin. Bu, nasıl batırdığın, daha iyi öğrendiğin ve planlı bir şekilde düzeltecek olan konuşmanın bir parçası olabilir.

2) Sürüm kontrolünü kullanmaya başlayın, umarım çoktan yapmışsınızdır.

Dışarıda ikisinin de küçük hesaplarda ücretsiz olmasını sağlayan çok sayıda barındırılan sistem var. Özellikle, patronunuza işleri iyi idare edilmiş bir şekilde hallettiğinizden daha fazla emin olacak harika bir tahmin ve görev tamamlama sistemine sahip olan FogBugz'a bayılıyorum.

Düzenle

Vay canına, birisi gerçekten böyle değildi - bir aşağı oy VE bir silme bayrağı? Neden?

Otuz yılı aşkın bir süredir birçok danışmanlık işi ve başkalarının kurallarını miras alan yazılımlar geliştiriyorum. Gördüğüm sorun sistemlerinin büyük bir kısmı insanların bir çukur kazdıkları ve oraya nasıl gittikleri hakkında ayrıntılı notlar almadıkları ya da sürüm kontrolü yapmadıkları yerlerdi.

Sorunuzu cevaplamak için: diğerlerinin söylediği gibi, hayır. Gönderin ve hataların giderilmesi sürecinde azar azar temizleyin.

Ek olarak, books / StackExchange / webforums iyi bir öğrenme kaynağı olsa da, hiçbir şey için çalışmaktan alacaksınız (ya da sadece çalışmanızın tartışılması) ile diğer programcılar arasında yapabileceğiniz bir şeydir. Kullanmakta olduğunuz veya öğrenmek istediğiniz bir teknoloji için yerel bir grup bulmak ve katılmak, zamanınızın harika bir yatırımıdır. Edinilecek olan teknik bilginin yanı sıra, gelecekteki gösterileri dört gözle beklediğiniz için paha biçilmez bir ağ oluşturmak için kolay bir yoldur.

Patronun seni işe aldığında deneyim seviyesinin farkındaydı. Sadece endişelerinizi dile getirin ve endişelendiğinizi ona bildirin. Ayrıca bir sonraki projeyi ne kadar öğrendiğinizi ve ne kadar iyi yapabileceğinizi de ona bildirin.

Yeni bir web geliştiricisisiniz, size tavsiyede bulunacak iyi bir geliştirici bulunmuyorsa, patronunuz bunu tamamen iyi bilmenizi sağladı. Sanırım, sizden beklediğiniz kadar iyi yapıyorsunuz. Aslında, işin daha iyi olabileceği ve aslında daha iyi yapmanıza izin verecek şeyleri öğrenmiş olmanızın içgörüsüne sahip olmanız, çoğundan daha iyi yaptığınız anlamına gelir. Akıl sağlığınız için, işe başlayan sürümünüzün daha iyi olamayacağını unutmayın. Daha deneyimli (ve bu nedenle daha iyi ödeme yapılan) veya deneyime değer bir projeye sahip olan bir kişi daha iyi yapabilirdi.

Şimdi ne yapmalı : Bir yıl öncesine göre daha iyi bir geliştirici olduğunuz için mutlu olun. Bir sonraki proje daha iyi olacak (ve sonunda tekrar daha deneyimli olacaksın ve yaptıklarından memnun değilsin; bu normal). Son projeyi değiştirmek veya yeniden yazmak, işletmeye maliyet açısından çok az fayda sağlayacaktır. Yapabileceğiniz şey, yine de değişiklik yapmanız gerektiğinde hatalı kodu iyi kodla değiştirmek; Bu mantıklıdır çünkü kötü bir şekilde korunabilir kodu değiştirmek, iyi bir kodla değiştirmekten daha zor olabilir. Ve yardımcı olacak yeni bir deneyimsiz geliştirici edinirseniz, onlara bu kodun kopyalamaları gereken bir örnek olmadığını söyleyin .