Tag Archives: розробка - Page 2

Програмна археологія і проблема власника коду

Уявіть собі, виявляється така дисципліна програмної інженерії як археологія існує досить давно, і в 2001 спеціально по ній навіть проводили конференцію.

Ну і я, собі теж, маючи необхідність прикрутив до Vim таку лопату, яка дозволяє копати в Mercurial:

103 command! -nargs=* Blame call Blame(<f-args>)
104 function! Blame()
105     " gets zero, one or two params
106     " first param – revision to annotate (if false – don’t pass)
107     " second param – pattern to search
108     let revision = (a:0 >= 1) && a:1 ? ‘ -r ‘ . a:1 :
109     let pattern = (a:0 >= 2) && a:2 ? ‘| grep ‘. a:2 :
110
111     let command = ":!hg blame -nvud % ". revision . "| cat -n ". pattern ." | less"
112     execute command
113 endfunction

Лопата жахлива бо я на VimScript ніфіга не вмію писати. І взагалі не люблю мови в яких оператор конкатенації рядків – це крапочка. :)

Але вона працює, і дозволяє вияснити хто, коли і під яким приводом (зазвичай посилання в Jira) написав код на який я дивлюсь. Найчастіше якщо трапляється якийсь великий WTF то виявляється що це написав мій CEO ще в 2008, не пояснюючи мотивів, бо тоді й не було кому пояснювати. :) Ну, і його питати немає сенсу, не тому що субординація, чи він зайнятий, а тому, що це було дуже давно, і звісно він не пам’ятає.

Але загалом все нормально. Тільки от з’являється проблемка. Коли я хочу збільшити пов’язаність якогось модуля, доводиться робити переміщення методів. Коли я хочу щоб метод похудав на 100-200 рядочків, доводиться робити витягнення метода. Обидва рефакторинги переміщують рядки коду, і для Mercurial змінюють його власника, бо він бачить лише що я видалив одні рядки, і вставив якісь інші. Те що вони однакові він не бачить.

Git вирішує цю проблему за допомогою евристики по метриках подібності. Що правда трохи страшнувато звучить, бо я не знаю чи можна буде передбачити результат його роботи.

Зібравши один модуль я навіть вгорі копірайти написав, аби в разі чого люди знали що за поясненнями можна іти не тільки до мене.
І от маю дилему – привласнювати код якось невиховано, але якщо наступна моя задача знову полягатиме в перечитуванні 300-рядкового методу, то я сильно пожалію що залишив код в такому стані.

Тепер питання: а вам доводилось займатись археологією? Що за проект? Як враження? :)


Filed under: Кодерство Tagged: hg, розробка, Vim

Легенда про самодокументований код

Якось був код:

        if self.get_package_ids() == [None]: # only free package

Він був дещо незрозумілим, тому прокоментованим. Але потім в когось з’явилась ідея додати

    def only_free_package(self):
        return self.get_package_ids() == [None]

І коментар в нашому рядочку став зайвим:

        if self.only_free_package():

Ось і все. Це коротка легенда з простим сюжетом. Її мораль – методи призначені не тільки для повторного використання. Їх також варто використовувати для ізоляції рівнів абстракції.

Макконел також розповідає що можна писати спочатку псевдокод, потім його поступово закоментовувати (якщо він хороший він може бути документацією), і під ним писати решту коду.

Але дуже часто я бачив псевдокод нижчого рівня ніж Python. Я читав погані псевдокоди?


Filed under: Кодерство Tagged: паттерни, розробка, Python

Про конкуренцію в програмістів

Вона дивна, так що зразу й не скажеш що конкуренція, але я спробую її пояснити. Спочатку розкажу про те яка вона в інших професіях.

Якось на зустрічі з приводу десятиріччя вікіпедії я спілкувався з російським вікіпедистом (який жив в Києві достатньо довго щоб мене розуміти). Він фінансист з System Capital Management, чи щось в тому роді, точно не пам’ятаю. Так от він сказав, що по своїй спеціальності в вікіпедію не пише, щоб не допомагати конкурентам. Пише про цікаві місця Києва, для розваги. Мені було дивно що в мене прямо протилежні бажання. З мого блогу видно, що я всіма силами намагаюсь допомогти конкурентам.

Чому так? Тому що в програмуванні відбувається конкуренція не персон, а спільнот. Яка викликана дефіцитом останніх. Програміст Python буде цінуватись на ринку праці більше, якщо він зможе робити свою роботу краще. Він зможе робити свою роботу краще тільки коли в Python буде більше батарейок, менше багів, більше документації, більше блогів, більше форумів, більше колективного інтелекту.

З іншого боку програмісту самому вигідно допомагати іншим, бо це збільшує досвід, дозволяє отримати конструктивну критику без якої вдосконалюватись важко, і найголовніше – збільшує вплив. Якщо я відкрито продемонструю всім можливість писати крутіше ніж Роман Хоменко, то після того як всі про це дізнаються, приїду в Харків, і заміню його на його роботі :) .

Хоча насправді коли таке відбувається… А ніколи, тому що всі програмісти різні, і кожен майстер у своєму проекті. Вони від відсутності конкуренції навіть придумали спортивне програмування, де всі програмісти пишуть один і той самий проект. Ізольовано. Для розваги. Проект зазвичай не має жодної практичної цінності. І кожен контест для суспільства – це втрата кількох сотень дуже дорогих (за собівартістю і ринково) людино-годин.

Яким чином ведення блогу покращує конкретно мою позицію на ринку праці? З двох сторін.

З одного боку мій блог читають менш досвідчені програмісти, і я економлю їм час. Я не боюсь їх конкуренції, бо поки вони читають те що я вже знаю, я вивчаю щось нове. Але існує ймовірність що вони розкажуть про мене своєму начальнику, або колегам.

З іншого боку мій блог читають люди більш досвідчені, які можуть підказати правильну дорогу далі. Їм це вигідно, бо я можу розповісти про них своїм колегам.

От якби був надлишок програмістів, думаю такої чудової роботи і співпраці не тільки в командах, а й між ними ми б не спостерігали.


Filed under: Кодерство, Психософія Tagged: розробка

Про конкуренцію в програмістів

Вона дивна, так що зразу й не скажеш що конкуренція, але я спробую її пояснити. Спочатку розкажу про те яка вона в інших професіях.

Якось на зустрічі з приводу десятиріччя вікіпедії я спілкувався з російським вікіпедистом (який жив в Києві достатньо довго щоб мене розуміти). Він фінансист з System Capital Management, чи щось в тому роді, точно не пам’ятаю. Так от він сказав, що по своїй спеціальності в вікіпедію не пише, щоб не допомагати конкурентам. Пише про цікаві місця Києва, для розваги. Мені було дивно що в мене прямо протилежні бажання. З мого блогу видно, що я всіма силами намагаюсь допомогти конкурентам.

Чому так? Тому що в програмуванні відбувається конкуренція не персон, а спільнот. Яка викликана дефіцитом останніх. Програміст Python буде цінуватись на ринку праці більше, якщо він зможе робити свою роботу краще. Він зможе робити свою роботу краще тільки коли в Python буде більше батарейок, менше багів, більше документації, більше блогів, більше форумів, більше колективного інтелекту.

З іншого боку програмісту самому вигідно допомагати іншим, бо це збільшує досвід, дозволяє отримати конструктивну критику без якої вдосконалюватись важко, і найголовніше – збільшує вплив. Якщо я відкрито продемонструю всім можливість писати крутіше ніж Роман Хоменко, то після того як всі про це дізнаються, приїду в Харків, і заміню його на його роботі :) .

Хоча насправді таке відбувається ніколи, тому що всі програмісти різні, і кожен майстер у своєму проекті. Вони від відсутності конкуренції навіть придумали спортивне програмування, де всі програмісти пишуть один і той самий проект. Ізольовано. Для розваги. Проект зазвичай не має жодної практичної цінності. І кожен контест для суспільства – це втрата кількох сотень дуже дорогих (за собівартістю і ринково) людино-годин.

Яким чином ведення блогу покращує конкретно мою позицію на ринку праці? З двох сторін.

З одного боку мій блог читають менш досвідчені програмісти, і я економлю їм час. Я не боюсь їх конкуренції, бо поки вони читають те що я вже знаю, я вивчаю щось нове. Але існує ймовірність що вони розкажуть про мене своєму начальнику, або колегам.

З іншого боку мій блог читають люди більш досвідчені, які можуть підказати правильну дорогу далі. Їм це вигідно, бо я можу розповісти про них своїм колегам.

От якби був надлишок програмістів, думаю такої чудової роботи і співпраці не тільки в командах, а й між ними ми б не спостерігали.


Filed under: Кодерство, Психософія Tagged: розробка

Ознака зменшення складності

Їду в неділю в маршрутці. Читаю Макконела. Раптом розумію що хочу дещо записати, і виявляю що забув блокнот. Довелось писати на чеку, який я тримав як закладку. Виявилось все одно краще ніж в твіттері. В твіттері фіг напишеш щось таке абстрактне про програмування…

Отож, по Макконелу, основна проблема програмної інженерії – боротьба зі складністю. Складність в системі з’являється через зв’язки. Тому що зв’язки заважають відокремленому аналізу елементів. Тому, чим менше в системі зв’язків, тим вона простіша. Це очевидно.

Тепер, якщо ми замінимо слово “зв’язки” словом “залежності”, відношення про яке ми говоримо перестане виглядати симетричним. А воно і не є. Якщо A залежить від B, це ще не значить що B залежить від A.

Якщо в програмі є ще якісь зв’язки окрім залежностей – дайте приклад будь-ласка, бо я щось не можу. Наслідування, створення екземпляра, виклик функції, доступ до атрибута, передача в якості параметра – це все залежності.

І от, чим більше речей залежать від певного об’єкта системи – тим краще. Тому що розуміння одного цього об’єкта дасть нам ключі до розуміння багатьох. Чим від більшої кількості інших об’єктів залежить цей – тим гірше. Бо щоб зрозуміти його, доведеться розуміти багато всього іншого.

І взагалі, коли я бачу diff, в якому в 3 різних місцях кількість рядочків зменшується навіть на один, хоча для цього довелось додати ще три рядочки, написавши функцію, на душі чомусь приємно. Зменшується дублювання. Відбувається щось на зразок нормалізації коду.

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

Ну, от так. Непогано, як для нотатки на чеку, правда?

А ще от згадав іншу аксіому. Наперед вибачте якщо для когось пишу очевидні речі. Я стараюсь робити з них очевидні висновки, які чомусь не зразу очевидні. Програма – зв’язний граф. Окрім від функції main, чи якихось інших точок входу, кожен модуль повинен мати залежні від нього. Якщо модуль не має залежних модулів, значить він непотрібний і його можна викинути. Більше того, це правило транзитивне. Якщо програма має кілька компонент зв’язності, то компоненти без точок входу можна викинути.

Увага! Під словом “модуль” тут мають на увазі частини системи на певному рівні абстракції зв’язки між якими аналізують. Звичайно на певному рівні абстракції це можуть бути модулі в класичному розумінні – окремі файли програми. Але більш точним відповідником того що я маю на увазі тут під словом модуль буде функція.

Так от, виникає потреба в інструменті який би проводив аналіз коду, і виявляв компоненти зв’язності, виявляючи код що можна видалити. Pylint поки що для цього недостатньо підходить, бо виявляє проблеми дуже локально. І динамічна природа Пітона, та метапрограмування трохи цьому заважає. Також заважають тести. Бо кожен тест має свою точку входу, тому їх не треба враховувати. Але не забувати видаляти тести модулів з непотрібних компонент зв’язності.

Можливо треба буде якось написати такий інструмент. Хіба ж не для цього створили модуль _ast? ;)

А на наступній сторінці вас чекає велика і жахлива формула.


Filed under: Кодерство Tagged: розробка

Додзьо для регулярного ніндзя

Щойно вивчив чим відрізняється negative lookbehing від negative lookahead.

Шукав всі пітонівські файли які не є скомпільованими мако файлами що містять певний шаблон. В моєму випадку – всі місця в проекті, в яких рендериться вміст листів. Написав:

    :Ack -G "(?!\.mako)\.py$" "email/[_/\w\d]+\.mako"

Не знайшов. Бачите в чому помилка? Тут я використав lookahead, а треба було lookbehind. Lookbehind пишеться так:

    :Ack -G "(?<!\.mako)\.py$" "email/[_/\w\d]+\.mako"

Хто б подумав, що треба писати так. Але тепер я вже знаю :) . Ах, для тих хто не зрозумів що відбувається, ack – це типу grep.

І от в мене виникла ідея – взяти якось на вихідних і написати інтерактивний підручник регулярних виразів. Такий собі html-файлик, всередині якого в JSON записано набір уроків в такому форматі:

[
    {
        'Назва': "...",
        'Текст уроку': "...",
        'Вправи': [
            {
                'Умова': "...",
                'Корпус тексту': "...",
                'Тип вправи': 1, # пошук/заміна
                'Підрядки що потрібно отримати з домогою виразу': ["...", ...],  # якщо пошук
                'Текст що потрібно отримати в результаті': "...", # якщо заміна
                'Бали': XP, 
            },
            ...
        ]
    },
    ...
]

І тебе пускають до наступного коли ти набрав необхідну кількість балів на попередньому.

Тепер розшукую regexp – гуру, jQuery – гуру, гуру верстки, і технічних письменників (чи просто літературних редакторів) які б це все допомогли реалізувати.


Filed under: Кодерство, Павутина, Розмітка Tagged: JavaScript, розробка, цілі

Археологія в програмуванні. Міждисциплінарне есе

Крім програмістів – архітекторів бувають програмісти – археологи. І невдовзі ми постараємось вияснити хто вони такі, і чим займаються.

Але спочатку цікавий факт: Археологи припускають що довжина сторони основи піраміди Хеопса була a = 230.33 (поки не стерлася), а її висота h = 146.6.

Любителі арифметики порахували, що
\displaystyle 2\frac{a}{h} \approx 3.142291950886767 \approx \pi

І от, якби вони були програмістами, в них виникло б питання:
“Ну і чого це Єгиптяни захотіли саме такі розміри?”,
“Що, число пі допомагає фараону краще сохнути?”,
“А що буде якщо збудувати вищу піраміду?”

І подібні. Взагалі то, поговоривши з архітектором можна було б вияснити чи було серед вимог до піраміди “вона повинна сушити мумії”, і якими архітектурними рішеннями він цього добився. Але про нього відомо лише що його звали

Хеміун

Хеміун

і що він мертвий. Правда ймовірно якась документація коло піраміди, або в самій піраміді залишилась. Якщо звісно її не полінувались перенести з папірусу на камінь.

Програміст – археолог робить те саме що й звичайний археолог. Намагається дізнатись побільше про те що хотів зробити архітектор. (Тобто спочатку про те що в архітектора вийшло, і чому воно так).

Звісно, в айтішній археології використовуються зовсім інші інструменти, і результати теж виглядають по-іншому.

Наприклад ось збережені письмові свідчення про те хто писав реалізацію мови Python (cpython), і що він про це думав 14 травня 91 року:

         guido Sun May 05 20:09:44 1991 +0000: /* Long (arbitrary precision) integer object implementation */
         guido Tue May 14 12:06:49 1991 +0000: /* XXX The functional organization of this file is terrible */
         guido Fri May 02 03:12:38 1997 +0000: #include "Python.h"

Програмістам археологам часто простіше ніж їх побратимам історикам, бо програмні архітектори зазвичай живуть довше за свої творіння, і з ними, якщо дуже треба можна сконтактуватись через електронну пошту, чи навіть соціальні мережі. Навіть незважаючи на те що Python вже дуже стара мова як для ІТ (приблизно мого віку), але сама галузь програмування народилась під час другої світової. А це новітня історія, а не історія стародавнього світу, якою займаються археологи в Єгипті.

Які якості повинен мати програміст археолог? Ну, по перше – терпіння. Його робота не така приємна як в архітектора, бо доводиться зустрічатись сам на сам з ідеями іншої людини, яка може виражати їх занадто по-іншому, бо належить до іншої культури, користується іншою мовою. Та не мені вам розказувати чому люди різні.

Про індійських програмістів яким платять за кожен рядочок коду, тому вони пишуть багато жахливих рядочків ходять легенди. Це упередження яке придумали погані археологи. Насправді багато індійських програмістів круті як герої індійських фільмів. Ну, і звісно економічна стимуляція покращення певних метрик призведе лише до тупого нарощування цих метрик. (Джоел про те як не треба командувати програмістами), а правильна мотивація до творчості повинна знаходитись на вершині піраміди Маслоу.

Так от, я про те, що якщо вже доля змушує бути археологом, то постарайтесь тримати мозок відкритим, а кругозір широким. Навчіться читати деванагарі в кінці-кінців. :) Он деякі мої знайомі окрім того що вчили Рубі, почали вчити ще японську. Думаєте це просто так?

І хоча терпіння потрібне, толерантність необов’язкова. Якщо вам від того полегшає, можете скільки завгодно матюкати індійських архітекторів. Чи кого ви там читаєте.

Більше того, що звичайному археологу зась, те дозволено софтверному. Звичайний археолог користується пензликом аби змітати грунт з відкопаних артефактів. Прораміст-археолог може розібрати піраміду на окремі блоки, спробувати по черзі забрати кожен блок з піраміди і подивитись чи буде вона після цього стояти та сушити мумії, замінити деякі блоки на свої, або взагалі збудувати з найкращих блоків нормальний елеватор, а зайві викинути, хоча тоді він знову перетвориться в архітектора. Але основне – дізнатись як змусити піраміду робити те що нам потрібно, а не яких фараонів вона сушила.

Ще археологу дозволяється після того як він розібрав що там нашкрябано древньоєгипетською (ах, так, він повинен вміти читати код. Багато.) дописати збоку коментар про те що функція блоку і його інтерфейс вияснені. І навіть заохочується. Архітекторам які прийдуть після археолога буде простіше переставляти блоки якщо вони будуть підписані.

Також арехологу потрібно мати гарну короткотермінову пам’ять. Багато програмістів (з книжки Coders at work) кажуть що чим гірша короткотермінова пам’ять в програміста, тим менш заплутаний код він пише. Це стосується архітектора. Археолог навпаки – чим більше зможе охопити в пам’яті за раз, тим швидше він зможе зрозуміти задум архітектора.

Ну, і окрім гарної пам’яті, археологу потрібні гарні інструменти.

Це перш за все великий комфортний монітор на якому влізається побільше символів, бо архітектор тільки те й робить що читає.
По друге – редактор, який обов’язково повинен мати вкладки (щоб можна було відривати одночасно кілька фізично віддалених шматків коду), буфери/вікна (щоб можна було, порівнювати різні шматки коду не перемикаючи вкладок), швидкий доступ до пошуку довільної складності, швидкий перехід по тегу (до місця опису конкретного ідентифікатора), і навпаки – пошук місць використання ідентифікатора. Тобто редактор повинен бути більше браузером ніж редактором.

Є популярний аргумент проти ефективних редакторів коду (від людей які так і не подолали поріг входження), що думає програміст 90% часу, а набирає код – 10%, тому його ефективність залежить від його голови, а не від редактора. Цифри можуть бути навіть заменшені, але можна привести контраргумент – зручніше думати пролітаючи в редакторі крізь 5 рівнів абстракції за секунду, і не думаючи про те чи ти натискаєш C-], чи n.

Посилання

  1. Переклад статті про обернене промислове шпигунство та корпоративну
    археологію, яка наштовхнула мене на роздуми з цієї статті.
  2. Стаття про те що треба читати код, а документація завжди буде відсутньою, застарілою або неправильною.
  3. Трохи про те як зробити Vim браузером.

Filed under: Кодерство Tagged: розробка

Парадокс роботи програміста

Полягає в тому що вона таки виконується. І код, хоча містить сотні помилок, все таки працює.

Захід є Захід, а Схід є Схід, і їм не зійтися вдвох,
Допоки Землю і Небеса на Суд не покличе Бог;
Та Сходу і Заходу вже нема, границь нема поготів,
Як сильні стають лицем у лице, хоч вони із різних світів!

Р. Кіплінг.

Основна відома мені різниця між сходом і заходом – захід більше орієнтований на ціль, а схід – на процес. І того я не можу зрозуміти як в китайців з японцями і південнокорейцями взагалі щось виходить з роботами, Ruby і айфонами. Філософічка щось там казала про те що китайський воєначальник застосовує принцип недіяння коли починає атаку на ворога, хоча тоді і тепер я такий дзен не можу збагнути.

Далі. На моєму рідному факультеті дехто таки зібрався, і таки видали новий номер газети “Кубик”. (Не соромтесь, візьміть й собі копію. ~9 Мб).

І порівняно з попередніми номерами цей – огого! Він не вийшов в паперовій версії, але думаю це й на краще. Там 40 сторінок дрібним шрифтом! Мій факультет розорився б, якби надрукував це хоча б в 100 екземплярів. А pdf крім того ще й зберігає true color і поліграфічну якість. Я взагалі мрію про те, що на офіційному сайті факультету з’явився RSS. Але скоріше вже збудують метро на Теремки.

Так от, окрім статей про те як на факультеті все погано, і як ніхто не хоче писати в газету, мучать дівчат (головного редактора), і ніхто не хоче вчитись (ну окрім одного наївного першокурсника, який теж свої враження там описав), є багато цікавих речей. І думаю цікавих не тільки нашим студентам.

Наприклад на сторінці 11 є коротенька стаття про те як керувати програмістами. Якої звісно мало щоб навчитись це робити, але уявлення про предмет вона дає.

Коротко: програмістам треба платити достатньо аби вони не думали про гроші. Як відомо гроші не мотивують. Зате їх нестача і стереотип про те що програмістам багато платять мотивує знайти кращу роботу.

Тоді чого, якщо не грошей хоче програміст? Він, як творча людина хоче творити, отримувати від цього задоволення, саморозвиватись. Йому сам процес подобається. Програміст – зі сходу. Але це трохи не те що потрібно проекту.

Проект – західний. Проекту потрібно щоб програміст зробив задачу. Достатньо якісно, і в потрібні терміни. Того роботодавці й шукають програмістів які все знають, аби вони на роботі не надто багато вчились.

І потім згадується методологія. Це така штука яка допомагає залишати програміста задоволеним, і окрім того добиватись того щоб він таки завершував те що повинен зробити.

І це, знаєте, мотивує розібратись з методологіями, і управлінням програмістами. Бо з’являється підозра що мене обманом заставляють робити те що я не хочу :D .

А якщо ввести назву методології яку використовують в нас, у пошуку картинок, то серед знайдених обов’язково зустрінете подібну на цю:
Mêlée ASM-MHRC

От так ми й працюємо. Ті двоє зліва – продакт менеджер і скрам мастер.. :)


Filed under: Кодерство Tagged: кубик, психологія, робота, розробка