Методології / інструменти для розробки самостійно [закрито]


10

Припустимо, ви повинні розробити програмне забезпечення середнього розміру + повністю самостійно. Як би це був особистий проект, який ви хочете здійснити.

Які методології / інструменти ви б використали для визначення того, що потрібно розвивати, вивчати та мати глобальне уявлення про те, якою є система, а також у її деталях?

В основному, щоб слідкувати за собою і не загубитися на шляху.


3
Олівець, папір і мій мозок. Наявність дошки допомагає. Якщо серйозно, велика частина моїх дизайнерських робіт відбувається саме в IDE. Чи є у вас конкретне питання, виходячи з проблеми, з якою ви стикаєтесь в даний час? Це допоможе нам відповісти на питання, якби ми конкретно знали, яку проблему ви намагаєтеся вирішити.
Роберт Харві

@RobertHarvey haha ​​Це дуже правда. Ну, начебто. Я розробляю свою ідею, особистий проект. Просто програмне забезпечення буває більшим, ніж я уявляв, і є речі, які я все-таки повинен дізнатися, як це працює, і тільки потім з'ясувати, як це розвивати.
Кассіо

1
@RobertHarvey Основні проблеми, ймовірно, відсутність мозкового штурму на деталях, відстеження того, що потрібно зробити, та погляду на систему в цілому.
Кассіо

2
Я на 99,9% впевнений, що ми говоримо про це в іншому запитанні, але наразі не можу їх знайти.
Адам Лір

4
Я завжди намагаюся загубитися в дорозі. Це швидкий шлях до навчання.
Джоель Етертон

Відповіді:


5

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


Yup - Mercurial - це один із тих інструментів, які здаються, що їх зробив Apple :) Простий, але потужний, красивий, але корисний ...
Rook

4

Це може легко вирости поза досяжності вашої уваги. Не проліт , ширина .

Важко врахувати занадто багато елементів одразу .

А потім ... він стає регресійним гіркою .
Все, що ви робите, порушує попередні речі, а відкат назад не допомагає.

Щоб уникнути цього, слід агресивно перевіряти регресію .
Автоматично. (Ви не можете цього зробити і будьте здорові)

Тестування додасть вашої енергії напруження.

Якщо проект стосується інтерфейсу користувача, ви, мабуть, тости:

  • Тестування інтерфейсу є важким .
  • Автоматизоване тестування користувальницького інтерфейсу ... все ще важко .

Неперевірена в останні хвилини ідея для проектів, орієнтованих на користувальницький інтерфейс,
Запишіть родича з вільним часом та прихильністю клацати мишкою як тестер користувальницького інтерфейсу.
Я тут думаю "підліток" .

Інші питання:

  • Пройде вічно .
  • Ви будете протистояти блоку письменників .
    (Це насправді не існує як умова, це популярні люди, котрі неправильно позначають свою недисципліну )

Якщо ви звикли і любите якийсь контроль версій , використовуйте його.
Початок навчатись зараз відволікатиме вас .

Як вже зазначалося, графіки ваших ідей можуть допомогти.

Я використовував Freemind , CMaps , XMind , yEd , graphviz та… щось інше.

XMind менш безглуздий:

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

Олівець та зошит все ще дуже добре оцінюються у моїй першій десятці:

  • Я сканую багато своїх заміток
  • Я роблю багато маленьких пояснювальних малюнків.

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

В крайньому випадку, ви завжди можете підготувати пункти живлення для власного споживання :)


+1. Однак, чи є у вас якісь пропозиції щодо того, щоб "вирішити щось, чого ви там не зрозуміли"?
Кассіо

@Cassio Я перемикаюся вперед і назад між xmind і олівцем + ескізною книжкою, складаю загострені списки у вільному доступі, записую приклади та перевіряю деяку приблизну реалізацію. Це досить трудомісткий процес, але вам доведеться відірвати деяку неправомірну лінію думки, щоб дійти до того, що відчуває себе правильно. (PS: обсипається папір перед тим, як кинути це катастрофічно)
ZJR

1
@ZJR Дійсно. Іноді я просто боявся писати речі, які мені не потрібні, і витрачав на це час, але зараз я бачу, що так працює процес. Спочатку ми пишемо деякі непотрібні речі, але з часом вдосконалюємось. :) Дякую!
Кассіо

3

Грамотне програмування.

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

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

Почніть з контуру того, що ви робите: використовуйте огляд справ, випуск 1, випуск 2, звільнення n. Запишіть резюме випадків використання. Поставте їм пріоритет. Вставте їх у спринти та релізи.

Кожен випуск має вигляд випадку використання, логічний вигляд, перегляд обробки, перегляд компонентів, вигляд розгортання. Для спринту детально описати випадки використання. Опублікуйте документ HTML, щоб показати, що ви збираєтеся робити. Докладно описуючи випадки використання спринту, напишіть логічну модель. Напишіть код, щоб підтримати це. Напишіть документацію по обробці. Напишіть код для його підтримки. Створення модулів. Напишіть документацію щодо перегляду компонентів. Напишіть тести та супровідну документацію. Опублікуйте результати спринту у вигляді документа HTML.

Повторіть для кожного спринту. Час від часу переглядайте та редагуйте документ.

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

Я використовую сфінкси та PyLit, але це тому, що я програміст Python.


Добре розчавити з нього університетський папір , а потім забути про нього, погано, якщо згодом плануєте випустити або доглядати за продуктом. Усі скрізь повинні використовувати доксиген , навіть на пітоні. Але це лише тому, що я фанат :)
ZJR

2

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

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

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


Дуже добре. Я вже тестую все це. Дякую!
Кассіо

2

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

Я працюю над особистим проектом так само, як ви описали. Я використовую Git, Redmine, JUnit та Jenkins, щоб задовольнити всі описані нами категорії. Мій робочий потік:

  • Виберіть квиток для роботи
  • Розгалуження кодової бази
  • Розробіть код і тести для завдання (введіть зміни до гілки в хороших точках збереження)
  • З’єднайте гілку назад до стовбура
  • Переконайтеся, що збірка була успішною, тести пройшли і інших проблем не було
  • Повторіть

Дотримуватися всього керованого та організованого так само важливо, як і коли існує багато розробників. У багатьох розробників вам потрібно організувати, щоб інформація поширювалася для всіх. Коли це лише ви, у вас вже є вся інформація, але запам'ятати кожну частину системи важко. Керована система полегшує вас, і ви можете зосередитись на заданні.


2

Інструменти:

  • Система версій управління (навіть якщо ви єдиний розробник у вашому гаражі чи домашньому персональному ПК): GIT, Mercurial, Tourtoise

  • Редактор з виділенням вихідного коду, навіть якщо у вас є IDE (Scintilla, Vim, Notepad)

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

  • Інструмент дизайну: Rational Rose, Umbrello, (UML, ER,) Visio або "Інструменти дизайнера бідних розробників", такі як Power Point, Corel Draw, Open Office Draw

  • Текст / вихідний код Засіб порівняння тексту, наприклад, WinMerge


Дуже корисний! Я все це втілю в життя. Дякую.
Кассіо

1

Це залежить від того, як ви можете розрізнити та впоратися з різними завданнями, адже вам потрібно буде ознайомитися з кожним етапом процесу розробки.

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

По-перше, на мою думку, ви повинні записати, що ви очікуєте, що це буде робити програмне забезпечення, а саме те, що воно не буде робити. Це вирішальний момент. Наступним кроком є ​​поділ кінцевої системи на нижчі підсистеми, що полегшує процес побудови. І останнє, але не менш важливе, вам потрібно буде вибрати свої інструменти. В основному хороший IDE, VCS та модельєр даних. Ви можете додати безліч інших інструментів, щоб допомогти, але слідкуйте за тим, щоб не почати неправильно.

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


Ага! Пам'ятайте, що код - якщо проект добре розроблений - це невелика частина цілого.
Лукас Маус
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.