Как организовать разработку программ?

Каждый разрабатывает программы по-разному. Хотелось бы узнать — а есть какие-то методы/приемы в комплексе — как работать в команде, как писать тесты, какой трекер использовать, как работать с GIT (в смысле как часто коммитить, как много, как описывать), как оптимально настроить emacs/vim под кодинг, например с Python, какую DE лучше взять для кодинга (XFCE или Xmonad).

В общем куча вопросов относящихся к приятному и эффективному кодингу. Каждый решает для себя сам, или таки есть какие-то методы, приемы, советы, как это все должно быть в комплексе? Что-то типа ISO/ГОСТ/RFC для организации кодинга.
  • Вопрос задан
  • 2985 просмотров
Пригласить эксперта
Ответы на вопрос 4
@sswz
Мы как раз сейчас внедряем методики Agile, конкретно Scrum.
Пока конечно плохо получается, но во всяком случае бэклог вести уже начали и программисты без дела сидеть перестали…
Ответ написан
@mithraen
1. Как писать автотесты — зависит от средств разработки. Скрипты на perl, десктоп приложения на Qt, и серверные приложения на Java тестируются, очевидно, по-разному.

2. Как делать описания тестов (для тестировщиков) — для этого нанимается опытный тестировщик, который сам все объяснит.

3. При работе с git — коммитить желательно отдельными логическими изменениями. Желательно перед коммитом проверять компилируемость. Не стоит крупные изменения делать одним коммитом, лучше разделять — вот сделали подсистему, вот мы ее используем в этом модуле, вот — в другом. Если какая-то функциональность развивается долго параллельно другой деятельности — git rebase позволит команде которая занимается этой подсистемой синхронизироваться с остальными, но не отправлять свои изменения пока не закончит работу. А потом отправить сразу группу коммитов.

4. Как настроить среду на кодинг — я не думаю что получится установить это как стандарт. У каждого программиста свои привычки. Идеальной настройки emacs/vim не существует.

5. По поводу DE — я лично фанат xmonad. Многие tiling WM не выносят, и для них он не подходит. Я не понимаю почему — но это факт. При найме программиста мне важно как он пишет код, а не какой window manager использует.

6. Тут вот какая штука — в Linux легко организовать миграцию конфигов. Так что даже при использовании парного программирования элементарно обеспечить чтобы каждый работал с привычной ему средой.

Стандартизировать надо не window manager, а требования к оформлению кода.
Возможно даже используемые в интерфейсах цветовые схемы и шрифты — чтобы при парном программировании люди глаза не ломали. Но и тут я бы поостерегся, а скорее предоставил возможность людям тратить некоторую часть рабочего времени на тюнинг. Тогда они будут интересные идеи по настройке рабочего места утаскивать друг у друга. Результат будет лучше чем любой стандарт.
Ответ написан
@s0rr0w
Вообще тут нет одного стандарта или супер-приемов, которые де-факто являются эффективными. На процесс разработки могут влиять множество факторов, как то особенности организационной структуры компании, особенности модели продаж, харизма или опыт руководителей, опыт и слаженность команды разработчиков, методика разработки, языки программирования и особенности продуктов, которые разрабатываются. Перечислять можно долго.

Лично я бы выделил два основные правила во всем этом:
1. Не принимайте ничто в своих моделях за аксиому. Это значит, что если что-то эффективно работает сегодня, то не значит, что через год это будет работать столь же эффективно. Постоянно улучшайте позитивные решения и избегайте негативных. Например, если сейчас вы коммитите со скоростью пять раз в день, то это не значит, что через год такой темп будет востребован.
2. Экономическая эффективность разработки — вот о чем стоит думать каждый день. Все принятые решения должны быть именно экономически эффективными. Например, вы можете отказаться от отной технологии или программы в пользу другой, только бы росла скорость разработки, падало количество ошибок в коде, качество кода росло, количество времени на исправление ошибок было минимальным, и так далее. Фактически, нет разницы, в какой именно программе вы работаете, особо не важно, на каком языке, как часто вы делаете коммиты и что пишете в комментарии, важно, чтобы вы не загрузли со всем этим, отвлекаясь на красивые пассажи и реверансы, хотя нужно просто написать код. Решать проблемы нужно по мере их возникновения. Например, мы провели множество смен ПО багтрекинга и постановки задач, сейчас ими пользуемся настолько редко, что можно сказать, что оно вообще у нас отмерло. И это не мешает нам контроллировать процесс и вести успешную разработку. Инструменты должны быть эффективными, а это возникает только тогда, когда есть опыт их использования. Инструмент сам по себе не поможет, иногда даже навредит.
Ответ написан
yuriykulikov
@yuriykulikov
Имхо, главное это не Scrum или Agile, а правильный подход к проектированию. То есть сначала тщательная проработка архитектуры, рисование всевозможных схем, написание документации. И только потом приступать уже к кодингу.

Если проект маленький, то можно обойтись и без багтрекера. В Git лучше коммитить часто на локальной машине, а перед push делать squash в несколько коммитов.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы