Блоґ одного кібера

Історія хвороби контуженого інформаційним вибухом

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

with 7 comments

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

Але спочатку цікавий факт: Археологи припускають що довжина сторони основи піраміди Хеопса була 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 браузером.
Advertisements

Written by bunyk

Лютий 16, 2012 at 02:28

Оприлюднено в Кодерство

Tagged with

Відповідей: 7

Subscribe to comments with RSS.

  1. До речі, коли я шукав інструменти для ефективної навігації по коду, мене здивував підхід одного з індексувальників, здається, GLOBAL, — там із коду генеруються html-сторінки із гіперлінками і кінцевий результат можна дивитись у браузері. Але це справді логічно)
    Щодо буферів і вікон, то я досі дивуюсь, як середньостатистичні користувачі Віжуал Студіо можуть жити без них.

    dmytrish

    Лютий 16, 2012 at 15:14

    • ефективніше ніж “тиць” по назві функції не існує. Навіщо щось генерувати по коду, якщо можна і без генерації спокійно пересуватись? (F12 – goto definition, S-F12 – find usages)

      Щодо вікон – не розумію, як можна БЕЗ них жити. Ось мій стандартний набір:
      – вікно коду
      – панель табів
      – дерево проекту
      – вікно Pending Changes (від TFS – контроль версій), показує файли, які відрізняються від origin
      – Error list
      – find in files
      – рідше: тулбар інструментів, вікно властивостей, тулбокс

      Я в цьому списку не бачу лишнього. Всі потрібні.

      danbst

      Лютий 16, 2012 at 16:17

      • Добре, можливо, я перебільшив.
        Але чи є фукнціональність, відповідна буферам vim/emacs у VS?
        Під вікном я мав на увазі ділянку екрана в стилі vim, коли його «вікна» не перекриваються (своєрідний тайловий віконний менеджер). Мені цікаво, чи є можливість розбити вікно VS на дві рівні половинки і перемикатись між ними з клавіатури? Потім ще раз розбити якусь із цих половинок по вертикалі і мати на екрані одразу три файла одночасно (незамінна штука для порівняння двох файлів або для перегляду хедера/сорс файла/тощо? Я бачив таку функціональість у QtCreator, але так і не зміг звикнути до його дивних шорткатів. А як із цим у Віжуал Студії?
        Щодо описаних вікон: вім дає вікно коду, панель табів, через розширення — дерево проекту, error list, find in files. Тулбар особисто для мене мишкотичне зло і засмічувач простору картинками.

        dmytrish

        Лютий 16, 2012 at 17:16

        • тулбар – згоден, рідко використовую.

          Вікна – є. Можна зробити поряд. Можна швидко переключатись (Ctrl-Tab). Можна ділити як завгодно, тільки мишкою. Тайлінг взагалі-то цінується в студії, для його виконання за допомогою мишки зроблено багато зручностей.

          Порівняння файлів можна робити (якщо це нова і стара версія) по пункту в контекстному меню, куди можна приписати будь-яку програму (у мене WinMerge).

          Шорткатів безліч, але як і у випадку віма, можна звикнути.

          Єдине що, студія повільна, після того як її переписали на .NET

          danbst

          Лютий 16, 2012 at 19:36

  2. Вау, тут майже почався IDE-срач. Як мило! 🙂

    Vim незвичний своїм інтерфейсом, але так як на ввід тексту припадає найменша частина тексту, значить основним режимом повинен бути не режим вводу тексту, це логічно. Те що він модальний дозволяє зменшити кількість необхідних розтяжок пальців. Він офігенний тим, що будь-яка мислима операція з текстом знаходиться на кінчику пальців. Але аби його таким зробити, його треба полірувати роками. От зараз я думаю як би то розібратись з python-rope, і прикрутити його. А також як би створити репозиторій на github з його конфігами, аби без зайвого гемору синхронізувати той Vim що в мене на роботі, і той що вдома.

    Visual Studio офігенна тому, що Майкрософт таки подбав аби розробляти під Windows було не гірше ніж під Unix-и. Вкладки там точно є ще з шостої версії. Буфери – не знаю, не бачив. Плюси студії в тому, що вона підтримує IntelliSens і переходи по коду з коробки. Ну, і ще там є Resharper – штука про яку навіть в шедеврі жанру nerdcore розповідають:

    when I write my raps
    never use a marker
    constantly refactor
    like I’m using Resharper

    Smixx – Developers

    bunyk

    Лютий 16, 2012 at 23:39

  3. […] такі справи з археологами. Взагалі сьогодні день перемоги, і вам напевне було б […]

  4. […] там у вас є, індекс для прискорення навігації по коду. Хороше IDE – головний інструмент програміста-археоло…. Також є інший софт, на зразок LXR (для читання коду Linux), […]


Залишити відповідь

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out / Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out / Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out / Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out / Змінити )

З’єднання з %s

%d блогерам подобається це: