2018-01-28 чукове
by Vasil Kolev“Не го насилвай, вземи по-голям чук”
Каня се от много време да направя debugging workshop, и около мисленето как точно да стане днес стигнах до интересен извод за инструментите, дето ползвам и си правя за дебъгващи цели и като цяло за разни мои начини на работа.
Чукът е хубаво нещо. Какъвто и проблем да имаш, след удара с чука резултатът има същия вид (сплескан) и донякъде ми се вижда като хубава метафора за начина, по който оправям някакви проблеми. Той може да се опише като “най-краткия и прост начин за достигане на нужното крайно състояние, без да има особено значение какво е началното.
Като за пример, тия дни ми се налагаше да подменя едно парче софтуер в 50-тина клъстера, като всеки от тях имаше м/у 3 и 50 машини. Понеже инструментите, които имам са pssh и pscp, се оказа най-лесно на един пас да копирам нужните файлове по всички сървъри, и на втори пас да се логне pssh и ако трябва, да копира където трябва, иначе просто да изтрие това, което бях копирал. Някакъв по-подреден начин би било да извадя списък на всички машини, на които има нужда да се направи действието и да го направя само там, но щях да го напиша и направя по-бавно, отколкото по грубия и бърз начин.
По подобен начин за друг инструмент си бях написал скрипт, който го налива в цял клъстер и отделен, който го update-ва. В един момент осъзнах, че това е тъпо и направих инсталатора така, че да не му пука, ако има вече нещо инсталирано и просто спокойно да може да слага отгоре (както и ако го прекъсна и го пусна пак, да свърши пак нужната работа). Крайният резултат беше, че общото количество код намаля.
Принципът изглежда да може да се приложи към любимите ми начини за дебъгване – това, което ползвай най-често е strace, което спокойно може да се опише като един от най-тежките чукове за дебъгване. Почти без значение какво дебъгвам – компилиран C код, php, python, perl, java – успявам да видя симптомите и да се ориентирам какво става, въпреки че като цяло за всеки от тия езици има специализиран и вероятно доста по-нежен вариант да се гледа какво става.
(искам да отбележа, че има и други тежки случаи – имам колега, който за да смята някакви математически изрази от време на време вместо да си пусне някакъв калкулатор като bc, пуска gdb и прави в него нещо като “p 1024*1024*231/1.1”)
Замислил се бях дали това всъщност не е погрешно и че трябва да се избягва, и стигнах до извода, че не виждам друг работещ начин. Много често ни се налага да дебъгваме чужд код (който сме link-нали/който е под нас някъде/от който зависим, или просто това са ни изсипали) и вариантът да го прочетем и разберем не е опция, понеже в наши дни почти няма проекти, които да могат да бъдат изчетени и опознати за под седмица-две (рекордно малкият код, който в една от фирмите, в които съм работил и търкаляше основните услуги беше около 20000 реда, което е горе-долу в човешките възможности, и пак ще отнеме доста време да се разгледа, а фирмата в това отношение беше сериозно изключение). Това води до нуждата за всякакви помощни средства, за да можем да се справим, понеже човешката глава има сериозни ограничения по темата, и тук на помощ ни идват чуковете, с които всеки проблем може да бъде сведен до пирон (или хлебарка, която трябва да се прасне достатъчно силно).
(да не говорим, че хората искат да пишат умно, и колкото по-умно пишат, толкова по-трудно се дебъгва това, което са сътворили)
Tags: крокодилски, работа
January 29th, 2018 at 23:45
Маса народ си пренаписват, различни tool-ове за собствено удобство, защото просто на тривиалните, интерфейса им е смотан/скучен..
И едно кратко видео по темата..
https://www.ted.com/talks/chris_domas_the_1s_and_0s_behind_cyber_warfare
February 8th, 2018 at 10:53
Много добре казано това за чука и за желаното крайно състояние! :)
Къде трябва да следя за анонс когато насрочиш дата за бъдещия ти debugging workshop и долу-горе кога планираш да го направиш?
А иначе идеята за собствена модификация на съществуващ (софтуерен) инструмент или собствено написан инструмент, като твоя паралелен tee да речем, би трябвало да е по-популярна. Или поне, във фирмите където съм работил като служител, доста съм се чудил, защо шефовете възразяват срещу внедряването на FOSS инструменти и техни модификации в toolchain-а с който работим. И то при положение, че някой се е подготвил преди да предложи, чел е лицензи, написал подробно кое се смята за industry standard, как то ще ни върши работа и в бъдеще, ще ни спести пари спрямо сегашните комерсиални продукти и въобще – аргументирал се е. Докато пиша това се сещам, че не винаги тези инструменти срещат съпротива: българите по-лесно се съгласяват, а при западните култури, трябва да намериш правилния човек в йерархията който поне малко да разбира материята. (Извинявам се за отклонението, ти все пак имаше предвид друг вид полезни инструменти.)