Не си достатъчно умен

Когато бях на 8 повечето ми съученици събираха миришещи листчета или колички. Аз пък правих първите си стъпки в програмирането – цъках DOS, правех магии с .BAT файлове и ръчках колкото можех по-навътре в компютъра защото ми беше интересно. В четвърти клас бях написал змията на QBASIC в текстов режим. На QBASIC се научих сам, четейки документацията и експериментирайки. Единственото обучение с учител, което съм имал тогава бе един курс по PASCAL в училища „Европа“ (от който почти нищо не разбрах). Бе, от малък си ме бива в тия неща. И тия ранни сблъсъци много ми помогнаха по-натам да разбера това-онова за занаята.

Разбира се, тия неща могат да се кажат за повечето добри програмисти. Краквахме сме софтуер, писахме бързо сортиране и сме правихме игри докато още ни се налагаше да ставаме в 7 часа за училище. И тогава беше много яко – викаш си „Иха, колко съм умен, к’ви дивотии правя“. После, като влезеш в университета е същата песен – задачите са лесни, научаваш повече, ставаш зъл C хакер – успяваш да държиш в главата си невероятно сложен код, на който повечето колеги само мигат. Отново си казваш „Иха, колко съм умен“. И после, след някоя друга година се хващаш на първата си работа – Java в някоя големичка фирма, където плащат добре. И тогава, изправен пред цялата плетеница от бисери и плява, си казваш „Няма к’во да губя време да чета седмици – направо ще се мятам. Достатъчно умен съм за да се оправя“.

Съжалявам, че аз трябва да ти го кажа. Не си достатъчно умен.

Continue reading

Счупени прозорци

Не, не става въпрос за Windows. Става въпрос за една интересна теория. Хорицата са изучавали как хубав квартал се превръща в гето. Изводът – с един счупех прозорец. Именно. Забелязали са, че ако една сграда има един счупен прозорец е много вероятно по-вероятно вандали да почнат да чупят и другите. Същото важи и за боклука по тротоарите. Докато е чисто, никой не хвърля. Но почне ли да се събира, мотивацията на хората да не замърсяват намалява. И скоро стъпвате по хартиени чаши, смачкани кутии от цигари, остатъци и от дюнери и всякакви други гадости.

Какво е общото между това и тематиката на блога ми? Същата тенденция я има в софтуера. Continue reading

Table-Driven

Това за което ще пиша е един подход за организиране на кода. Срещал съм тази идея под различни имена – Table-Driven Approaches и Data-Driven Programming. Много пъти съм получавал много по-прост и разширяем код с този подход. И понеже ми е малко трудно да обясня на теория, първо ще дам няколко примера и после ще коментирам.

Continue reading

The Pragmatic Programmer

Най-накрая прочетох една важна и основна книга на софтуерния занаятчия: The Pragmatic Programmer: From Journeyman to Master. Страхотна е. Фокусът е върху практическите (прагматичните) и полезни неща, като всяка идея е много добре аргументирана и представена. Аз научих много неща от нея:

  • как да си опростя процеса
  • за какво да внимавам като правя refactoring
  • как да си организирам кода, че да може да се тества особено лесно
  • някои особено хитри начини да държа проекта добре документиран

Тази книга не ви учи как да пишете код. Учи ви как да разработвате софтуер. И то по особено приятен и прагматичен начин.

Най-мъдрите неща в нея са разпръснати в 70 съвета из целия текст. Първият е „Care about your craft“, а последния – „Sign your work“. Философията на човека, който наистина обича да прави софтуер, а не просто да отбива номера от 9 до 5. Ако сте сред тези хора, книгата определено ще ви хареса. Ако не – как въобще попаднахте на този блог? 🙂

Mushroom management

Това IT-то просто не си е работа. Зарязвайте тази лудост и хващайте някоя по-нормална и здравомислеща професия – например водопроводчик. Ще ви е доста по-добре и няма да сте заобиколени с толкова идиотия и лудост.

Свежа илюстрация на горните редове е „термина“ mushroom management. Отнася се за IT отдела. Може да го интерпретирате така:

Keep them in the dark and throw shit at them. And they grow.

Сиреч: събирате група програмисти (гъбите), слагате ги на тъмно (малка влажна стая с щори и стар хардуер) и започвате да хвърляте „тор“ по тях (проблеми, поддръжка, PHP). И те се развиват. Правят нов продукт, поддържат стария, въобще – докарват ви пари.

Не сме хора ние програмистите и туйто.

<button name=“commit“>

Най-честата грешка, която правя в HTML:

<form>
    ……
    <button name="submit" type="submit">Submit</button>
</form>

Разликата е много коварна. Понеже бутона се намира във форма, той е достъпен в JavaScript като form.submit. Което е неприятно, понеже скрива функцията form.submit() и кара повечето ви скриптове да престават да работят по мистериозни причини. Мъдри са хората от Rails като техния submit_tag по подразбиране генерира име commit. Не просто избягват проблема автоматично, но и тренират навик, с който да не попадате в него. В резултат, когато не пиша на Rails винаги си наименовам submit бутоните по този начин. И съм много доволен от това.

Програмиране и шофиране

В книжката си за екстремно програмиране, Кент Бек прави интересна аналогия между разработката на софтуер и шофирането. Тя касае спецификациите. Големият мит на софтуерното разработване гласи, че първо клиента пише спецификация, след това програмистите правят дизайн и накрая го кодят. Поставя се една посока и след това се върви по нея. Кент Бек твърди, че по-скоро прилича на шофирането – дори на най-правото шосе, ако насочите колата право напред и пуснете волана, след най-много минута-две ще сте извън пътя. След като изберат посоката, шофьорите постоянно налагат малки корекции за да не напуснат платното. Така правят и софтуерните разработчици – в процеса на разработка постоянно да правят малки корекции по изискванията, кода и дизайна. Хрумна ми как тази метафора може да бъде доразвита. Continue reading

Интерфейси и абстрактни класове (в Java)

Често ми се случва да се чудя дали да ползвам абстрактен клас или интерфейс докато пиша на Java. И двете идват от леко остарелия ООП апарат на C++, в който наследяването се ползва предимно за две неща – предотвратяване на повторение на код и абстракция. Та, хрумна ми една проста схемичка как да определя кога какво да ползвам.

Continue reading

Uniform Access Principle

Днес прочетох за нещо, наречено Meyer’s Uniform Access Principle. Това е един много интересен прицип касаещ ООП езиците. Гласи горе-долу следното:

Атрибутите на един обект трябва да се достъпват чрез нотация, която не позволява да се различи дали те са имплементирани чрез запис или чрез изчисление.

Иначе казано, line.length не трябва да издава дали става въпрос за поле или метод, изчисляващ разстоянието между двата края. Това е много хубава идея, понеже промотира любимите ми думички – абстракция и енкапсулация. Та, замислих се доколко това важи в езиците, които ползвам.

Continue reading