Najbardziej niedoceniane narzędzie programistyczne [zamknięte]

35

Mamy wiele świetnych narzędzi, które bardzo pomagają w programowaniu, takich jak dobrzy edytorzy tekstów, IDE, debuggery, systemy kontroli wersji itp. Niektóre z narzędzi są mniej więcej „niezbędnymi” narzędziami do wykonania zadania (np. Kompilatory) .

Nadal zawsze są narzędzia, które bardzo pomagają, ale wciąż nie przyciągają zbyt wiele uwagi, z różnych powodów, na przykład, kiedy zostały wydane, wyprzedzały swój czas i teraz są mniej lub bardziej zapomniane.

Jaki rodzaj programowania narzędzie myślisz jest najbardziej niedoceniane jeden? Motywuj swoją odpowiedź.

tools  developer-tools 
— Anto
źródło
3
Nasze mózgi? - -
— Trufa
Dobra, kto chce dodać wpis Lisp? * grin *
— Mark C

Odpowiedzi:

70

Gumowa kaczka. Tak naprawdę.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Debugowanie gumowej kaczki , gumowa kaczka i test gumowej kaczki to nieformalne terminy stosowane w inżynierii oprogramowania w odniesieniu do metody debugowania kodu. Nazwa nawiązuje do prawdopodobnej apokryficznej historii, w której nienazwany programista przez cały czas trzymał gumową kaczkę przy biurku i debugował swój kod, zmuszając się do wyjaśnienia kaczce wiersz po wierszu.

Aby skorzystać z tego procesu, programista wyjaśnia kod obiektowi nieożywionemu, na przykład gumowej kaczce, oczekując, że po dotarciu do fragmentu niepoprawnego kodu i próbie wyjaśnienia go programista zauważy błąd. Opisując, co powinien zrobić kod, i obserwując, co faktycznie robi, widoczna jest jakakolwiek niezgodność między nimi.

— Andiaz
źródło
6
Robię to cały czas z moim mężem. Jako specjalista ds. Wsparcia technicznego z odrobiną umiejętności programistycznych rozumie około 60% tego, co mówię, ale zmusza mnie do wyjaśnienia 40%, których również nie rozumiem. Liczba przypadków, w których działa, jest naprawdę imponująca.
— Ethel Evans,
1
Śmiejesz się Miałem współpracownika, który miał na biurku gumową kaczkę.
— Berin Loritsch,
57
Próbowałem, ale moja gumowa kaczka nie mogła skupić się na problemie. Gdzie mogę znaleźć odpowiednio wykwalifikowaną gumową kaczkę z prawdziwym zainteresowaniem w programowaniu?
— Steve314,
3
Używam do tego mojego dziennika. Czasami prowadzę ze sobą dość długie dyskusje. Chciałbym czasem sprawić, by zrozumiałem, co mam na myśli. Zapisywanie tego w dzienniku czasami pomaga dużo później, kiedy zastanawiam się, co myślał idiota, który napisał kod, nad którym pracuję.
— Lars Wirzenius
1
@ Steve: Japońscy naukowcy pracują nad tym, ale nie sądzę, aby byli nigdzie blisko: youtube.com/watch?v=3g-yrjh58ms
— Rei Miyasaka
42

Pióro i notatnik.

  1. Działa bez prądu.
  2. Przenośny.
  3. Doodle on / in, gdy nudzi się na spotkaniach
  4. Przechowuj przydatne informacje.
  5. Jeśli jest spisany, ludzie przywiązują do niego większą wagę.
  6. Inni mogą to przeczytać i nauczyć się.
— iskrzący
źródło
W dawnych czasach dużych korporacji inżynierowie i technicy otrzymywali puste notesy inżynierskie, w których zapisywali wszystkie te rzeczy, które zwykle przechowujemy w różnych plikach na naszych dyskach twardych. Gdy notebooki zostaną wypełnione, zostaną wysłane do bezpiecznego i ognioodpornego repozytorium. Jeśli ktokolwiek potrzebowałby mieć dostęp do tych notatek, mógłby sprawdzić zeszyty.
— oosterwal 11.03.11
3
Rosjanie użyli ołówka.
— Job
@ Job Hah, wciąż używam butelki z atramentem! (... Cóż, tylko do kaligrafii, ale nadal. :))
— Mateen Ulhaq
Co z komputerami typu Tablet?
— Mateen Ulhaq
1
@Job:… i wódka!
— Spoike
38

Narzędzia porównywania wydają się być niewykorzystywane podczas porównywania wyników dziennika lub danych w płaskich plikach tekstowych. A może to tylko nisza? Wydaje mi się, że jest to bardzo przydatne i pomocne przy debugowaniu, aby porównać ogromne dzienniki wykonania programu i wskazać jeden lub dwa szczegóły, które uległy zmianie.

Narzędzia do profilowania wydajności są również bardzo dobre, szczególnie gdy uderzasz w krytyczne wąskie gardło, ale wydaje się, że niewiele osób je zna (i przyznaję się do pewnego stopnia w tej kategorii).

Dobre narzędzia XML są niezbędne - jeśli pracujesz z plikami XML więcej niż tuzin linii lub schematów wielokrotności. Czasami potrzebujesz czegoś więcej niż tylko podstawowej składni, która wyróżnia inne edytory. Również podczas pracy z XML nauka XSL może być bardzo przydatna. Wiele razy widzę, co można zrobić w prostej transformacji XSL wykonanej w wielu wierszach kodu aplikacji. Choć należy wyjaśnić: nie sugeruję, że sam XML jest „niedocenianym narzędziem programistycznym”; Sugeruję, że wartość dobrych edytorów XML jest niedoceniana z tego, co widziałem.

— FrustratedWithFormsDesigner
źródło
1
++ Absolutnie diffjest niedoceniany. Jeśli chodzi o profilowanie, nie jesteś sam, myśląc, że muszą być przydatne, ale sam nie wiesz, jak to zrobić. Sprawdź to.
— Mike Dunlavey,
Tak, zastanawiałem się nad nauką narzędzia do profilowania, ale nigdy tego nie dostałem
— Anto
23
+1 dla profilowania, +1 dla narzędzi diff, -1 dla narzędzi XML. Niektórzy ludzie, gdy pojawia się problem, myślą „Wiem, użyję XML”. <Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening>
— Mason Wheeler,
2
@Mason: Cute XML.
— Mike Dunlavey,
10
@Mason Wheeler: Nie sugerują XML jako narzędzia do rozwiązywania problemów, zasugerowałem dobrych narzędzi XML - jeśli masz do pracy z XML, upewnij się, że masz editor / narzędzie, które jest bardzo dobry. Coś, co może wykonywać zapytania Xpath, sprawdzanie poprawności schematu, transformację, porównywanie wartości z strukturą (wydaje mi się, że to specjalne narzędzie do porównywania) itp. ... Proste edytory z podświetlaniem po prostu nie potrafią wyciąć, gdy robi się bałagan - często robią rzeczy gorzej (btw lubię twój kod XML;)).
— FrustratedWithFormsDesigner
37

Wyrażenia regularne

Są po prostu bardzo przydatne. Pomagają w wyszukiwaniu plików dziennika, analizowaniu tekstu itp. Są po prostu niezwykle przydatne.

Dziwi mnie, ilu ludzi znam, którzy nigdy ich nie używają, ponieważ wiąże się z nimi trochę krzywej uczenia się. Wiele razy widzę, że ludzie robią rzeczy w trudny sposób (uwaga: przed wyrażeniem regularnym robiłem rzeczy w trudny sposób), gdy prosty wyrażenie regularne może szybko to zrobić.

— barrem23
źródło
8
Pamiętaj, że wyrażenia regularne nie są szwajcarskim scyzorykiem, nawet jeśli są świetne, gdy są prawidłowo stosowane.
— Anto
10
Niezwykle użyteczny - ale często nadużywany, co prowadzi do tajemniczego, niemożliwego do utrzymania kodu. Stare powiedzenie „teraz masz dwa problemy” ma w rzeczywistości pewne podstawy.
— Steve314,
4
RegExes to szwajcarski scyzoryk: odpowiednie narzędzie do wielu szybkich prac, choć prawdopodobnie nie jest odpowiednim narzędziem do budowy całego domu.
— JasonTrue
4
Hmm, z jakiegoś powodu zawsze miałem wrażenie, że regex był daleki od niedoceniania. Zbyt często widzę ludzi sięgających po wyrażenie regularne, w którym wystarczyłby zwykły podział / pętla for lub gdy wyrażenia regularne po prostu nie są odpowiedzią (np. Parsowanie xml / html).
— MAK
Widziałem oba zjawiska: Regex? To jest nieczytelne / wolne / wstaw pejoratywne tutaj i „Jaki jest najlepszy sposób na parsowanie (wstawianie całkowicie nieregularnej gramatyki) za pomocą jednego wyrażenia regularnego?”
— JasonTrue
24

Twoi współzawodnicy. Kiedy masz ochotę na jakiś pomysł i zapominasz o włączeniu swojego zespołu, nigdy nie usłyszysz ich obaw ani pomysłów, dlaczego to nie zadziała lub dlaczego może być jeszcze lepiej.

Mówię to, ponieważ łatwo jest myśleć, że programowanie jest czymś aspołecznym, co ludzie robią w kącie ze swoimi genialnymi pomysłami. Ludzie, którzy uważają, że nie doceniają wartości zespołów i ich kolegów z drużyny, pomagają sprawić, by pomysły / projekty zatonęły / popłynęły.

— Doug T.
źródło
Dobrych kolegów z drużyny nigdy nie można przecenić. Większość oprogramowania i sprzętu może.
— Anonimowy typ
19

Google. Istnieje bardzo niewiele problemów, które nie zostały jeszcze rozwiązane i udokumentowane. Dobrze dostrojone zapytanie Google może zaoszczędzić każdemu dużo czasu.

— Adam Crossland
źródło
13
Dobre narzędzie, ale nie jestem pewien, czy nazwałbym to lekceważeniem, przynajmniej już nie (może zgodziłbym się 9 lub 10 lat temu).
— FrustratedWithFormsDesigner
12
Przykro mi, ale Google nie docenił? Przynajmniej Google jest przeceniany :)
— eestein
2
Wiem wiem! Ale moim uzasadnieniem dla stwierdzenia, że ​​jest niedoszacowane, jest takie, z którym podejrzewam, że się zgodzisz: co najmniej 75% pytań zadawanych na StackOverflow można łatwo odpowiedzieć w Google, tak? Oczywiście do pewnego stopnia nie docenia się tego, że tak wielu ludzi go nie używa. Jeśli moje uzasadnienie jest błędne, usunę moją odpowiedź.
— Adam Crossland,
3
@Adam Crossland: 75% jest uprzejmy. Myślę, że jest wyższy niż to.
— S.Lott,
1
@adam @ s.lott, więc chyba chodzi o to, że Google nie jest właściwie używany. Zgadzam się z tym. Odpowiedzi na tak wiele pytań (nie trzeba by było zadawać), gdyby ludzie wiedzieli, jak prawidłowo Google. Pozdrowienia.
— eestein 11.03.11
16

Zdecydowanie najbardziej niedocenianym narzędziem do znajdowania „wąskich gardeł” jest Ctrl+ Club przycisk „Wstrzymaj” w debuggerze.

Sprawdź ostatni akapit tego postu oraz ten post i ten post na początek.

Tak wiele razy widzę / słyszę ludzi mówiących: „Program jest zbyt wolny! Co mogę na to poradzić? Próbowałem profilera (jeśli tak zrobiłem), ale nie rozumiem, co to mówi. Ktoś ma jakieś domysły? Pomocy! „ Domysły są właśnie takie. To, co zawsze robiłem, podobnie jak inni, to uruchamianie, przerywanie i sprawdzanie stosu wywołań. Jeśli problem jest naprawdę poważny, bingo , jest tuż przed tobą. Jeśli problem jest tylko łagodny, zrób to kilka razy. Wszystko, co pojawia się na więcej niż jednej próbce, którego można uniknąć, jest wąskim gardłem, które można naprawić.

Tak, to przynęta negatywna, ale działa.

— Mike Dunlavey
źródło
Nie należy lekceważyć tępych instrumentów. Oczywiście nie zawsze jest to właściwa odpowiedź, ale może być. Nazwij to przybliżeniem pierwszego rzędu, które w razie potrzeby może zostać poprawione przez prawdziwy profiler.
— Kristof Provost
@Kristof: Kuszące jest, aby tak myśleć, i są problemy, z którymi nie można sobie poradzić, i są przypadki, w których próbki nie są łatwe do uzyskania, ale profilerzy również nie mogą sobie z nimi poradzić, z wyjątkiem pewnego rodzaju, takiego jak Zoom , a nawet wtedy nie są lepsze w tym sensie, że prowadzą cię bezpośrednio do problemu.
— Mike Dunlavey,
@Kristof: Oto rodzaj problemu polegającego na tym, że losowe wstrzymywanie nie jest dobre - w przypadku, gdy weźmiesz migawkę w czasie i przestudiujesz, nie możesz podać przyczyny tego, co robi. Przykład: przetwarzanie oparte na wiadomości, w którym nie można określić, skąd wiadomość została wysłana ani dlaczego i jak często. Kolejny przykład: protokoły asynchroniczne, w których wiadomości są wymieniane i wygląda na to, że zawsze czekamy na drugiego faceta. W przypadku przetwarzania synchronicznego profilery mogą mierzyć lepiej, ale losowe wstrzymywanie jest lepsze w wyszukiwaniu .
— Mike Dunlavey,
14

Jak myślisz, jaki rodzaj narzędzia programistycznego jest najbardziej niedoceniany? Motywuj swoją odpowiedź.

Kompilator.

Większość ludzi nie potrzebuje czasu, aby zrozumieć, co robi ich wybrany kompilator. Po prostu czują, że zamienia kod w program, który można uruchomić, i to jest tak daleko, jak to możliwe. W większości współczesnych istnieje kilka konfiguracji, w które można go zasilić, dzięki czemu działa tak, jak trzeba. Oto przykład, założę się, że połowa deweloperów w twoim biurze nie ma pojęcia, jak ustawić ostrzeżenie jako poziom błędów (zakładając, że faktycznie ma taki poziom). Jakie opcje musisz wygenerować symbole debugowania? Których optymalizacji (lub jakiego poziomu) chcesz dokonać. I tak dalej.

— Kevin
źródło
3
@Kevin: i dodałbym sposoby pisania kodu, aby kompilator przeprowadził dla ciebie sprawdzanie (dla języków o typie statycznym). Większość deweloperów używa gotowych typów (takich jak łańcuch) do reprezentowania wszelkiego rodzaju informacji, w których mogliby zdefiniować proste, ale niekompatybilne typy dla niepowiązanych danych ... i mieć kompilator, którego nie zepsuły podczas przekazywania argumentów.
— Matthieu M.,
@Matthieu M To także dobra uwaga. Wiele osób zapomina o łatwych sposobach pomocy.
— kemiller2002
3
Każde ostrzeżenie kompilatora jest cennym prezentem. Nie ignoruj ​​ich! Poproś o więcej! - Błąd powinien być obowiązkowy.
— Kristof Provost
@Kristof: -pedantic -Wall -Wextra -Werror... chociaż wtedy może być trudno zbudować cokolwiek: p
— Matthieu M.
Może to tylko ja, ale jeśli „połowa deweloperów” nie wie, co z symbolami debugowania ”nie jest przesadą, to jest dość zniechęcające.
— kizzx2 15.04.2011
10

Twój mózg. Inne narzędzia bez niego nie miałyby większego znaczenia.

— Jnevelson
źródło
4
Czasami sprawiłem, że moje są w większości niezdatne do użytku.
— David Thornley,
3
„mniej lub bardziej zapomniane”: -S
5
Powiedziałbym, że jest niedoceniany. Zbyt wielu ludzi zawsze szuka skrótów, aby nie musieli myśleć. Nic nie zastąpi zdrowego rozsądku i logiki, a narzędzia po prostu tego nie zastąpią.
— jnevelson
2
Zgadzam się z Jonathanem, mózg jest często niedoceniany. W rzeczywistości zbyt wielu programistów polega na kilku sztuczkach, które znają, zamiast wychodzić z pudełka i od czasu do czasu pisać na zamówienie (tanią i brudną, wyrzuconą klasę) skrzynkę testową oraz narzędzie testowe, aby zbadać problem. Wielokrotnie dawałem programistom środki, by wyjść poza ich stan myślenia i rozwiązać ich problemy za pomocą zaledwie kilku pytań.
— asoundmove 11.03.11
1
Niektóre komentarze skłoniły mnie do zmiany zdania, +1 :)
— Anto
10

Dobry stary:

print

Czasami użyteczny jest debugger lub profiler lub diagram przepływu UML. A czasem doprowadzają cię do szaleństwa. Zawsze wracam do używania instrukcji print (lub trace, NSLog lub what-have-you) tylko po to, aby upewnić się, że mój kod robi to, co myślę, że robi, kiedy myślę, że to robi.

— JRW
źródło
Myślę, że to zależy od języka i debuggera. Tego rodzaju debuggery oferowane przez większość przyzwoitych IDE dla popularnych języków pozwalają ci robić rzeczy o wiele łatwiej niż wypisywanie instrukcji.
— Billy ONeal 13.03.11
8

Zwykłe stare skrypty ... bez względu na to, ile języków nowej generacji opracowujemy, nadal w dużym stopniu polegamy na skryptach, a większość codziennych zadań można wykonać, pisząc kilka wierszy skryptów.

— Gaurav Sehgal
źródło
1
Widzisz… Nie zgodziłbym się z tym. Tak, skrypty mogą zautomatyzować niektóre zadania. Ale często są one zabrane daleko poza sens, aż do momentu, w którym stają się dużym szczupakiem spaghetti.
— Billy ONeal
1
To prawda, że ​​duże skrypty są makabryczne i można do tego użyć Perla lub Pythona. Chociaż nadal świetnie sobie radzą w wykonywaniu drobnych prac.
— Gaurav Sehgal
@Billy Użyj Pythona. Problem ze spaghetti rozwiązany :)
— Evan Plaice
5

Perl i inne języki skryptowe. Idealny do zadań, które są nieco zbyt skomplikowane dla narzędzi GUI, takich jak Agent Ransack.

— Kevin Cline
źródło
1
Nie jestem pewien, czy są niedoceniani ...
— Anto
3
Zdecydowanie niedoceniany ... zwłaszcza Perl. To jest język. bardzo dobrze zaprojektowany z prostą dewizą… jako taki, jest bezcenny dla szybkich zadań, które po prostu trzeba wykonać.
— Rook
@Rook: Nie jestem pewien, jak język z ponad 100 operatorami można uznać za „prosty”. Być może przydatne. Ale nie „proste”.
— Billy ONeal
@Billy - Simple nie wyklucza potężnego. Uważam kalkulatory za proste. Nie wiem, co robi połowa z moich 300 funkcji, ale to nie zmniejsza jej prostoty.
— Wież
4

Skróty klawiaturowe, które umożliwiają szybkie, częste i bezpieczne refaktoryzowanie. Uczenie się, jak wyciągać (lub wstawiać itp.) Zmienne, metody, stałe lub klasy za naciśnięciem niektórych klawiszy, zasadniczo zmieniło sposób, w jaki koduję. Będziesz refaktoryzować tylko często (tj. Wystarczająco), gdy koszt jest minimalny, więc uczynienie tych skrótów drugą naturą jest niezbędne, jeśli chodzi o pisanie i utrzymanie dobrego kodu.

Ogólnie używaj dobrych narzędzi (IDE / edytor) i dowiedz się, jak uzyskać jak najwięcej funkcji, które zapewniają.

Kolejne są testy jednostkowe i TDD, aby Twój kod był testowalny i aby uniknąć strachu przed refaktoryzacją.

Skorzystaj z nich, a z łatwością przejdziesz do pisania poprawnego, łatwego w utrzymaniu kodu, który jest zgodny z zasadą DRY i jest samodokumentujący.

— Alba
źródło
4

Testy jednostkowe zapewniają następujące korzyści:

  • Programiści stają się pierwszymi klientami kodu. Im szybciej zostanie wykryty błąd, tym tańsze jest jego naprawienie. Błędy mogą zostać wykryte przed kompilacją, instalacją lub wdrożeniem .
  • Testowanie zmienia twoje spojrzenie na kod. Czy projekt jest przejrzysty? Czy obsługuje skrzynie narożne?
  • Efekt Hawthorne poprawi jakość, po prostu ogłaszając, że zespół publikuje wskaźniki jakości / testowania.
  • Nawet jeśli testy nie są sprawdzane pod kontrolą źródła, mogą być świetnym sposobem na odkrywanie i poznawanie nowego terenu.
  • Wysokie prawdopodobieństwo mniejszej liczby błędów!
— Michael Easter
źródło
4

Generatory kodu

Generatory kodu mogą tworzyć dużą ilość wydajnego i wolnego od błędów kodu na podstawie prostej definicji. Zastosowania typu ORM są najbardziej oczywiste przy tworzeniu klas dostępu do danych, ale istnieje wiele innych potencjalnych zastosowań.

Obsługa generowania kodu wydaje się być jeszcze w powijakach, zarówno z punktu widzenia programisty, jak i frameworka, ale wierzę, że będzie to coś, co będzie coraz więcej. W .NET możesz rozpocząć dabbing przy pomocy CodeDOM .

— konrad
źródło
Lubię pisać generatory kodu, nie jest to najłatwiejsze rozwiązanie, ale och, takie przydatne.
— Zachary K
3

Często używam AgentRansack . Jest to ogromna pomoc w bardzo szybkim przeszukiwaniu tysięcy plików. Zaoszczędziło mi to dużo czasu, ale nie znam wielu programistów, którzy wiedzą o tym lub go używają.

— JakeRadakovich
źródło
3

Metody formalne.

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

Trudno przecenić ich znaczenie. Każda pętla i każda instrukcja if zaczyna się jako pomysł, który wymaga pewnego rodzaju „dowodu”. Większość programistów robi to w większości przypadków w swoich głowach. Pytasz, co robi instrukcja if, a oni mogą wypowiedzieć - rozsądnie i logicznie - jakie są wybory i dlaczego wybory są kompletne, spójne i wyłączne.

Ale niektórzy zdają się zgadywać losowo. Potrzebują więcej pomocy, a formalne metody mogą być potrzebną im pomocą.

To tylko algebra (i rachunek) dla kodu. Nic zbyt skomplikowanego ani wyrafinowanego.

— S.Lott
źródło
Uważam, że często przydają się one do porządnego wykonywania prostych czynności, dzięki czemu mogę na nich polegać podczas debugowania bardziej skomplikowanych rzeczy. Z mojego doświadczenia wynika, że ​​metody formalne całkiem dobrze eliminują subtelne błędy, pozostawiając tylko te rażące oczywiste, które można łatwo złapać podczas testowania.
— David Thornley,
3

Fizyczne wzorce projektowe, takie jak opuszczanie krzesła na szybki jogging w słońcu i świeże powietrze, utrzymują nasze mózgi w szczytowej niesamowitości.

— Joe Chrysler
źródło
3

Cóż, to Half Life 2 (wstaw tutaj swoją ulubioną grę). Jeśli mam problem, którego nie mogę rozwiązać, po prostu rezygnuję i zaczynam grać w moją ulubioną grę i nagle rozwiązanie pojawia się w mojej głowie. Szczerze mówiąc, nie jest to gra ani coś takiego, ale robienie czegoś innego . Często widzę ludzi siedzących nad problemem przez wiele godzin bez jego rozwiązania i wszystko, co powinni zrobić, to wyłączyć mózg na krótki czas.

— Adam Arold
źródło
3

Przepełnienie stosu - szybka pomoc eksperta, gdy utkniesz

strona z pytaniami i odpowiedziami dla profesjonalnych i entuzjastów programistów. Jest zbudowany i obsługiwany przez Ciebie jako część sieci Stack Exchange stron z pytaniami i odpowiedziami. Z twoją pomocą współpracujemy nad stworzeniem biblioteki szczegółowych odpowiedzi na każde pytanie dotyczące programowania ...

— komara
źródło
+1, ale już nie tak niedoceniane
— MAK
4
może nawet zawyżone, a przynajmniej nadużywane
— Anto
3

Myślę, że to Notepad / TextPad / proste programy do edycji tekstu. Każdy ma czas, kiedy potrzebuje szybkiej poprawki, która nie wymaga otwarcia IDE i potrzebuje tylko szybkiej edycji. Wszystkie komputery mają jakiś prosty program do edycji tekstu.

— Peter Mortensen
źródło
2

Zapewnia i dobrą alwaysAssert()funkcję. IMHO są one ważniejsze niż testy jednostkowe, ponieważ testy jednostkowe mogą znaleźć błędy tylko w określonych przypadkach, które chciałeś przetestować. Jeśli ten sam programista napisze kod i testy, prawdopodobnie nie trafi w obu przypadkach na te same zbocza. Co więcej, czasami testowanie jednostkowe jest niepraktyczne, ponieważ środowisko, w którym funkcjonuje komponent i / lub dane, na których działa, jest zbyt skomplikowane, aby wymyślić wymyślony przypadek testowy.

Piękno twierdzeń polega na ich zdolności do dokumentowania założeń i testowania ich na nieskomplikowanych danych wejściowych . Jeśli którekolwiek z tych założeń jest błędne, kod zawiedzie głośno zamiast „działać”, ale generować subtelnie niepoprawne wyniki. Nie udaje się też bliżej źródła problemu niż bez twierdzeń. W praktyce, jeśli wyraźnie podasz wystarczające założenia dotyczące fragmentu kodu i wszystkie te założenia są poprawne, wówczas kod jest zwykle poprawny.

Jednym z powszechnych problemów związanych z twierdzeniami jest to, że można je wyłączyć. IMHO każdy język lub standardowa biblioteka powinna mieć alwaysAssert()funkcję lub przybliżony odpowiednik, który robi to samo, assertale nie można go wyłączyć. Można to wykorzystać do sprawdzania założeń w krytycznych obszarach kodu, które nie są wydajne, a korzyści z wyłączenia twierdzeń są znikome.

— dsimcha
źródło
Zgoda. Ale niestety proste, ale wydajne narzędzia tego typu są często niedoceniane.
— Peter Mortensen
2

Klawisz F1. - Przydatny w przypadku programów, których nie znasz i programów, nad którymi pracujesz. (Zakładając, że jest to duża aplikacja).

Potężne do odfiltrowania problemów było zgłoszenie przez użytkowników błędów na podstawie ich interpretacji sposobu działania oprogramowania. Oczywiście możliwe, że sam projekt był wadliwy. Ale to inna historia.

— Jeremy Edwards
źródło
2
Zarówno niedoceniane, jak i niedostatecznie wdrażane.
— Anonimowy typ
Bardzo niedoceniane przez twórców aplikacji, z której obecnie korzystasz; jako taka pomoc zawiera niewiele lub nie ma żadnych użytecznych informacji.
— poke
2

Różne podstawowe narzędzia UNIX, ale przede wszystkim findi sporadycznie greplub ed. Umiejętność znajdowania rzeczy w głębokich gniazdach plików jest nieoceniona, szczególnie gdy nagle odziedziczysz bazę kodów i musisz ją naprawić. Nawet jeśli wspomniany kod jest dobrze udokumentowany, prawdopodobnie będziesz musiał polować, a dobre zrozumienie findgo zabije.

— kojiro
źródło
2

Ciekawość

Nazwij to „zagadką programowania”. Co to jest narzędzie w porównaniu do osoby, która go używa? Chęć dowiedzenia się, jak i dlaczego coś działa lub nie działa, poszerza swoją wiedzę bardziej niż jakiekolwiek konkretne narzędzie i jest to prawdą poza programowaniem.

— Tomasz
źródło
1

Ogon

Program Tail może służyć do monitorowania pliku wyjściowego dziennika programu w czasie rzeczywistym. Było to bardzo pomocne podczas opracowywania systemów, które nie zapewniają innym możliwości odczytu dziennika.

Przykładowe programy to;

— Komunikat
źródło
Mac OS X to system UNIX. Nie trzeba wspominać o tym osobno.
— prawej strony
0

Połączyłem jeden raz generator wykresów wywołań Perla. Było to niezwykle użyteczne, ale wymagało od nieprocesowego kodu lub procedur spoza pliku.

— Paul Nathan
źródło
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.