Разработка самостоятельно

Ответ 1

Это очень сложное программное обеспечение самостоятельно, имея другого человека, чтобы отскакивать идеи, делает вещи намного легче/более удовлетворительными. Но, здесь кикер - что другой человек действительно не должен быть тем, что настроено на то, что вы делаете. Простое объяснение вещей кому-то еще часто дает вам представление о том, что вы делаете.

Раньше я работал с кем-то, кто рекомендовал "разговаривать с плюшевым" - например, забрать свою любимую игрушку (мистер Бинки), объяснить все эти новые API RESTful, над которыми вы работаете, мистеру Бинки. Похлопайте себя по голове, когда ослепительная вспышка вдохновения поражает вас - "гах, я знал, что мне нужен еще один ресурс, спасибо Бинкстеру!".

Имейте в виду, я не уверен в том, что коллеги рассуждают...

Для более обоснованного подхода вы не могли бы создать свободный союз с другим разработчиком, где вы отказываетесь от своих проектов друг от друга, даже если вы вернетесь к работе в изоляции?

Ответ 2

Не попадайте в ловушку, не документируя свой код! это, я думаю, один из советов, которые легко забыть, потому что, эй, вы сами написали, чтобы вы знали, что он делает, верно?... неправильно! просто поднимите один из ваших прошлых проектов и выясните, как все работает без какой-либо документации, это как чтение другого (плохого) кода.

Я всегда поощряю себя использовать стандартный стиль документации, такой как javadoc для java или эквивалент для .NET в коде, но на самом деле любая документация лучше, чем никто...

Ответ 3

Я много лет работаю самостоятельно. Сначала в составе группы инженеров-механиков. Теперь о моих собственных проектах. Я согласен с ответами выше:

Поговорите с кем-нибудь (кем-нибудь) о том, над чем вы работаете. Моя жена быстро оглядывается, но она пытается задавать уточняющие вопросы. Обычно вопросы не имеют смысла, но я притворяюсь, что она мой босс и все равно отвечает им. Я нахожу все виды решений таким образом.

Методы разработки в основном завышены для команды из 1 человека. Однако я принял пару гибких практик. Во-первых, оценивайте все в небольших кусках времени не более полудня. Во-вторых, сломайте свою работу на небольшие "спринты" трех или четырех недель. Я использую FogBugz для всех своих оценок и составления расписания (там есть бесплатная версия для групп 1-2 человек).

Не забывайте о необходимости документации кода, управления версиями и модульного тестирования. Я использую Doxygen, Subversion/TortoiseSVN и NUnit соответственно.

Ответ 4

Используйте управление версиями, всегда оставляйте день с компиляцией кода как минимум и всегда проверяйте. Я много лет работал в относительной изоляции в более крупной организации, я, естественно, применял то, что чаще всего называют технологиями разработки Agile. Получите что-то работающее независимо от того, насколько грубо, рефактору и повторите.

Сохранение стабильного состояния помогает много, это означает, что когда вы можете взаимодействовать с кем-то, у вас есть что-то, что нужно продемонстрировать, а не с набором идей и абстрактных понятий.

Я бы согласился, что "Прагматический программист" - отличный читатель.

Ответ 5

Большая часть большинства методологий фактически определяет, как вы можете работать вместе как команда. Большая часть гибкого/экстремального программирования и т.д. - это общение, настройка командной среды и многое другое. Если вы работаете в одиночку, некоторые вещи проще, и некоторые вещи (например, парное программирование) сложнее.

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

Ответ 6

Отъезд Тест Joel. Реализация этой практики как независимого разработчика была полезной задачей.

Ответ 7

Я думаю, что большинство "полномасштабных" методологий развития, таких как xp и т.д., направлены на то, чтобы направлять и рационализировать общение между членами команды.

Если вы развиваетесь в команде "одного человека", нет никакой пользы, которую можно было бы делать при ежедневных совещаниях по схватке и таких с самим собой;-) Таким образом, этого должно быть достаточно, если вы придерживаетесь некоторых лучших практик, таких как "использование контроля версий" и т.д. Книги "Прагматический программист" и "Корабль!" может дать вам хороший обзор некоторых практик, заслуживающих внимания, если вы работаете в команде или в одиночку. По крайней мере, сделал это для меня.

Чтобы быть понятным, вам понадобится какая-то структура или план для вашего проекта. Прежде чем начинать кодирование, но что-то вроде простого списка дел и исходного эскиза планируемого программного обеспечения.

Ответ 8

Когда я работал разработчиком ссуды, я использую XP, в сочетании с Джоэлем, который делает вещи, когда вы только грубая статья, чтобы держать меня на прямой и узкой.

я рассматривал это как упражнение для обучения, которое я мог бы интегрировать в команду, если бы я мог доказать, что применение "лучшей практики" имеет хорошую рентабельность инвестиций. который, хотя он дается хорошим разработчикам, все еще должен быть доказан; по крайней мере, по моему опыту.

Позже я использовал настраиваемый гибкий процесс, который лучше соответствовал политике компании, в которой я работал.

Ответ 9

Если вы чувствуете, что практика не оптимальна, и есть другие, которые чувствуют то же самое, почему бы не начать сотрудничать немного? Если ваша компания особенно странна и не хочет, чтобы разработчики учились друг у друга, я думаю, что вы должны серьезно относиться к альтернативной работе: вы, вероятно, не будете лучшими в такой среде.

Теперь, когда я сделал предложение о том, что вы задаете неправильный вопрос;) есть хорошая отправная точка для гибкости сольного разработчика на C2 Wiki

Ответ 10

@reefnet_alex

Вы абсолютно правы - процесс артикуляции, даже если это для вас или игрушечной игрушки, замечательно для размышлений. Лично я печатаю блог-подобный монолог в файле, пытаясь что-то сделать. У этого есть дополнительный бонус, чтобы иметь возможность вернуться к нему, когда мне нужно.

Что касается других стратегий, я считаю, что лучше всего поддерживать список TODO. Если я застрял на одном, я просто перейду на что-то еще в списке задач.

Ответ 11

@Kyle

Старые объясняют это себе через заметки в файле rous eh? К моему ужасу я видел этот комментарий в верхней части моего старого кода на днях:

/*
    bloody hell - where to start...
*/

Ответ 12

Когда вы единственный, кто работает над проектом/проблемой, общение должно быть хорошим, поэтому формальности для этого не нужны. Однако, как упоминалось в других сообщениях, по-прежнему применяются передовые методы, такие как контроль версий. Отказывание идей от кого-то тоже оказалось для меня критическим.

Хотя общение не является проблемой при работе в одиночку, я нашел полезным в некоторых случаях использовать post-it и сделать персональную сессию. Недавно я перешел из компании, которая была ориентирована на команды на ту, что находится далеко от нее, и это сложный переход.

Еще одна мысль по пути того, как прийти к решению... книга Conceptual Blockbusting содержит несколько хороших замечаний о том, как лучше проблема решить.

Ответ 13

Я задал аналогичный вопрос до, вы можете найти там хорошие ответы.

Ответ 14

Я бы предположил, что, используя SCM, используйте трекер проблем. Даже при том, что вы можете потратить немного больше времени на добавление в то, что нужно сделать, оно дает конкретную запись о вашем прогрессе в более легком формате, чем изменения в вашем контроле версий.

Он также дает вам теплые пушистики, когда вы пересекаете вещи из своего списка. Я рассматриваю это как расширение списка TODO.

Ответ 15

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

Ответ 16

Большое спасибо за советы:

• Я пытаюсь документировать свой код настолько, насколько могу, используя общие стандарты. Я пытаюсь вспомнить бедного парня, который, возможно, когда-нибудь придет и должен будет поддерживать мой код (кто знает, может быть, этот парень может быть мной!).

• Я использую источник управления. Это обязательное для меня, и я просто не могу работать без него.

• Единичное тестирование (разве это не третья пилар?)... Ну... я вообще ничего не тестировал:( и это одна из вещей, которые я хотел бы изменить для будущих проектов.

• Когда я рисую, я стараюсь записывать все свои внутренние мысли (это более или менее похоже на разговор с твоим плюшевым, не так ли?).

• У меня также есть список TODO. Интересно, есть ли какое-то приложение (или веб-приложение), чтобы лучше контролировать все эти задачи.

Я рассмотрю некоторые из современных методологий и попытаюсь включить некоторые методы в свою собственную методологию. Это кажется действительно интересным.

Теперь я также думаю об установке Cruise Control на моей машине, но это действительно стоит для меня?

Ответ 17

Персональный программный процесс