Каковы некоторые сольные методологии программирования разработчика? [закрытый]
Быстрее было бы написать ...
in = open('path/to/input/file').read()
out = open('path/to/input/file', 'w')
replacements = {'zero':'0', 'temp':'bob', 'garbage':'nothing'}
for i in replacements.keys():
in = in.replace(i, replacements[i])
out.write(in)
out.close
Это исключило множество итераций, предлагаемых другими ответами, и ускорит процесс для более длинных файлов.
9 ответов
Практически любая методология разработки будет работать в индивидуальной среде, за исключением тех, которые явно требуют команды (например, параллельное программирование). Но даже тогда вы могли бы обойти это, просто создав воображаемых друзей / товарищей по команде или развив расстройство множественной личности.
На ум приходит методика «резиновая уточка»: http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html
Даже будучи индивидуальным разработчиком, вы можете использовать методологии, применяемые к большим командам разработчиков.
- Написать спецификацию.
- Разметить UML.
- Сделать дизайн пользовательского интерфейса на бумаге.
- Коридорное тестирование: если вы ожидаете большая толпа, спросите маму, легко ли им пользоваться.
- Экспертная проверка: вы можете создавать специальные группы проверки с другими индивидуальными разработчиками.
- Держите в актуальном состоянии расписание.
- и так далее ...
Я постоянно развиваюсь в одиночку, и эти практики позволяют мне придерживаться моей собственной работы и дают моим боссам отличный ресурс, чтобы узнать, что я сделал и как далеко я продвинулся. И они держат меня в курсе!
Многие agile-методы отлично работают в одиночку:
- Опросы и истории с пользователями: Если вы не знаете, чего хотят ваши пользователи, почему ваше программное обеспечение может быть полезно?
- A простая спецификация: Или даже просто заявление о миссии. «Пусть люди рассылают короткие сообщения своим спискам подписчиков». «Использование степени для сортировки результатов поиска в Интернете». «Позвольте людям совместно ответить на вопросы по программированию». Как бы то ни было.
- Строго упорядоченный список дел: Помогает не утонуть в мыслях.
- Журнал касательных: В хорошем списке дел есть компонент, который нельзя делать, так что вы не зацикливаетесь на том, что не собираетесь делать (пока).
- YAGNI: Оставайся на цели. Это очень важно, когда вы работаете в одиночку, потому что никто не скажет вам «Нет! Не изобретайте динамическую типизацию в Java заново! Вернитесь к проекту. " Список дел, которые нельзя делать, поможет с этим.
- Разработка через тестирование: Написание тестов заставляет вас думать о конечном результате, а не увязнуть в деталях реализации . В любом случае вы достаточно увязнете, не нужно усугублять ситуацию.
- Частые выпуски: Придерживайтесь сроков. «У нас будет полнофункциональная версия, включающая пользовательские истории 1 -4 к пятнице. Он не подключается к сети и не сохраняет данные на диск, но XYZ ... "
- Пользовательское тестирование: Пусть ваши друзья смотрят, что вы делаете, довольно часто - может быть, раз в месяц. , может быть, каждую неделю, в зависимости от того, сколько у вас друзей и сколько пива / пиццы вы хотите их накормить. Обращайте очень пристальное внимание на то, что они говорят, делают и думают при использовании программного обеспечения.
И другие вещи, которые только кажутся имеющими смысл в больших проектах, могут очень помочь:
- Контроль версий: Установить ] git . Все просто. Используй это. Не зацикливайтесь на этом.
- Резервные копии вне сайта: Понимаете. В случае пожара или наводнения.
- Блог: Но вам разрешено писать туда только после выхода релиза. ;) Также поможет вам создать аудиторию для вашего продукта еще до того, как он будет выпущен.
Надеюсь, это поможет! Индивидуальное программирование в большом проекте может быть очень сложным.
Не зацикливайтесь на этом.Надеюсь, это поможет! Индивидуальное программирование в большом проекте может быть очень сложным.
Не зацикливайтесь на этом.Надеюсь, это поможет! Индивидуальное программирование в большом проекте может быть очень сложным.
Следуйте тому, что изложено в этом вопросе о переполнении стека:
Какие инструменты / методы могут принести пользу индивидуальному разработчику?
Также. Используйте систему управления версиями . Вы не поверите, сколько раз меня это кусало на личных проектах.
The issue is more a question of what you are comfortable with and what problems you hope to solve. Most methodologies are used by a solo developer at some point (pair programming is a notable exception). The issue is are you actually alone, or just working by yourself? I have found that it is invaluable to have people I can bounce ideas off of. Furthermore having someone else to look at you code (peer review) is a great way to find issues that you just cannot "see". So to agree with Aiden Bell "Programming on your oen is uncool." Я бы попытался подключиться к сообществу (например, SO), где вы можете передавать идеи другим. Затем вам нужно построить свою методологию таким образом, чтобы можно было отвлекаться, когда вы отправляете идею.
Есть ли в этом смысл? Почему ты программируешь один?
Пэт О
Это больше уловка, чем методология. Когда вы отлаживаете, объясните ошибки вслух, как если бы вы пытались объяснить это коллеге. Это кажется глупым, но если заставить себя сформулировать проблему вслух, часто можно понять, в чем проблема.
Не совсем официальная методология, но я много разрабатывал самостоятельно (независимый консультант и независимый поставщик программного обеспечения), и вот что я считаю важными:
- Найдите онлайн-организацию (например, oisv.com ) поделиться мыслями и idea
- Убедитесь, что у вас есть время на общение с реальными людьми в реальном мире
- Установите цели проекта, сроки и вехи
- Найдите время, чтобы сделать соответствующие предварительные дизайн и планирование проекта
- Выделите рабочее время, чтобы их
- Не работайте слишком много и не обожгитесь out
- Ничто не бывает идеальным, так что старайтесь для хорошего кода, который работает, а не совершенство
- Найдите себе хобби, не связанное с программированием