Neyin yanlış gidebileceği konusundaki bilginin artması nedeniyle yavaş problem çözmenin üstesinden gelmek [kapalı]

Bu beni bir süredir rahatsız ediyordu ve diğer profesyonellerin katılımını gerçekten takdir ediyorum.

Kısa geçmiş: 1988 yılında ailem bana ilk bilgisayarımı aldığında programlama yapmaya başladım (14 yaşında, şimdi 39 yaşındayım). 1997'de profesyonel bir programcı olmadan önce birkaç başka kariyer yolunu izledim. Geç çiçek açmış, belki de, ama öyleydi. Seçimimden hala memnunum, programlamayı seviyorum ve yaptığım işte kendimi iyi görüyorum.

Son zamanlarda, daha fazla tecrübe kazandıkça, projeleri tamamlamamı veya bir projedeki belirli görevleri daha uzun sürdüğünü fark ettim. Henüz senil olmayacağım. Sadece olayların yanlış gidebileceği birçok farklı yol gördüm. Ve bildiğim ve hatırladığım potansiyel tuzaklar ve yakalananlar giderek daha da artıyor.

Önemsiz örnek: sadece "tamam, buraya bir dosya yaz" dır. Şimdi izinler, kilitleme, eşzamanlılık, atomik işlemler, dolaylı / çerçeveler, farklı dosya sistemleri, bir dizindeki dosya sayısı, öngörülebilir geçici dosya adları, PRNG'mdeki rastgelelik kalitesi, herhangi birinin ortasındaki güç kesintileri konusunda endişeleniyorum. İşlem, ne yaptığım için anlaşılır bir API, uygun belgeler, vb.

Kısacası, sorunlar uzun zamandan beri "bunu nasıl yaparım" dan "yapmanın en iyi / en güvenli yolu" ndan geçti.

Sonuç olarak, bir projeyi acemilikten daha uzun sürebilir. Sürümüm çok sağlam olabilir ve nasıl yapacağımı bildiğim kadar aşılmaz olabilir, ancak daha uzun sürüyor.

Yukarıdaki "dosya yarat" örneği sadece bir örnekti. Gerçek görevler daha karmaşık, ama bunun gibi genel bir soru için daha az uygun. Umarım bununla nereye gittiğimi anlıyorsundur. Verimli algoritmalarla ortaya çıkmakta sorunum yok, matematiği seviyorum, karmaşık konulardan zevk alıyorum, konsantrasyonda zorluk çekmiyorum. Sanırım deneyim konusunda ve dolayısıyla bir hata korkusuyla (içsel veya dışsal) bir sorunum olduğunu düşünüyorum.

Günde neredeyse iki saatimi yeni gelişmeler, yeni teknikler, diller, platformlar, güvenlik açıkları ve benzeri konular hakkında okumak için harcıyorum. Anlaşma, ne kadar fazla bilgi edinirim, projeleri o kadar yavaşlatıyorum.

Nasıl anlaştın onunla birlikte?

Projeleri tamamlamada hiç yavaş değilsin. Daha önce, acemi projelerinizin gerçekten olmadıklarında yapıldığını düşünmüştünüz. Bu kaliteyi müşterilere satmalısınız.

"Bu şirket daha hızlı ve daha ucuz hale getirebilir, ancak gerçekten yapıldı mı? Yoksa yıllarca böcek avlayacak mısın?"

Bunun ötesinde, eski deyimi bilmeniz ve kabul etmeniz gerekir: "Mükemmel, iyinin düşmanıdır."

Karanlık tarafa katılma zamanı geldi gibi geliyor: yönetim.

Programlamadan vazgeçmeni ve yönetici olmanı önermiyorum. Ancak şu ana kadar alıntı yaptığınız tüm deneyimler doğada teknik olmuş gibi görünüyor. Basit bir dosya yazma işlemi, daha az olgun bir geliştirici asla düşünmeyeceği 10 farklı yönden düşünebilirsiniz. Kötü bir şey değil, ama ...

Karanlık taraf, şimdiki değer ile ilgili. Maksimum kazanç için minimum yatırım yapmakla ilgilidir (fayda-maliyet analizi). İş dünyasında her şey bana ne kadara patlayacak, başarı olasılığı, başarısızlık olasılığı, muhteşem başarısızlık olasılığı ve potansiyel kazanç. Matematik yap; uygun davran.

Bir geliştirici olduğunuzda da işe yarar: geçici bir dosya oluşturun, izinleri ve isim çakışmalarını yok sayarak - 5 dk. Net kazanç, ekibin geri kalanı o dosyanın varlığına bağlı olarak hangi kodun üzerinde çalıştığıyla başlayabilir. Mükemmel bir çözüm mü? Kesinlikle hayır. % 99,% 95, belki% 90'ı alacak mı? Evet, muhtemelen olacak.

Sorulması gereken bir başka soru: Teknik borç hakkında ne düşünüyorsunuz? Bazı insanlar ortadan kaldırılması gerektiğini düşünüyor. Bence bu insanlar yanılıyor. Tıpkı iş dünyasında olduğu gibi, teknik borç da daha kısa sürede bir şey sunmak için "nakit" veya "zaman" ödünç almanıza izin verir. Hangisi daha iyi: 2 yıl içinde mükemmel bir çözüm mü yoksa bir müşterinin 4 ayda kullanıp satın alabileceği tam bir kesmek mi? Her durum farklıdır, ancak bazı durumlarda 2 yıl beklerseniz, müşteriniz zaten rekabetinize katılacaktır.

Kilit nokta, teknik borcun iyi yönetilen bir işletmenin finansal borcu yönettiği gibi yönetmektir. Yeterince almazsanız, optimum yatırım getirisi elde edemezsiniz. Çok fazla alırsanız, ilgi sizi öldürür.

Öyleyse benim tavsiyem: Çalışmanızı, titizliğinizi en üst düzeye çıkarmak yerine değerinizi en üst düzeye çıkarmak olup olmadığına göre değerlendirmeye başlayın. Ve bunu uygularsanız, teknik alanda daha önce geliştirdiğiniz sezgiyi de geliştirirsiniz.

Yan not olarak, yakın zamanda pomodoro tekniğini yapmaya başladım ve çok yardımcı oldu. Bir teğetin teğetine girmek yerine, küçük zaman aralıklarında odaklanın ve daha sonra gelecekteki çalışmalar / araştırmalar için pomodoros tahsis edin. Bir konuyu araştırmak için kaç kez not almam şaşırtıcı ama bir saat sonra zaman geldi, kendime şöyle düşündüm, "bugün zamanımla birlikte daha değerli olan en az 3 başka şey yapabilirim."

Birkaç yıl önce (muhtemelen) aynı problemi yaşadım, birkaç yıl sürdü ve üstesinden geldim. Bu yüzden belki de, benim tarzımın sizin için de geçerli olacağından emin olmasam bile, bunu nasıl başardığımı bilmek sizin için ilginç olacaktır.

Ayrıca burada bir göz atmalısınız: Yazılım Mühendisliğinde Yedi Uzmanlık Aşaması Verimliliğin büyük ölçüde beceri seviyesinin bir yan etkisi olduğunu gösteriyor. Halen kullanmakta olduğunuz teknoloji konusunda aşama 3 ve aşama 4 arasında hala bir noktada olabilirsiniz (beceri yeterliliği teknolojiye bağlıdır, diğerlerini öğrenirken bazı teknolojilerin ustası olabilirsiniz).

Şimdi biyografik tanıklıkla başlıyorum.

Biraz içerik. 47 yaşındayım. 80'lerde 12'de programlamaya başladım. Lisedeyken yarı zamanlı profesyonel oyun programcısı olarak da çalıştım. Temel olarak bana o kadar para alamadı, sadece donanım almaya yetti, ama çok eğlendim ve çok şey öğrendim. 18 yaşında resmi bir Bilgisayar Bilimleri öğrenmeye başladım.

Sonuç olarak, 20 yaşına geldiğimde, herhangi bir programlama görevine başlarken, verilen sorunları çözmenin birçok yolunu biliyordum ve eldeki birçok parametre ve tuzaklar ve her yöntemin dezavantajları ve sınırlarının çok farkındaydım.

Bazı noktalarda (yaklaşık 26 yaşında) herhangi bir program yazmam çok zor oldu. Açılan o kadar çok olasılık vardı ki aralarında seçim yapamadım. Birkaç yıl boyunca (6 yap) Programlamayı bıraktım ve teknik bir haber yazarı oldum.

Yine de programlamayı denemekten asla vazgeçmedim. Ve bir noktada geri geldi. Benim için kilit nokta aşırı programlamaydı, özellikle de Sadelik ilkesiydi: “Muhtemel İşleyebilecek En Basit Şey Yaz”.

Temelde kod verimliliğini önemsememeye zorlamıştım (bu benim ana engelimdi, verimsiz tasarımlardan kaçının), ama sadece en kolay yoldan gitmeliyim. Ayrıca beni hataları daha az görmeye zorluyorum ve hatayı yükselten testler yazdıktan sonra daha sonraki bir zamana kadar hata işlemeyi geciktirdim (gerçekten TDD).

Bu yazarken öğrendiğim bir şey. Ne yazacağımı bilmediğimde veya yazdığımın kötü olduğunu biliyordum . Sadece devam et. Aslında kötü şeyleri yaz. Sonunda daha sonra düzelteceğim. Ya da gerçekten o kadar kötüyse, onu silin ve yeniden yazın, ancak ilk seferinde mükemmel bir şeyler yazan şeyleri iki kez yazmak daha hızlı olur.

Gerçekten de, ilk yazarken iyi olduğuna inandığınız bir kodun gerçekten kötü bir kod kadar iyileştirilmesi gerekeceği çok muhtemeldir.

Sadelik yolunu izlerseniz, ayrıca bir bonus kazanırsınız. İlk tasarım / kodlamayı çıkarmayı / değiştirmeyi kolayca kabul edersiniz. Daha esnek bir zihin elde edersiniz.

Ayrıca, şu anda ne yapmadığımı açıklayan ve daha sonra normal kullanım durumunda kodun ne zaman işlevsel olacağını düşündüğümüzü açıklayan geçici bir yorum yapma alışkanlığına girdim.

Ayrıca, XP uygulamalarını içselleştirmek için diğer programcılarla birlikte uygulanmış bir kod katas olan bir XP Dojo'ya katıldım. Yardımcı oldu. Yukarıdaki resmi yöntemleri içgüdüsel kılmıştır. Çift programlama da yardımcı oldu. Genç programcılar ile çalışmak biraz hız veriyor, ancak deneyimlerle ne yapmadıklarını da görüyoruz. Mesela benim durumumda sık sık aşırı karmaşık tasarımlara girdiklerini görüyorum ve yol açabilecek tasarım kabuslarını biliyorum. Bu tarafa gitti. Bunu yaptım. Sorun vardı.

Benim için en önemli nokta akışı korumak. Hızlı olmak, akışı korumada gerçekten başarılı oluyor.

Şimdi profesyonel bir programcı olarak döndüm ve yaptığım şeyi daha iyi anladığım için hem daha iyi hem de daha hızlı olduğuma inanıyorum. TDD Uygulaması, küçük bir boğa olduğumdan biraz daha yavaş olabilir (ve hiçbir şeyi test etmedim), fakat aynı zamanda yeniden yapılanma korkusu da yok ve kesinlikle hata ayıklamada daha az zaman harcıyorum (neredeyse hiç zaman yok, zamanın% 10'undan azını yapıyoruz) ).

Özetle: çevik yöntemler (XP) kullanarak kod basitliği aştım, sadelikten sonra yeniden yapıştırarak ve içgüdüsel hale getirmek için pratik yaparak. Benim için çalıştı. Bundan başkalarına genelleştirilebileceğinden emin değilim.

Beceri kazanma seviyesi açısından, çoğunlukla teknolojiyi her değiştirdiğimde (yeni dil, yeni çerçeve, vb. Öğrendiğim) yavaşladığımda bir aşamadan geçeceğimi kabul etmeyi öğrendim. Bu normaldir ve sonunda bunun üstesinden gelecektir. Bunu iyi bir metodoloji ve genel amaçlı programlama becerileri ile telafi edebilirim ve bu bir sorun olmayacak.

Programlamanın önemli bir kısmı karmaşıklığı yönetmek ve kontrol etmektir ve şahsen benim için en önemli konulardan biridir. Yok sayılırsa, eksiklik sıklığı artar veya durumunuzda olduğu gibi, bitmiş yazılımın ETA'sı çarpıcı şekilde artar.

Yazılım karmaşıklığı birçok farklı düzey ve yoldan kontrol edilebilir ve yönetilebilir, ancak bir bakış açısı elde etmek için iyi bir kuraldır: "Herhangi bir yazılım projesinin birinci önceliği beklentilerinin bir işlevi olan müşteri memnuniyetidir."

Başka bir deyişle, yazılımın karmaşıklığı, müşterinizin beklentilerini kontrol etme konusunda ne kadar yetenekli olduğunuza bağlıdır.

Bir kişi bu görüşü benimsediğinde, iki önemli nokta açıkça ortaya çıkıyor:

1. müşteri beklentileri açıkça belirtilmelidir (ne şekilde olursa olsun);
2. müşteri beklentileri her zaman değiştirilebilir ve bu müzakere sanatı ile yapılır.

Örneğin çok iyi bir örnek, "basitçe" "diğer düşüncelerin sayısız" ı. Bir düşünün - eğer birisi her iki değişken için de ayrıntılı gereklilikleri yazacak olsaydı, tarif edilen özelliklerde bir eşdeğerlik olabilir mi?

Bir F16 oluşturmak, ikisi de uçabilmesine rağmen bir Cessna oluşturmaktan farklıdır.

Basit cevap: kabul et.

Tüm sistemlerde, güvenilirlik, sağlamlık, güvenlik, hız, donanım maliyeti, geliştirme maliyeti, pazara çıkış zamanı, arasında isimlendirmeler yapabileceğiniz takaslar vardır. Müşterinin bu takası nasıl yaptığını her zaman kabul etmeyeceksiniz, ancak bu kararları veren siz değilsiniz. Yapabileceğiniz tek şey, düşünülmüş bir fikir vermektir. Yazılım geliştirme, "kişisel web sayfamdan" "nükleer reaktörü çalıştırma" ya kadar tüm gamı ​​kapsar ve kodun buna göre yazılması gerekir. Bir çarpışma "kişisel web sayfamı yeniden yükle" anlamına geliyorsa, bunun gerçekleşmesi kimin umurunda? Fakat eğer bir çarpışma "Çernobil" anlamına geliyorsa, katı kod tercihiniz sizin için bir şeyler olabilir.

"Proof of Concept" seviye kodunu mutlu bir şekilde kabul edecek ve canlı sistemlerinde çalıştıracak bazı müşteriler var ve sıklıkla buna alışmış sistem yöneticileri var. IME sistemleri, bir sürü zamanlanmış yeniden başlatma işlemi gerçekleşirken, gecenin ortasında genellikle bir saat kadar kullanılamaz. Ancak iş kararını böyle almak istediklerine karar verdiler. İdeal olarak, sahaları o kadar hızlı hareket eder ki, yüksek kaliteli kod hiçbir zaman hazır olmaz, ancak çoğu zaman değeri göremedikleri için (bir sistem "sadece çalışırsa" asla farketmezler, bu nedenle sistem için değeri temsil etmez) para). Sizi çok rahatsız ediyorsa, bu müşterilerden uzak durmaya çalışın.

Güncel kalmak, hepimizin harcamak zorunda olduğu veya en azından harcaması gereken zamandır. Bazen bu sizi çalışmaya zorlar, bazen de zihninizi iyi durumda tutar. Her iki durumda da, tadını çıkarmaya çalışın.

Yetenekleriniz çok kaliteli görev kritik sistemler gelişimi için çok yararlı olacak gibi görünüyor, finans / ticaretle ilgili uygulamalar, yayın, havacılık, savunma ...

Bu tür uygulamalardaki hatalar çok maliyetlidir ve tüm davaları ele alabileceğiniz gibi sizin gibi düşünen insanları kullanır.

Gerçek şu ki, modern sistemler giderek daha karmaşık hale geliyor. Bilgisayar şimdi, bu parçaların hepsinin diğerlerine güvendiği “Jenga” oyununa benzer. Yanlış parçayı çekip çıkardığınızda bir hata oluşur, doğru / gerekli parçayı çıkarın ve yine de hata üretebilirsiniz. Sistem ne kadar karmaşıksa, kodunuzu daha sağlam ve umarım daha güvenli hale getirmenin yollarını düşünerek daha fazla zaman harcarsınız. Hız iyi olurdu, ama haberlerde “XYZ” şirketinin saldırıya uğradığını ve 6 milyon müşterinin kredi kartı numaralarının çalındığını duyduğunuzda hızın çok fazla arka koltuk aldığını düşünüyorum.

Müşterileriniz programlarının güvenli, sağlam, vs. olması gerektiğini duymak istemeyebilir. o?

Eğer fazla düşünmeye çalışıyorsanız, işleri doğru şekilde yapacaksınız, bunun dışında "somut" görünen bir strateji seçmeniz ve onunla devam etmeniz yeterlidir.

Yanlış gidebilecek her şey hakkında düşünme eğiliminizin farkında gibisiniz.

Tecrübeli Temkinli Geliştiriciler genellikle mantrayı takip etmeyi öğrenirler YAGNI, başarısızlık modu-analizi-gitti-amok yabancı otlarına çok boğulduktan sonra, zayıf, çevik ve üretken bir iş akışına geri dönmeye çalıştıklarında ihtiyaç duymazsınız.

Bununla birlikte, eğer gerçekten bu düzeydeki bakımın Profesyonellik'in talep ettiğinden daha az olmadığı bir alanda bir şeyler yazıyorsanız, “hızınızın”, “verimlilik” inizin, net olarak ne kadar iyi ölçülebildiğini fark etmelisiniz ( veya zarar) şirketinize, müşterilerinize ve inşa ettiğiniz veya bakımını yaptığınız yazılım grubuna veya ürün ailesine yapıyorsunuz.

Hatırla:

• Yaklaşımınızdaki değişiklikleri düşündüğünüzde, toplam bakım maliyetini, toplam sahip olma maliyetini ve toplam dağıtım ve bakım maliyetini dahil edin. Daha hızlı gitmek ve daha fazla hata yapmak işleri daha iyi hale getirebilir veya etmeyebilir.

• İyi bir şirkette çalışıyorsanız, muhtemelen bir Kariyer Sınırlama Hareketi olmadan kendi ekibinizde ve kendi amirinizle tartışabilirsiniz. Eğer yapamazsan, şimdi bunu bulmak ve yeni bir iş bulmak için iyi bir zaman.

Görebildiğim tek şey: "Sen gittikçe daha değerli hale geliyorsun".

Daha fazla tecrübe kazanırken ve kaçınmanız gereken şeyleri öğrenirsiniz ve bu sizi diğerlerinden daha iyi yapan şeydir.

Kodunuzun şu anda daha güvenli ve daha bakımlı olacağını fark edebileceğiniz bir şey.

• Yapmanız gereken tek şey müşterinize neden zaman harcadığını ve onlar için nasıl yararlı olacağını açıklamaktır.
• Onlara bilginizin derinliğini göstermelisiniz.
• Onlara neden yaptığını, ne yaptığını ve onların ve işlerinin nasıl önemli olacağını anlatman gerek.

Benim önerim, bu bölüme konsantre olmak olacaktır.

Şüphe durumunda, Knuth'u kötü bir şekilde alıntılamak ...

"Erken optimizasyon tüm kötülüklerin köküdür."

İşte size önereceğim şey, sanırım zaman zaman sahip olduğum bir probleminiz var gibi ...

Gerçekten benim için çalışan şey ...

1. Ünite testlerini, tüm kodlar yapılmış gibi yazın.
   
2. arayüzü belgeleyin.
   
3. arayüzü uygular.

gerçekte ne yaptın:

1. Model katmanları gereksinimlerini araştırmak
2. gerçekten, hangi nesnelerin neye karşı sorumlu olduğunu, iş bölümü oluşturdu.
3. Aslında, iş kodunu gerçekten adım adım atabileceğiniz bir ortamda çalışmaya başlayabilirsiniz, bu da işleri çok daha hızlı ve doğru yapar ...

Ayrıca erken gelişimdeki iddialara da güvenebilirsiniz ... sonra hangi ilaçların uygulanması gerektiğini ve ulaşılamayan veya test edilmesi zor bir kod yazamayacağınızı anlayın.

Kodlama standartlarınıza bağlı kalmanız gerektiğini düşünüyorum ancak müşterilerinizle ilgili her şeyden önce emin olun. Birçok müşteri, iyi bir yazılım oluşturmanın ne kadar / masraflı olduğunu bilmiyor. Onları eğitmek profesyonel geliştiricinin işinin bir parçasıdır.

İster çevik olun, ister şelalenin olsun, müşteriden, uygulamanın ne yapmasını bekledikleriyle ilgili bir tür anlaşma olsun. Çok fazla geliştirici (tamam belki daha fazla satış elemanı) kum torbası yapmaktan suçludur . "Çok güvenli bir web sitesi istediklerini söylemediler." Çoğu durumda, sorulmadıkları için. "E-ticaret siteniz saldırıya uğraırsa sorun olur mu?" Elbette umursarlar ve neden birisinin güvenlikten geçmesine izin verecek şekilde inşa ettiniz? Onları eğitmek zorundasın.

Sadece müşterinin yapması için para ödediği şeyi yaptığından emin ol. Hizmetinizin bir parçası da sizin deneyiminizdir. Müşteriler, sormalarına gerek kalmadan tuzakları bilmenizi bekliyor. Gerekliliği dahil etmek onlara kalmıştır. Ucuz bir şey isteyen müşterileri geçmek isteyebilirsiniz.

Bir hatanın pratik sonuçlarını, çözülmesi gereken diğer tüm problemlere kıyasla düşünün.

Kötü yazılmış bir kod parçası oluşturmanın aşağıdaki sonuçlarını göz önünde bulundurun:

1. Veritabanının tamamı her ay atılıyor. Yedeklemeler geri yüklenirken 48 saatlik hizmet dışı kalma süresi.
2. Müşteri kayıtları birbirine bağlanır. Ayda 200 $ değerinde sipariş yanlış müşterilere gönderilir.
3. Bir emir haftada bir kez yanlış durumda kalıyor. Gemilere sipariş verin ancak depoya her seferinde yardım masasını çağırması gerekir.
4. İki hafta kadar bir süre sonra, uygulama çöker ve kullanıcının 2 dakikalık veriyi tekrar girmesi gerekir.
5. Ayda bir kez, uygulama başlangıçta kilitleniyor. Kullanıcı süreci öldürmek ve baştan başlamak zorundadır.

İlki açıkça kabul edilemez. # 2 - # 5 işin niteliğine bağlı olarak olabilir veya olmayabilir. # 2 - # 5, işletmenin karşılaştığı diğer problemler bağlamında değerlendirilmeli.

İdeal olarak, # 2 - # 5 asla, asla olmazdı. Gerçek hayatta, çelişkili öncelikleri olan, maaş çekinizi imzalayan insanlar, hiçbir zaman bir sorunu olmayan mükemmel bir kod yazmak yerine başka şeyler üzerinde çalışmanızı isteyebilir. # 5 başka bir programda daha ciddi bir hatayı tamir etmeme pahasına giderilirse etkilenmeyeceklerdir.

Çözüm, projeler arasında yeniden kullanabileceğiniz sık kullanılan işlevlere sahip bir kitaplık koleksiyonu oluşturmaktır. Örneğin, kodlama, şifreleme, şifre çözme, düzenli ifade değerlendirme vb. Gibi şeyleri yapan bir StringFunctions.dll .NET kütüphanesine sahibim. Bu şekilde, sürekli değişmeyen şeyleri tekrar yazmaya gerek yok.

Dosya oluşturma görevleri için bir sarmalayıcı olması da çok mantıklı. Kütüphaneniz, tüm kontrolleri sizin için yapan ve boş ya da bir dosya (ya da yararlı bulduğunuz şeyleri) veren GetFile () yöntemini gösterebilir.

Hangi proje için ne kadar yapılması gerektiğine karar vermeyi öğrenmeniz gerektiğini düşünüyorum. Bazı projeler önemsiz olabilir ve gerçekten bu kadarını mükemmelleştirmek için harcamak zorunda değilsiniz. Her şey sağlam bir şifrelemeye ihtiyaç duymayacak, her şey milyonlarca kullanıcıya ölçeklenmeyecek.

Bir milyondan fazla kullanıcı için iyi ölçeklendirilebilecek bir program yazmak, şimdi sahip olduğunuz zaman ve deneyim alacaktır, ancak uygulamanızın maksimum 1000 kullanıcı tarafından kullanılmayacağını biliyorsanız, tüm harcamaların bir anlamı yoktur. mükemmelleştiren o zaman.

Bunun programlama kariyerinizde önemli bir aşama olduğunu düşünüyorum ve şimdi programlama ile değil olgunluk ile ilgili bir sonraki seviyeye geçmeniz gerekiyor. Herhangi bir proje için ne kadar zaman ve kodun yeterli olacağına doğru bir şekilde karar verebilmeniz gerekir.

Ve her şey gibi, pratikte de bunu elde edebilirsiniz. Bu nedenle, bir projeye başlamadan önce, bir süre önce üzerinde çalışmış olsanız bile, deneyimlerinizle bunu geçeceksiniz. Başlangıçta birkaç vuruş olabilir ve özlüyor olabilir, ancak zamanla bunu mükemmelleştireceksiniz (karar verme, kodlama değil).

@Zilk, ben iyi bir programcı değilim ve 1998'den beri programlama yapıyorum. Şimdi bile bu sorunla karşı karşıyayım. Ama farkettim ki sonuçta kalite sorunları. Bugün ölürsem, birileri şimdi yaptığım şeyi kaldığım yerden almalı. Böyle bir programlama standartları olmalıdır (Evrensel).

Şimdi kendimi geliştiriciden mimar'a taşıdım. Yönetime geçmek çizgiyi değiştiriyor. Tutkunuza devam etmek istiyorsanız, Mimar olmak için hareket edebilirsiniz.

Başlangıçta Teknik Mimar -> Çözüm Mimarı -> Kurumsal Mimar -> Baş Mimar vb.

Bir mimar olarak, insanları başarıya yönlendireceksiniz. Sizin gibi onlarca yıldır programlama yapan insanlar, o yılların deneyimini başkalarına rehberlik etmek için kullanabilirler.

Daha yüksek bir kuş gibi görebildiği daha fazla karaya uçar, böylece deneyiminiz de odur.

Ayrıca doğru uygulamayı programlamanın, yanlış bir uygulamayı daha hızlı programlamaktan daha önemli olduğunu söyleyeyim. Son zamanlarda gençlerimden biri yanlış bir program yaptı ve bir bankaya çok pahalıya mal oldu. Elbette zamanında teslim etmiştik ama bu işe yaramadı! Aynı küçük kızın bu sorunun olmayacağını kodlamasına rağmen rehberlik etmem istendi mi? Bu örneği, iyi rehberlik sağlamanın da önemli olduğunu vurgulamak için veriyorum. Bazıları bu işi danışmanlık olarak adlandırıyor.

Başka bir seçenek ise: kod yazmayı durdurmak, bunun yerine sorunları önceden tespit etme konusundaki uzmanlığınızı satmak.

Başka bir deyişle, bir danışman olun .

Birçok kuruluş, sorunları ayıklayan kodu oluşturmak için aylarını harcamadan önce birisinin sorunları tespit etmesi için pahalı dolarlar (üst dolar olmasa da) ödemekten memnuniyet duyar . Tasarımda bir hatayı tamir etmenin, kodlandıktan, test edildikten ve yerleştirildikten sonra tamir etmekten daha ucuz / daha kolay olduğu bilinmektedir.

Çok fazla kod yazmayacaksınız ve büyük olasılıkla bunu kaçırmış olabilirsiniz, ancak o zaman gerçek kod satırları sizin temel gücünüz değildir, ancak hangi kod satırlarının yazılması gerektiğini ( hangilerinin yazmaması gerektiğini) bilmeniz gerekir.

Güçlü yönlerine odaklan.
(iyi, eğer zevk aldığın buysa ...)

Sana en iyi tavsiyem: yapı taşları.

Her zaman güvenebileceğiniz bir dosya yapı taşı yapın, API'niz için bir tane yapın, zaman zaman aynı şeyi tekrar tekrar yazmayı bırakın. Her problemi bir kez düşünün ve bir kez ve herkes için düzeltin.

Kimse buna yetmeyecek, kesinlikle zamanlarının% 80'ini, anlamadıkları köşe davaları için başarısız olan kod hata ayıklama koduyla harcayan acemi değil.

Hepsinden önemlisi, yanlış izinler gibi, gerçekleşemeyecek sorunları çözmeyin.

Eğer izinler yanlışsa, zaten bir şeyler yanlış demektir ve programınızı kurşun geçirmez yapmak yerine düzeltmelisiniz.

Bir noktada, yapıp yapmadığınızı her zaman kontrol etmek yerine kendinizi ayağından vurmamanız gerekir.

Belgelendirme için zaman harcamak yerine, kodunuzu kendiniz belgelendirmek ve mümkün olduğunca kısa yapmak için zaman ayırın. Tüm bu yinelenen ish işlevlerini değiştirin. Kütüphanenizi küçültün, şeyleri kesin olarak yeniden adlandırın.

Kendine fazla karşı gelme. Her zamankinden daha fazla insan zekası, bilgi ve deneyim gerektiren, artan karmaşıklık mesleğinde çalışıyorsunuz.

Bilgisayar işlem gücü yavaşlıyor - belki de yakında duruyor - çok çekirdekli yongalar, gpu ile çalışan nümerikler, paralellik, vb.

Bu nedenle, günümüzde ve gelecekte büyük gelişmeler programcılardan gelecek - ileri algoritmalar ve daha verimli kod.

GTA 4 ve GTA 5'e bakarsanız, farklılıklar şaşırtıcıdır. Fakat ikisi de aynı donanım üzerinde çalışıyor. Bu, 10 yıl önce gerekmeyen veya ulaşılabilen çok zeki ve gelişmiş bir programlama uygulamasının sonucudur.

Bu, deneyimli programcıların gelecekte daha değerli olabileceği anlamına gelebilir - tıpkı en yüksek kazançların genellikle kariyerde geç kaldığı mühendislik gibi diğer meslekler gibi.

Tıpkı sizin gibi, 14 yaşında, ilk bilgisayarımı aldığımda da programlamaya başladım (bu noktada birkaç aydır okudum). Ancak, ben şimdi "sadece" 33. :-)

Benim önerim, bir şey geliştirirken, bu kaygıların her birini (dosya izinleri, bir dizindeki dosya sayısı vb.) Alırsınız ve ardından bu konuda birkaç soruyu yanıtlamak için engin deneyiminizi kullanırsınız:

• Bu konunun kodunuzda doğru bir şekilde ele alınması ne kadar sürer?
• Düzgün idare edemiyorsanız, bu şeyin sizi daha sonra ısırması ne kadar olası?
• Seni ısırırsa, sonuçları nelerdir?

Bu cevaplarla donanmış, böyle tecrübeli bir adam akıllıca bir karar vermekte zorlanmayacak. ;-)

Bu tür bir şartı yerine getirmek gibi sizin gibi “gazilerin” sorumluluğudur ve bu hem neyin yanlış gidebileceğini belirlemek ve hangi potansiyel sorunlara dikkat etmeniz gerektiğine karar vermeyi içerir.

Uygulama geliştirirken olası tüm kriterleri bilmek, kaliteli bir ürün geliştirmede en önemli şeydir. Bu işte iyisin. Yapabileceğiniz şeylerden biri, gereksinimi kalite seviyesine göre sınıflandırabilir ve daha sonra belirtilen son tarihle seviyeyi haritalandırabilirsiniz. Bu sayede sizlerle projenin son tarihini kolaylaştırabilirsiniz.

Edsger Dijsktra'nın sözleriyle: “Eğer hata ayıklama, yazılım hatalarını kaldırma işlemi ise, programlama onları yerleştirme süreci olmalıdır.” Bunlardan sadece daha azını yapıyorsunuz, bu nedenle daha azını yapmanız gerekiyor. Bu sadece doğru kodlama için zaman harcamayı öğrenme meselesi. Hala nispeten genç bir programcıyım (20ish'i okudum) ve bir şeyi tamamen doğru bir şekilde kodlayabilmeyi arzu ediyorum. Bir saatlik planlama ve 10 dakikalık kodlama, 10 dakikalık planlama, bir saatlik kodlama ve üç hata ayıklama işleminden çok daha iyidir.