Patronumdan (kibar bir şekilde) kodunu yorumlamasını nasıl isteyebilirim?

Patronum tarafından öğretiliyorum (okulu yeni bitirdim ve biraz programlama tecrübesi olan birini istiyordu, bu yüzden beni bu şirketin uzmanlığı konusunda eğitmeyi seçti) ve ASP.NET MVC uygulamaları, bazı HTML ve CSS ile çalışmaya başladı. . Bana verdiği web tasarımı konusunda iyiyim (açıklama olmadan anlaşılması oldukça kolaydır).

Ancak örneğin bana ASP.NET MVC ile ilgili bir görev verdi, bunu gerçekten iyi açıklıyor. Ama az önce bana verdiği kodda hiçbir şey açıklamıyor. ( Visual Studio 2013'te kaynak kontrolü kullanıyoruz ), bu yüzden ne yapması gerektiğine dair bir arka plan olmadan tam anlamıyla yüzlerce satır kod satırı var. Gördüğüm kod türü daha önce hiç görmediğim kod, bu yüzden denemek ve çözmek gerçekten zor.

Ona daha fazla soru sormaya çalışırdım, ama her zaman çalışıyor (kendi işi) ve elimde olan tüm bu sorulardan rahatsız olmuş gibi hissediyorum.

Bu yüzden, bir şeyleri kavrayana kadar bana yardım edecek bir şey var, patronumdan bana verdiği koduna yorum yapmasını nasıl isteyebilirim, ama kibarca?

Sen 'derin sondasın' ve bence öğrenmenin en iyi yolu bu. Asıl ipucunun olmadığı şeylere baktığın için değil, ama seni daha becerikli olmaya zorladığın ve hangi bileşenlerin yeni bir sistemde hangi rolü oynadığını bulduğu için.

Patronunuzun meraklı biriyle başa çıkmak için çok meşgul olmamasına yardımcı olmuyor (ve meraklı olmak için tamamen haklarınız arasındasınız; öğrenmeye heveslisiniz, ki bu iyi). Ancak, ne yazık ki, kıdemli öğreniminiz için kendi stilini ve yaklaşımını değiştirmesini istemek, özellikle de meşgul olduğunuzu söylediğiniz birisiyle uğraştığınızdan, çok iyi düşmeyebilir.

Aşina olmadığınız binlerce kod satırının önünde oturmak normdur. Yorumlarla her zaman siyah ve beyaz olarak açıklayamazsınız. Ancak yeni iken öğrenme adına, ondan kesinlikle yorum istemesi gerektiğini düşünüyorsanız - belki de nedenini açıklayın. Açıkla, sık sık meşgul olduğu için onu sorularla rahatsız etmek istemediğin için. Bu sadece ona bir şeyler yapmasını söylediğiniz gibi daha az rastlanmayacak, aynı zamanda soruyu sorma zamanını bir kenara bırakmayı nasıl tercih edeceği konusundaki tartışmalara zemin açıyor.

Birincisi, binlerce tanıdık kod satırını taramak ve kaybolmuş hissetmek, her yazılım projesinin, her yerde, zamanın başlangıcından itibaren olmasıdır.

Siz ve deneyimli bir programcı arasındaki en büyük fark, buna alışık olmadığınızdır.

Akılda tutulması gereken birkaç nokta:

1. Yeterince çabayla, her kod biti anlaşılabilir. Birkaç dakika içinde bir şeyleri çözemedikleri takdirde birçok insan kendini sinirli hissediyor. Bundan daha sabırlı ol.

2. İyi bir patron, kesintilere ve sorulara mümkün olduğunca açıktır. İyi bir çalışan, kesintileri ve soruları en aza indirgemek için elinden geleni yapıyor. Bunun bilincinde olun.

3. Kesintiler sorulardan daha maliyetlidir. Tartışmalarınızı birleştirerek ve kafanızın karıştığını hissetmeyerek, zamanınızı ve patronunuzun zamanını daha iyi kullanabilirsiniz.

4. Patronun senden daha iyi bir programcı. (Muhtemelen.) Bu, bazı alanlarda daha güçlü olamayacağınız anlamına gelmez, fakat genel olarak uzmanlığı daha fazladır. Çok fazla deneyime sahip olana kadar, onun uzmanlığından mümkün olduğunca çok şey öğrendiğinizden emin olun.

5. Daha fazla yorum koduna önemli ölçüde yardımcı olacağından eminseniz, patronunuza sorun. “Bazı yerlerde neler olup bittiğini anlamak benim için zor. Bir şeyleri çözdüğümde, yorum eklersem sorun olur mu?” Belki de yorumlardan nefret eder. Belki onu sevecektir. Belki kayıtsız kalır.

Ancak sonuçta, birkaç ay sonra bunu sormayı hatırlamanız ve "Huh, neyle bir sorunum olduğunu merak ediyorum? Bu o kadar da kötü değil. Hm, peki, önemli değil."

Patronunuzun tüm sorunuzu yanıtlamak için vakti yoksa, neden eski kodunu yorumlamak için vakti olacağını düşünüyorsunuz? Dahası, yorumlarının şu an için anlamadığınız parça ve parçaları gerçekten tarif edeceğini düşündüren nedir? Tecrübelerime göre, patronlarınızın programlama tarzını sadece ona sorarak değiştirmeye çalışmak, kibar olmayacak ya da çalışmayacak.

Böyle bir durumda yapabileceğiniz en iyi şey: İşinizi kendiniz yapmak için anlamanız gereken kodun bölümlerini yorumlayın. - bir zamanlar bu kısımları anladığınızda, elbette ve patronunuzdan bunun iyi olacağını taahhüt ettikten sonra. Siz veya patronunuz yorum ekleyerek bir şeyi kırabileceğinizden korkuyorsa, bunları ayrı bir şubeye ekleyin ve patronunuza, yorumlarınızı bagajla birleştirilmeden önce incelemesi için zaman ayırıp harcayamayacağını sorun. Patronunuz yalnızca sınırlı bir zaman bütçesine sahip olduğundan, belirli bir parçanın ilk önce ne yapabileceğini makul bir zamana yatırım yaparak bulmaya çalışın. Sıkışırsanız, sorunuzu bir listeye yazın ve patronunuza, örneğin 30 dakika rahatsız etmek yerine günde bir kez sorun. Tecrübelerime göre, bu yaklaşım çoğu insanla, çok meşgul olsalar bile, size yardım etmeye istekli oldukları sürece çalışır - ki bu sizin durumunuzda kesinlikle böyledir.

Bu sayede, ihtiyacınız olan yorumları aldığınızdan eminsiniz ve patronunuz ek bilgiye ihtiyaç duyduğunuz ve doğru şeyler bulduğunuzda bunu görecektir. Ve yalnızca açık olmayan şeyleri yorumlamanız için kısıtladığınız sürece, yorumlarınızın kod tabanının genel kalitesini artırma olasılığı yüksektir, bu yalnızca sizin için değil, aynı zamanda diğer herkes için de fayda sağlayabilir. Patronun da dahil olmak üzere, kodu ele almalı.

Öncelikle, bunun kodunuzu doğru şekilde yorumlayabilmesi için bir örnek olmasına izin verin, çekirge!

O zaman bunu her zaman yapmak zorundayım. Yerel kopyamı kontrol ettirdim, ve üzerinden gidip kendim yorum yapıyorum. (Tekrar kontrol edeceksem tekrar çıkartabilirim - ya da kimse aklını kaçırmazsa, onları bırakabilirim.) O zaman gerçekten daha fazla göremediğimde, birine sorabilirim, burada, sanırım öyle bu (yorumladım), haklı mıyım? Öyleyse asıl yorumu yapmış olabilirsiniz, ama bu yapıldı ve mesele bu.

Bu kişisel bir istekten daha fazlasıdır. Alışkanlıkları / kültürleri değiştirmeye çalışıyorsunuz ve bu kolay değil. Bu kesinlikle bir koridor konuşması veya bir e-posta ile gerçekleştirilebilecek bir şey değil. Senin için biraz çaba sarf edecek.

Dünyada görmek istediğiniz değişim siz olun.

Alıntı sahte bir şekilde Mahatma Gandhi'ye atfedilebilir, ancak uygulanabilir bir tavsiye. Kod tabanını bulmaya çalışırken, görmek istediğiniz yorumları, elinizden gelen en iyi şekilde yazın ve patronunuz tarafından incelendikten sonra bunları yapın. Avantajları:

• Dırdır etmekten çok proaktif oluyorsun.
• İyi bir örnek oluşturuyorsun. En iyi durumda, patronunuz / ekibiniz faydaları görecek ve davayı takip edecektir.
• Yorumların bazıları muhtemelen söyleyecektir /* Mystery parameter 3 */veya /* 2015-02-09 AidanQuinn: Is this code ever called? */- bunlar meslektaşlarınızın ya kodu doğru bir şekilde belgelemesi ya da gizli hataları düzeltmesidir.
• Ön inceleme incelemesi sırasında, yazdığınız bir yorumun yanlış olduğu tespit edilirse, iş arkadaşlarınız şimdi kodun belirsiz olduğunu bilir.

Bunu yaparken herhangi bir yeniden yazma veya yeniden düzenleme işleminden kaçının ve yorumların tanıtılması neredeyse risksiz olmalıdır. Herhangi bir şeyi yeniden yazarsanız, bu değişiklikleri ayrı taahhütler olarak saklayın.

(Bu projeye başlamadan önce, yorumlar için beklentilerinizin makul olduğundan emin olun. İyi yorumlanmış kod fikriniz normların dışındaysa ( Örnek 1 , Örnek 2 ), yalnızca bir aptallık yapacaksınız. kendin.)

Ek yorumlar istemeyeceğim ama işte sizin için bazı fikirler:

1. Patronunuzla oturmaya çalışın ve kodu yüksek bir seviyede geçirmesini sağlayın. Bu senin başlamanı sağlamalı. Hızını arttırmak için birkaç saat belki yarım gün beklerdim. Bu genel tasarım, kullanılan kalıpları vs. içermelidir.
2. Bir test projesi oluşturun ve koda karşı birim testleri yazmaya başlayın, bu onu etkilemeden anlamanıza yardımcı olacaktır. Ayrıca bazı hatalar da bulabilirsiniz!
3. Belirli alanları anlamak için gereken şekilde hata ayıklayın.
4. Bir donanım geliştirin veya biriktirmeyin ve üzerinde çalışın.

Yorumlar tamam, ancak kod basit bir şekilde yazılırsa, birkaç gün sonra anlaşılabilir olması gerekir.

Ayrıca hepsini anlamayı beklemeyin, önce kilit alanlara odaklanmak ve ardından kod tabanı bilgisini gerektiği gibi genişletmek daha iyidir.

Bir yıl önce kabaca sizinkine çok benzer bir durumdayım. Çok az programlama tecrübesiyle çalışmaya başladım (biraz OO ve başlayacak diğer dilleri bilmeme rağmen) ve bana öğreten bir kişinin çok az zamanı vardı. Her zaman yardımcı oldu, ama sahip olduğum her soruyu sormak istemeyeceğimi hissettim.

Diğerleri burada zaten çok yararlı şeyler önerdiler (örneğin, birim testleri yazmak, ancak kendi tecrübelerime dayanarak, bu benim için sıfırdan 'biraz ileride olacak bir şey) veya kodun bölümlerini kendiniz yorumluyor olabilir. ilk noktaya / soruya bağlı olarak zor olacağım bir dakika içinde size soracağım). Aşağıdaki noktalar ne yaptığımı ve bana neyin yardımcı olduğunu özetliyor, ancak sorunlarınızın tam olarak nerede bulunduğuna bağlı.

Ayrıca, C # ile ilgili yorumlara gerçekten ihtiyacınız olmadığını söyleyen @AK_ ile aynı fikirdeyim. Bu% 100 doğru olmayabilir (yorumların kesinlikle yardımcı olduğu alanlar var, mesela Yansıma-ağır kodlar) ama özünde öyle. Gerçekten iyi adlandırılmış yöntem ve değişkenlerle 'temiz kod' yazarsanız ve çok sayıda küçük 'ısırık' kod kodunuz varsa, neredeyse tamamen gereksiz olacaktır. Her zaman kod okurken yorum yapmaya ihtiyacım olduğunu hissettim, sonra ne yaptığını anladıktan sonra, nasıl yapıldığına çok memnun değildim ve ilk başta iyi refactoring ile daha net olabileceğini düşündüm. Düzenleme: Belgelendirme her zaman önemli olduğunu düşündüğümden, özellikle burada C # yorumlarından bahsediyorum , belgelerden değil (ayrı belgeler veya XML yorumlarından ayrı).

• Sorunlarınızın tam olarak ne olduğunu ve bunları kategorize edip edemediğinizi belirleyin. Yani, hala dilin kendisiyle ilgili sorunlarınız mı var veya belirli bir sözdizimini anlamadınız mı (örneğin, lambda ifadeleri ve genel olarak LINQ veya Yansıma)? Kod satırlarını anlamıyorsanız, tüm yöntemin / bloğun ne yaptığını anlamayacaksınız, bu nedenle kendinize yorum yapmak zor olacaktır. Aksine, iyi bir kitap edin ('Özetle' C # 'benim içindi, ama' Derinlikteki C # 'nın da muhteşem olduğunu duydum) ve karşılaştığınız şeyleri okuyun. Bu sorunları önceden kategorize etmek, daha büyük soruları bir kerede doldurabileceğiniz, hatta artık çok fazla soru olmadığı gibi, patronunuza da sorabileceğiniz, böylece tek bir konuyu veya en sık kullanılan yapıları açıkladığınızdan bunu kolaylaştırır. büyük bir 'boost' alabilir

• Yukarıdakilere paralel olarak kendimi 'temiz kodlama' ve en iyi genel uygulamalar (dile özgü değil) ile tanıştırmaya çalıştım. Bunun etkisi hemen olmayabilir, ancak mevcut şeyleri genişletmek zorunda kaldığınızda veya birisinin neden her şeyin bulunduğu bir yerine neden bu kadar küçük yöntemler yarattığını merak ettiğinizde, er ya da geç ödeyecek ;-)

• Ortak tasarım desenlerini anlayın. Burada ve orada okuduğunuz kodda görünebilirler ve eğer onları tanırsanız hemen size bir-ha anı verir. Gördüğünüz kodun ne yaptığını anlamış olsanız bile, neden bu şekilde yapıldığını merak etmenize neden olabilir ve bunu kendi başınıza çözmek çoğu zaman kolay değildir.

Lütfen yukarıdaki metni “beceriniz” hakkında varsayımlarda bulunduğum gibi almayın, genellikle deneyimlerim hakkında konuşmak ve “sizinle” konuşmak arasında yanlışlıkla geçiş yapıyorum. Çoğunlukla karşılaştığım ve yaptığım şeydi . Diğerlerinin de söylediği gibi, bu çok iyi bir deneyim olabilir ve işinizde kendinize ait olmayan ve önceden hakkında fazla bir şey bilmediğiniz kodları okumak oldukça standart. Fakat orada neler olup bittiğini kavramak ve kendinizi bu özel 'beceri'de daha iyi olduğunuzu fark etmek gerçekten tatmin edici olabilir. Bunu çok kısa sürede çok şey öğrenme fırsatı olarak alın , iyi şanslar! :)

Muhtemelen onun tarzını değiştirmesini istemeyeceksin.

Yapabileceğiniz şey birçok soru sormak ve cevapları yazmak.

Son işimde çok büyük bir kod temeli, küçük belgeler ve az yorum aldım. Bu yüzden aynı problem için yarım saat çalışacağım, o zaman hala çözemezsem, ya yazan ya da nasıl kullanacağını bilen birine sorardım. Sonra bana söylediği her şeyi belgeleyecektim. Çoğu dokümantasyonumuza girdi, bazıları yorum olarak kodlara girdi. Bir yıl sonra neredeyse belgelerimizin büyük bir bölümünü yazdım ve kod temeli hakkında çok şey biliyordum.

İyi şanslar!

Ben de aynı problemi yaşıyordum. Ben fizist öğrenciyim ve iyi bir programlama deneyimim var. Birçok dilde programlama yapıyordum ama premium uygulamalar için hiçbir şeyim yok.

Web geliştiricisi için bir iş başvurusunda bulundum ve hemen beni web programlamanın arka tarafına yerleştirdiler. Patron bana REST düğümü için temel api gösterdiğinde, dışarı fırlayacağımı düşünüyordum. Geri arama ve çok garip sözdizimi ile işlevleri hiç görmedim. Ve patronuma soruyorum, sorunum var Kodda hiçbir şey anlamadım. Hüzünlü hayır, bunu çözmek için 1 ayım olduğu için üzgünüm ve bu arada beni başka bir önderle test etmek için bir CMS yapacağım.

Ben de o zaman 1 satır kod kullandım ve bilmediğim her şeyi google'da bıraktım. Bu yüzden 1 hafta geçti ve ön uçla biraz işbirliği yapabildiğim için yeterince kod kullandım. Başlangıçtaki kodum berbattı ama 3 ay sonra beni selamladı! Yazılım mimarımızdan daha iyi ve daha hızlı kodlama yapıyorum!

Asla öğrenmeyi bırakmadığına inanıyorum! Moto'm -> Öğrenmeye devam et ve sakin ol :) Patrona bağımlı olma, bağımsız ol ve doğrudan sor, ama sadece en zor sorunları. Çünkü kendi araştırmanla bulduktan sonra mutlu olacaksın. Ve yanlış bir şey öğrenmeyi bıraktığınızı hatırlayın, ewery gününü nasıl iyi bir programcı olunacağını öğrenin.

Patrondan öğrenecekseniz, kendi standartlarınızı belirlemekten daha iyi olmayacak, IDE, Linux wmii'niz için kör yazma, VIM veya VIM eklentisini öğrenin, böylece bir gün patronun ötesine geçersiniz ve ondan daha iyi olursunuz!

20 yıllık bir yazılım mühendisi olarak, çoğunlukla güvenlikle ilgili konularda (SF-PD) çalışıyor, patronunuzun sizin örneğiniz olmak istediğiniz kişi olamayacağını söylemek zorundayım. Yorumların olmaması, işi düzgün bir şekilde yapmayı asla öğrenemeyen, kendi kendine öğretilen amatör bir kodlayıcı ya da deneyimsiz bir mühendisin bir işaretidir. Ya da belki de sadece zamanı olmayan bir mühendis - son tarihler ve uygunluk kodunuza korkunç şeyler yapabilir! ;) Kesinlikle her yetkili yazılım mühendisi için kesinlikle bir anti-patern.

Patronun çok iyi bir kodlayıcı olabilir, ama iyi bir yazılım mühendisi değil gibi görünüyor. Bir mühendis, diğer insanların zaten yakaladıkları tuzaklardan kaçınmak için toplu grup deneyimini kullanır. Etkili yorumlama, yazılım için bu toplu grup deneyiminin bir parçasıdır, stres analizi ile aynı şekilde makine mühendisliği için de ortak grup deneyiminin bir parçasıdır. Etkili yorumlama olarak sayılan şey daha akışkandır ve kesinlikle deneyimden edindiğiniz bir şeydir.

En temel şey, yorumların bir kod satırının ne yaptığını söylememesi gerektiğidir. Bir fonksiyonun ne yaptığını söyleyen yorumların (özellikle C #) gereksiz olduğu zamanlar vardır. Aşırı yorum yapmak da etkisiz olabilir (ve deneyim eksikliğinin bir göstergesidir) çünkü cürufta önemli maddeleri bulamazsınız. Bir acemi olarak, hala kodun "ne" olduğunu bulmak için çalışıyor olabilirsiniz ve bunun için sadece ne yaptığını okumanız ve anlamanız gerekiyor.

Ancak yorumlar için önemli olan şey, NEDEN bir kod satırı veya fonksiyonun yaptığı şeyi yaptığını, bunun açık olmadığı durumlarda söylemesidir . Y modülünden önce X modülünü kurmanız mı gerekiyor? Bir dosyanın zaten açık olup olmadığını görmek için bir dönüş kodunu kontrol etmek önemli mi, yoksa bu başka bir yerde kontrol edildiğinden, dönüş kodunu bilinçli olarak görmezden mi geliyoruz? Kodun "nedeni", deneyime bakılmaksızın herkesle alakalı olacaktır - ve belirli bir şeyi yapmanın iyi bir nedenini unuttuğu zaman 6 ay içinde de onunla ilgili olacaktır. Yorum yapmak sadece diğer insanlar için değil, gelecekte de size yardımcı olmak içindir.

Patronunuzu sinirlendirmekten kaçınmak istiyorsanız, akıllı sorular sorun. “Neden” hakkında soru sormaya odaklanın ve “ne” yu kendiniz bulmaya çalışın (gerçekten belirsiz olmadığı sürece). Hiçbir iyi patron, R-ing TFM'den bulabileceğiniz türden şeyler değilse, sorular sorulmasının sakıncası olmaz. Ve iyi bir mühendis, başka bir mühendisin hayatını önemli ölçüde kolaylaştıracak bir şey yapmamın istendiğini aldırmayacaktır, onlara düşük maliyetle. (Sadece tüm kod temeli hakkındaki yorumları doldurmasını istemeyin!;)

Ben de benzer durumdaydım diyorum

1. Patronunuz bir nedenden dolayı kirli yolu öğrenmenizi isteyebilir (hiçbir ipucu olmayan kodu kullanarak). Bu, işte bir ayda kolejde bir yıldan fazla öğrenmenin yoludur.

2. Bu, diğer cevaplarda belirtildiği gibi "norm" dur. Nereden başlayacağınız, nasıl yaklaşacağınız ve neye odaklanacağınız konusunda daha fazla endişelenmelisiniz. Patronunuza doğru araçları ve kodda hata ayıklama / adım atma yollarını sorun. Bu tür sorular size bazı puanlar kazandıracak.

3. Düzenli olarak, patronunuza nasıl yaptığınızla ilgili geri bildirim almak için yaklaşmaya devam edin; böylece patronunuzun aynı durumda çok sayıda insanı gördüğünü ve nasıl yaptıkları hakkında bir fikir edindiğini varsayarak yüzdelik şartlarda nerede durduğunuz konusunda bir fikir edinebilirsiniz.

4. Bunu bir fırsat olarak kabul edin ve kodu anlamakta daha iyi hale geldikçe, patronunuza sormayı umduğunuz yorumları eklemeye devam edin.

Gerçekten de koduna yorum yazmasını istemeyi denemek istiyorsanız (tavsiye etmiyorum) Gerçekten bazı yorumları kullanabilecek (çoğu kendi kendini açıklayıcı olan) düzenlemesi gereken bir kod bulmanızı ve hakkında soru sormanızı öneririm. Bunun gibi, "Buradaki kodlara bakıyordum ve [Sorunu çözdüğünüzü] anlamaya çalışıyorum ve açıklamak için herhangi bir yorum bulamadım" gibi. Temel olarak, onu anlamak için çaba sarf ettiğinizi göstermeye çalışın ve neden ikisinin de orada olmanızdan faydalanabileceğinizi açıklayın.

Muhtemelen iyi yazılmış kodun% 90'ı yorum yapmak zorunda değildir. Kodun yalnızca optimize edilmiş ve oldukça gerilmiş olan kısımlarını belgelemek istiyorsunuz. Bir şirkette çalıştım, temelde değiştirdiğiniz her kod parçasını belgelemenizi gerektiren bir şirkette çalıştım. Bir haftanın bir fonksiyonunu ayıklamak için harcadığım kötü yorumlardan kaçının ve sonunda böyle bir bayrağın "yanlış" olarak ayarlanmasına ilişkin okumaya devam ettiğim yorumun aslında bayrağı "doğru" olarak ayarladığım ve her şey çalıştığını gördüm. olması gerektiği gibi.

Kodda, bir şeylerin neden yazıldığını anlamak için yorumlarınızı istiyorsanız, o zaman büyük olasılıkla (yeni olduğunuzu düşünün) iş gereksinimlerini henüz anlamadınız. Tüm sözdizimini bildiğinizden ve kod okuyabildiğinizden eminim ancak bazı kodların amaçlarını bilmediğiniz sürece biraz kaybolmuş hissedeceksiniz.

Akla gelen bir şey çift programlama. Patronunun gelişiminden etkilendiğini söylüyorsun, böylece onunla birlikte çalışmayı önerebilirsin. Bu, uzun vadede ikinize de yardımcı olacaktır. Patronunuz, kendisine verilen şeyleri açıklamak zorunda kalacağını görecek ve iş hakkında daha fazla şey öğreneceksiniz.

Diğerlerinin de belirttiği gibi, bu oldukça yaygındır, ancak bu sadece onu emmek ve içinden geçmek zorunda olduğunuz anlamına gelmez. Kodu düşündüğünüz kadar derinlemesine anlamanıza gerek yoktur ve "derin sonu" nu daha sığ hale getirmek için somut stratejiler vardır:

• Eldeki görevle ilgili kodda bir şey bulun . Genellikle aranması en kolay kullanıcı GUI üzerindeki düğmenin etiketi gibi görünen bir şeydir. Bulduğun yeri yaz. Bu sizin çapa noktanız olacak.
• Şimdi bir adım ötedeki kodu arayın ve yazın. Düğmeyi kim oluşturur? Düğme tıklatıldığında hangi kod çağrılır?
• Kaynak kontrolü, bir adım ötedeki kodu bulmak için genellikle yararlıdır. Baktığınız kodun ne zaman eklendiğini veya değiştirildiğini öğrenin ve aynı anda başka neler kontrol edildiğine ve neden olduğuna bakın.
• Değişikliğinizi yapacak kadar anlayıncaya kadar bir şey daha kaçırmayacağınızdan emin olmak için bir seviye daha derinlemesine devam edin.
• Herhangi bir noktada takılıyorsanız, şimdi sormanız gereken çok özel bir sorunuz var. Örneğin, "Bu düğmenin neresinden örneklendiğini anlayamıyorum."

İşte konuyla ilgili 0,02 dolar. Özel bir cevap önermiyorum, burada söylenenlerin çoğu oldukça alakalı.

Bir şeyler düzenlemek için biraz sosyal mühendislik denerdim, böylece patronunuz kodunu yorumlamamaktan daha kolay / daha az zaman alıcı bulur.

Şimdi, eğer büyük bir risk almaya ve onu sinirlendirmeye istekliyseniz, bu oldukça kolay olabilir - ama bunu yapmak istemiyoruz. (yan not: Sadece sizlere yorum yazmadan veya dikte etmeden hiçbir şey yapamıyor olabilirsiniz, ısrar edip durmadan durdurabilirsiniz.)

Alternatif nedir o zaman? Duruma bağlı olarak birkaç fikir.

seçenek 1

1. X'in yaptığı gibi, kodunun bir parçasını anlamak için zaman ayırın.
2. Şimdi yanlış anlamak için Y'nin makul bir yolunu düşünün .
3. Patronunuza (e-posta yoluyla veya kahvaltıda veya neyin olmadığını söyleyerek) şu anda anlamaya çalıştığınızı söyleyin.
4. Kodun ne anlama geldiğinin açık olmadığını söyleyen bir yorum ekleyin, ancak Y olarak; bu yorumu onun için görünür kılmaya çalışın - ancak çok fazla çaba harcamayın!
5. Y varsayarak hareket edin - ve patronunuzun eyleminizi fark ettiğinden emin olun (böylece zamanınızı yanlış bir varsayımda uzun süre boşa harcamazsınız).
6. Patron seni düzeltmek için inisiyatif almalı. Bu noktada ona şöyle bir şey söyleyin: "Bu kodun yanlış varsayımı yapmamı engellemek için birkaç yorum yapmasını diliyorum. Kendim için eklediğim yorumu düzelteceğim. Genel bir açıklamada bana yardımcı olabilir misiniz? Bu ve bu kodun parçalarından mı? Tam olarak niyeti bulmak için yeterince tecrübeli değilim ve sadece birkaç cümle yapıyorum. ” Ya da başka birşey..

seçenek 2

Eğitimdesin. Onunla haftalık olarak bir (ek?) Sabit frekans toplantısı düzenlemeye çalışın. Bu toplantıda bazı kodları gözden geçirin - ancak her bir satırı açıklamamaya yetecek kadar hazırlıklı olmanız gerekir. Bir noktada - umarım - yorumlar eklerse toplantıyı atlayabileceğini anlayacaktır.

Seçenek 3

Sizinle aynı kod parçasını anlayamamak için başka bir iş arkadaşınız alın. İkiniz de aynı soruları sorarak farklı zamanlarda patrona yaklaşıyorsunuz. Bir şeyi yapamadığını fark etmesini sağlamanın kesin bir yolu ... ama herkesin aynı projedeki yardımcı iş arkadaşlarının lüksüne sahip olmaması.

Bu yüzden, bir şeyleri kavrayana kadar bana yardım edecek bir şey var, patronumdan bana verdiği koduna yorum yapmasını nasıl isteyebilirim, ama kibarca?

Kodu anlayamıyorsanız, neden yorumların sizin çözümünüz olduğunu düşünüyorsunuz?

Programlama stilini bilmiyorum, ancak fonksiyonların ve değişkenlerin adı yanıltıcı olursa, bir kodu anlamanın çok zor olduğunu itiraf ediyorum. Fakat eğer isimler ve fonksiyonlar veya hatta programın organizasyonu (sınıflar, metotlar, özellikler ...) kodu anlaşılır hale getirecekse, kod aslında sizinle konuşacaktır.

Ondan program mimarisini sorsanız iyi edersiniz ve bir şey talep etmek istiyorsanız, fonksiyonlar için daha anlamlı adlar isteyin; bu onun için daha uygun.

Bunu kibarca sormanın bir yolu olsa bile, patronunuzun kodundaki yorumlar hakkında ne düşüneceği konusunda iki olasılık var:

1. Ya kodundaki bu yorumların olması iyi bir şey olurdu, ya da

2. Onun kodunda bu yorumlar olması iyi bir şey olmazdı.

Patronunuz kodundaki yorumların sahip olmak için iyi bir şey olmayacağını düşünüyorsa (ve bunun için çok iyi argümanlar varsa, yani kodun dokümantasyon olması gerektiği varsayılır ve hiçbir dokümantasyon hiçbir zaman kesin ve net olmayan bir şekilde şart koşmaz) Aslında bunu yapan kod gibi ) o zaman hiçbir şey olmayacak.

Şimdi, eğer patronunuz kodunda yer alan yorumların sahip olmak için iyi bir şey olduğunu düşünüyorsa, size kodunu incelemenizi, nasıl çalıştığını anlamanızı ve kodlarına yorum eklemek için ilerlemesini söyleyebilecek önemli bir şans var. kendini kodla . (Bunun için de çok iyi argümanlar var, yani öğrenmelisin , ve zamanının tanımı seninkinden daha değerli .)

Yani, bunu yapmak için hazırlıklı olmadığınız sürece, hiçbir şey söylememekten daha iyi olabilirsiniz.