UProLa

Неокріпші думки

Нова нав’язлива ідея – Підтримка проекту

with 11 comments

Піднімемо питання maintainability коду. Або по нашому – “Який код легше підтримувати на протязі тривалого терміну”. Як правило, обговорення цього питання завершуються дуже швидко посиланнями на “авторитетного автора” або на “власний досвід”. Проте, це відповідь дилетанта, а нам (мені, цебто) потрібно щось більш конкретніше.

Зауважу, що проблемне поле не є цілиною, тобто, люди уже давно ставлять експерименти по підтримці коду. Фредерік Брукс, для прикладу, уже давав певні оцінки, а в наш час люди типу <a href=”http://www.dawis.wiwi.uni-due.de/team/stefan-hanenberg/”>Stefan Hanenberg</a> займаються <a href=”http://en.wikipedia.org/wiki/Experimental_software_engineering”>Empirical Software Studies</a>, як одним з методів аналізу мейнтейнабіліті та швидкості розробки.

Я в свою чергу пропоную ще один підхід (можливо він уже описаний десь). Він базується на наступному алгоритмі:
1. Складається мінімальне завдання (ТЗ), яке неважко виконати, проте воно може відображати складність проекту або його частини.
2. Складаються форки завдання. Форк завдання – це якби “завдання на доробку”, потенційна ситуація, що станеться в процесі підтримки коду.
3. Завдання анонсується піддослідним, незалежним, командам розробників. Потрібно його зробити, включно з форками завдань. Ключовою складовою є “не робити більше, ніж проситься в завданні, і при цьому повністю відтворювати функціонал”. Фактично, пункт 3 імітує процес “підтримки коду”.
3.1 Одна частина команд повинна виконати завдання як бажає, будь-яким методом
3.2 Друга частина команд повинна виконати завдання за мінімальний час
3.3 Третя частина команд повинна виконати завдання з максимальною оптимізацією
4. Після завершення першого етапу, кожна команда модифікує свій код для мінімізації наступних параметрів
– сумарна кількість рядків у всіх diff виконаних форків і оригінального завдання
– кількість рядків оригінального завдання, без фанатизму
Фактично, від кожної команди ми отримаємо приклад “ідеально легко-підтримуваного коду”
5. Зворотній зв’язок – модифікація ТЗ, пропозиції нових форк-завдань
6. Аналіз кращих представників коду, селекція у фінальну ітерацію
7. Видача новим командам цих відібраних зразків коду (тільки оригінал! форк solutions не даються) і завдання виконати всі форки.
8. Селекція нових кращих представників коду (селекція по швидкості виконання завдань всіх форків окремою командою)
9. Аналіз цих представників коду – які структури даних використовуються, які алгоритми, як організовано код, на якій мові все це написано, які технології використовуються, середня швидкість виконання одного завдання, оптимальність роботи. Показник “maintainability” буде автоматично максимальним, оскільки саме для його максимізації і виконувалися всі 8 кроків.

Щоб вам легше було представити цей процес, приведу приклад. Нехай в якості оригінального завдання вибрано “написати Тетріс”. Проект на основі цього завдання буде в певній мірі репрезентувати наступні класи задач: відео-гра, інтерактивна програма, простий проект. Я вже спробував описати мінімальний тетріс, ось цей опис:
– кросплатформенний
– консольне поле, повна перемальовка екрану (тобто, GotoXY використовувати не можна)
– фіксований розмір – 10 * 12 блоків, обмежений границею з одного символу ‘*’
– розмір блоку – одиничний символ ‘#’
– управління вліво (h), вправо (l), поворот за годинниковою стрілкою (Space), вихід (q)
– швидкість падіння фігури – 1 блок в секунду
– знищення заповнених ліній
– результат виводиться після завершення гри як число заповнених ліній
– поворот фігури неможливий, якщо в результаті виникне перетин або вихід за межі поля
– автовихід, якщо поле заповнилось доверху

В якості форків використовуються такі завдання:
– додати параметризацію (налаштування)
— через параметри командного рядка
— через конф. файл заданого формату
— через XML-конфіг
— в якості параметрів параметризації вибрати розмір поля, розмір блоку, клавіші управління, швидкість падіння
– додати лог статистики
– переписати відображення через
— curses (втрата кросплатформенності)
— SDL
— DirectDraw (втрата кросплатформенності)
— OpenGL
– зробити кожну падаючу фігуру кольоровою (на вибір з 16 кольорів)
– додати рівні: кожні 10 заповнених ліній збільшуйть рівень. Від рівня залежить швидкість падіння
– додати обгортку гри: гейм-менюшку, паузу, вибір профілю\користувача
– додати анімований фон
– додати кнопку швидкого падіння
– зробити анімацію знищення заповненого рядка і щоб був слоник біля поля і він стрибав, коли заповнюється 10-ий рядок.
– зробити так, щоб фігури підлягали гравітації 9.8 і відбивались (пружно, але вполовину) від нижньої межі
– зробити так, щоб замість квадратиків використовувались трикутники або шестикутники
– зробити так, щоб … тут ваші фантазії, яким повинен бути або не бути тетріс

Чим більше буде придумано завдань, тим більше можна буде говорити про адекватне моделювання реального розвитку проекту. Мінімальне дерево розвитку коду (щойно придумав) обов’язково буде щось та й означати, бо будь-що мінімальне має цю властивість. Тетріс – це всього лиш приклад, існує багато (скінченна кількість) класів задач, мінімальне дерево розвитку котрих зможе репрезентувати must have букет технологій та алгоритмів. І це неодмінно зможе бути використаним проти начальників, котрі вважають, що Сонце рухається навколо Землі.

Проблеми? Звісно, мільйони їх
1. Чи потрібне це комусь? Всі знають, що потрібно використовувати, мейнстрім уже сформований, хороші аналітики або девелопери з досвідом замінять всю твою ідею.
Відповідь: це науковий підхід до проблеми, а не експертний. Він ТОЧНО буде комусь потрібний, саме через його научність, а хороші аналітики та розробники можуть сумарно витягнути більше коштів, ніж грамотно спланована серія експериментів по maintainability
2. Цей параметр (maintainability) не є важливим при проектуванні проекту.
Відповідь: так, він не є критично важливим, проте аналіз мінімального дерева розвитку допоможе закласти правильно основу проекту.
3. Таку велику кількість квалфікованих розробників для постановки експерименту знайти неможливо!
Відповідь: взагалі-то так. Проте ідея, активна реклама та грамотна реалізація можуть зробити своє діло.
4. Даний підхід не підходить до алгоритмів, тому не запрацює і тут.
Відповідь: алгоритми справді неможливо оцінювати по цій методиці, тому що параметр “підтримка” для них немає змісту. Тільки проекти з великою кількістю зв’язків можуть отримати певний виграш від статистичного аналізу та селекційного відбору.
5. Дана методика репрезентує тільки доробки нового функціоналу, але не виправлення помилок.
Відповідь: так, помилки не будуть брати участь у історії селекцій. Проте в проекти на фінальній стадії селекції можна вводити зумисні помилки, і тоді форками будуть завдання на виправлення цих помилок.
6. Створення коректного завдання складніше ніж реалізація проекту.
Відповідь: реально найскладніша до вирішення проблема. Іншою схожою проблемою є тестування на відповідність завданню, робити це вручну може бути неможливим через велику кількість різноманітних проектів та параметрів. Методи автоматизації, юніт-тестингу, віртуалізації, симуляції та перевірки інваріантів справді повинні показати всю свою силу на даній задачі.
7. Централізація цього діла є must have (розробників не так багато, щоб розділятись), але тоді ми не зможемо говорити про “незалежність” результатів – буде всього лиш ще один “авторитет”.
Відповідь: можна централізувати тільки збір даних. Аналіз та інтерпретація даних виконується сторонніми групами науковців.

Основна моя думка наступна – якби це вже існувало на даний момент, я би обов’язково глянув на вибрані проекти у фінальну селекційну стадію, для розвитку своїх навиків проектанта. А поки-що я можу тільки мріяти і читати подальші баталії Haskell VS Python VS .NET VS Java, Ratpoison VS Ion VS xmonad VS KDE VS Gnome, битва за кращий спосіб зчитати XML-ку та безліч інших холіварів, де наразі існують тільки релігійні погляди без наукового підходу.

Written by danbst

Квітень 2, 2012 at 22:46

Оприлюднено в Програмування

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

Subscribe to comments with RSS.

  1. Тобі точно варто прочитати Deadline ДеМарко. Там не зовсім про підтримку, а про розробку, але ідея подібна.

    bunyk

    Квітень 3, 2012 at 07:56

    • А можеш викласти, яка саме ідея подібна? Читати цілий роман про управління немає часу.

      danbst

      Квітень 3, 2012 at 12:11

      • В романі шпигуни якоїсь пострадянської країни викрадають крутого проджект-менеджера, аби він зробив їх країну лідером з випуску програмного забезпечення. Йому дають > 1500 випускників КПІ. І п’ять проектів. Він каже, хм, на один проект 300 людей забагато. Давайте поділимо кожну команду ще на три і нехай вони користуються різними методологіями…

        bunyk

        Квітень 8, 2012 at 16:58

    • Присоединяюсь, хорошая книга.

      Александр Щапов

      Квітень 8, 2012 at 18:19

  2. До речі, це дорого. І чим більший проект – тим дорожче.

    bunyk

    Квітень 8, 2012 at 17:00

    • Ну я сподівався все покласти на плечі Open Source … Але так, дорого. Питання, чи окупиться?..

      danbst

      Квітень 8, 2012 at 17:09

  3. Вообще я не увидел, чтобы ты учёл, насколько разные уровни бывают у исполнителей-кандидатов. Т.е. фактически, “идеальный код”, которы

    Александр Щапов

    Квітень 8, 2012 at 17:55

    • й ты вывел в своей теории будет, как следствие, довольно сложен и неочевиден, и, в свою очередь, не сможет быть, во время поддержки оставаться именно таким. Т.е. каждый программист, даже есть будет следовать результатам “идеального гайдлайна”, будет неким образом интерпретировать эти рекомендации и писать свой код. Постепенно результат будет уходить все дальше и дальше от идеального прототипа.

      Ещё — ввести человека в работу по такой системе — очень дорого.

      Александр Щапов

      Квітень 8, 2012 at 17:58

      • Саме тому присутня “фінальна стадія”, де зроблений одною групою девелоперів код дається іншій, незалежній групі. Якщо перша група писала код “по-своєму”, то “добре” це чи “погано” – скаже друга група.

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

        На рахунок “дорого” – тому і вибираю простий проект – день-два роботи над основним завданням. Достатньо моделі, а не реальної системи.

        danbst

        Квітень 8, 2012 at 18:06

  4. > 1) якщо, наприклад, якось записувати процес написання коду проекту (наприклад, посимвольно), чи має ця “історія” якусь практичну цінність (наприклад, в якості туторіалу новачкам)?
    Я думаю, лучшим ответом на этот вопрос будет написание документации по проекту. Именно её очень часто не хватает, да и вообще, именно написание документации то, что менее всего любят программисты. От этого она аутдейтед, что ещё хуже, отнимает море времени у новичков.
    Тем не менее, я согласен рассмотреть твой вариант записи истории. Скажем так, пусть, в каком то приближении, это будет история комитов. Т.е. есть некоторые ветки развития, есть некоторые клюевые комиты, с которыми предлагается ознакомиться новичку перед тем, как начать работу. Так вот, в большом проекте количество таких комитов будет неверотяно большим.

    > 2) якщо зробити під цю ідею вебморду (типу хабра), чи будуть люди намагатись писати проект в рамках експерименту по “підтримці проекту”? Чи зробив би це ти? якщо ні, то чого не вистачає?
    Здесь ты сразу полез в практику, но, боюсь, теория ещё слишком сыра в настоящий момент, и я не вижу варианта, когда такое будет работать. Рано думать про веб-морду и способ.

    > 3) чи будуть люди в рамках експерименту брати участь “у фінальній стадії” – вирішувати завдання на швидкість по готовому проекту? Чи робив би це ти? Якщо ні, то чому?
    Да, я бы принял участие, да и народ бы принял, по той причине, что всем интересно, какой именно код лучше всего и быстрее пишется. Я хочу, чтобы ты принял во внимание ещё один момент. Как и в других случаях, скорость и качество всегда находятся на разных полюсах, в итоге, от такого перетягивания одеяла, даже если оно будет происходить по теории, результат может быть хуже, а не лучше. Скорость — не всегда качество. И, самое печальное, количеством людей не исправить ситуацию, потому что, как писал тот же Брукс, с увеличением людей время сокращается только до определённого момента, после чего начинает наоборот падать.

    > 4) чи є тетріс достатньо складною задачею, щоб хоч якось відображати розвиток великого проекту? Яка ще задача може бути поставлена?
    Возможно я не очень понял тебя, но, на мой взгляд, хотя ты и утверждаешь, что количество таких прототив конечно, в настоящее время, для каждого отдельного большого проекта будет необходимо делать такой прототип. Это будет первой версией, и, если следовать твоей теории, очень дорогой версией.

    > 5) чи буде результат фінальної стадії розвитку проекту (тобто, мінімізований) представляти якусь цінність? Тобто, чи можна буде, дивлячись на цей код, робити певні конструктивні висновки?
    Я думаю, суммарное количество полезного, т.е. выводов, которые можно будет выбрать из такого проекта будет небольшой. Гляди, во первых, если та же команада, будет во второй раз писать тетрис — то да, скорее всего, результат по науке будет совпадать с фактом. Но в реальности, проект, скорее всего будет совсем другой, а в силу его возможной сложности, многие выводы вообще невозможно будет перенести на другой проект. В итоге: количество сил и ресурсов, которые затрачены на эталонный проект, будут скорее всего неоправданно высоки.

    Александр Щапов

    Квітень 8, 2012 at 18:17

  5. 2) нажаль, вебморду і спосіб я уже придумав =)

    3) єдине, що показує швидкість, – наскільки новій групі ЛЕГКО було в’їхати у чужий проект і його допилювати (ситуація: компанія найняла багато нових програмістів, і саме від швидкості введення їх у роботу залежить успіх проекту). Якщо швидко розвивати старий код не виходить, значить з ним щось неправильно, значить вектор розвитку було прийнято неправильно ще при старті.

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

    5) див 4.

    >>> В итоге: количество сил и ресурсов, которые затрачены на эталонный проект, будут скорее всего неоправданно высоки.

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

    danbst

    Квітень 8, 2012 at 19:00


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

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

Лого WordPress.com

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

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

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