Comments 40
скромный опыт. жалких 6 лет программирования. Это ж не опыт даже, тьфу.
:)
:)
В любом случае человек поделился с огромным сообществом тем, что ему кажется полезным и правильным. И Вы знаете, я возьму на заметку многие советы, так как они действительно полезны. Раз вам это не нравится, давайте же, поделитесь с нами подобным опытом (вы же этим так давно занимаетесь, намного больше «жалких шести лет»).
Автор молодец, плюс ему за статью.
Автор молодец, плюс ему за статью.
Просто кто-то забыл табличку «сарказм».
ну я примерно это и имел в виду ) у меня опыта намного меньше и человек с 6-летним опытом кажется мне гуру. Поэтому я намекнул автору на излишнюю скромность в начале поста, не более того. пост мне и самому понравился. Загуглите Ч/Ю — офигенная вещь, в жизни всегда пригодится :)
Программист — это как хорошее вино. При приличных начальных данных лет через 6-8 его можно пить. Хотя, если изначально кислятина — ничего уж не попишешь.
Согласен, ерунда, а не опыт :) Кстати по зарубежным меркам это очень небольшой опыт, у них другие мерки :)
мне показалось интересным, вынес кое что для себя
Готов подписаться под всеми пунктами, но добавлю свой пять копеек
— относительно CI: Каждый день должна происходить не только сборка системы и прогон тестов но и автоматическая ее установка на доступный енвайронмент. Процесс деплоймента нужно тестить так же как и другие части системы.
— Также по кнопке нужно иметь возможность обновить установку системы на енвайронменте, используемом QA.
— Заказчик в любой момент времени должен иметь доступ к промежуточной версии системы. В частности если практикуются демонстрации раз пару недель (что кстати оч повышает результативность коммуникаций с заказчиком) то заказчик должен всегда иметь возможность «потрогать» то что было показано на последней демонстрации (линк если речь о веб, или файл инсталятора).
— относительно CI: Каждый день должна происходить не только сборка системы и прогон тестов но и автоматическая ее установка на доступный енвайронмент. Процесс деплоймента нужно тестить так же как и другие части системы.
— Также по кнопке нужно иметь возможность обновить установку системы на енвайронменте, используемом QA.
— Заказчик в любой момент времени должен иметь доступ к промежуточной версии системы. В частности если практикуются демонстрации раз пару недель (что кстати оч повышает результативность коммуникаций с заказчиком) то заказчик должен всегда иметь возможность «потрогать» то что было показано на последней демонстрации (линк если речь о веб, или файл инсталятора).
Не люблю я автоматические штуки. Затраты на их поддержание большие. Разве что кнопка спасет мир, но не всегда. Вот например структура БД изменилась и что? Автоматика иногда дает сбой.
Кстати промежуточный сервер полезная штука, особенно если там данные в БД адекватные :)
Кстати промежуточный сервер полезная штука, особенно если там данные в БД адекватные :)
Я на своих проектах держу скрипты по созданию БД в отдельном проекте. На каждый объект- скрипт для создания и для удаления (обновления и ролбэка до предыдущего релиза), отдельно скрипты с тестовыми данными плюс скрипты которые это все накатывают. При каждом автодеплойменте вызывается ролбэк потом апдейт. В результате имеем независимый контроль версий объектов бд и готовые деплоймент скрипты в любой момент да к тому же гарантированно рабочие и up to date ибо тестятся ежедневно.
Все здорово, но не хватает терминов на английском и полезных ссылок (например на системы контроля версий, которые используются автором, на CIS системы, на таск трекинговые системы). Мало про тестирование. Это пожелание, а не укор автору. Полезность текста была бы выше и можно было бы им пользоваться как краткой справкой при таком подходе.
Очень интересно, спасибо!
Кстати, С++ программисты, рекомендую почитать книгу «С++ для профессионалов(Professional C++)» Николас А. Солтер, Скотт Дж. Клепер
Там есть и про практику правильного развития проекта.
Кстати, С++ программисты, рекомендую почитать книгу «С++ для профессионалов(Professional C++)» Николас А. Солтер, Скотт Дж. Клепер
Там есть и про практику правильного развития проекта.
статья интересная, спасибо!
а вот название показалось мрачноватым, в конце напрашивались слова "… в могилу" :-))
а вот название показалось мрачноватым, в конце напрашивались слова "… в могилу" :-))
Есть еще вот такая штука:
Тест Джоэла Спольски 12 шагов к лучшему коду
1. Пользуетесь ли вы системой контроля версий?
2. Можете ли вы собрать продукт за один шаг?
3. Выполняете ли вы ежедневные билды?
4. Используете ли вы базу данных ошибок?
5. Исправляете ли вы ошибки перед написанием нового кода?
6. Есть ли у вас актуальный план работ?
7. Есть ли у вас спецификация?
8. Предоставлены ли вашим программистам спокойные условия для работы?
9. Используете ли вы новейшее дорогое оборудование?
10. Есть ли у вас тестеры?
11. Пишут ли кандидаты на работу код во время собеседования?
12. Проводите ли вы коридорное тестирование удобства использования программ?
по странному стечению здесь тоже 12 рекомендаций.
хотя возможно это моя паранойя
кому интересно тут
Тест Джоэла Спольски 12 шагов к лучшему коду
1. Пользуетесь ли вы системой контроля версий?
2. Можете ли вы собрать продукт за один шаг?
3. Выполняете ли вы ежедневные билды?
4. Используете ли вы базу данных ошибок?
5. Исправляете ли вы ошибки перед написанием нового кода?
6. Есть ли у вас актуальный план работ?
7. Есть ли у вас спецификация?
8. Предоставлены ли вашим программистам спокойные условия для работы?
9. Используете ли вы новейшее дорогое оборудование?
10. Есть ли у вас тестеры?
11. Пишут ли кандидаты на работу код во время собеседования?
12. Проводите ли вы коридорное тестирование удобства использования программ?
по странному стечению здесь тоже 12 рекомендаций.
хотя возможно это моя паранойя
кому интересно тут
В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать
Если есть разбивка на микротаски и управление ими, ответ на этот вопрос возникает сам собой
Исходный код проекта должен хранится в системе контроля версий и Все материалы по проекту должны быть сосредоточенны в одном месте. очевидно что ВСЁ должно хранится в системе контроля версий.
Если есть разбивка на микротаски и управление ими, ответ на этот вопрос возникает сам собой
Исходный код проекта должен хранится в системе контроля версий и Все материалы по проекту должны быть сосредоточенны в одном месте. очевидно что ВСЁ должно хранится в системе контроля версий.
Должна быть инструкция для настройки рабочего окружения по работе над проектом в идеале должен быть скрипт или инсталяшка которая разворачивает проект для работы
Я об этом писал в «Наличие описания сборки проекта.» :)
я не про сборку приложения здесь говорю, я про разворачивание рабочего окружения.
как понять этот механизм контроля версий? и как он выглядит? есть пример?
Классно! Наша компания проходит по многим тестам.
Про три вопроса — недавно проводил для Вебинар по управлению временем, как раз про это говорил. Вопросов задаю гораздо больше, но уже на автомате. Анализ — великая весчь, да.
Про три вопроса — недавно проводил для Вебинар по управлению временем, как раз про это говорил. Вопросов задаю гораздо больше, но уже на автомате. Анализ — великая весчь, да.
Спасибо за советы, над несколькими пунктами серьезно задумался.
Мы делаем это в начале дня, чтобы состыковывать планы. А подводим итог, соответственно, вчерашней работы.
В конце рабочего дня подведение краткого итога, и письменный ответ на три вопроса: что было сделано, какие проблемы возникли, что планируется сделать.
Мы делаем это в начале дня, чтобы состыковывать планы. А подводим итог, соответственно, вчерашней работы.
Не знаю почему, но верю в старую фишку, что подсознание хорошо кушает информацию к вечеру — а еще лучше прямо перед сном. За 15 минут перед сном пишу планчег.
Поэтому можно вечером провести анализ, и, если условия меняются часто — накидать векторы на завтра, а утром уже определиться с деталями. IMHO
Поэтому можно вечером провести анализ, и, если условия меняются часто — накидать векторы на завтра, а утром уже определиться с деталями. IMHO
Главное не переставать поддерживать порядок в голове и делах. :-)
Это не каждому под силу.
Это не каждому под силу.
Спасибо за дельную информацию в топике и комментариях, что-то я уже использую, что-то уже хочу внедрить.
UFO just landed and posted this here
А еще я бы добавил code review.
Программист — это ещё слишком мало в отсутствии приличного менеджера (или лицо, испольняющего его обязанности). Ибо программирование не может быть только ради программирования.
немного сумбурно, но я плюсовал от души
очевидно, контроль версий, управление задачами, сборка и т.д. — это просто некий очевидный необходимый уровень
а вот про 3 вопроса и обратную связь с заказчиком — это действительно разумный lifehack
очевидно, контроль версий, управление задачами, сборка и т.д. — это просто некий очевидный необходимый уровень
а вот про 3 вопроса и обратную связь с заказчиком — это действительно разумный lifehack
Sign up to leave a comment.
Программирование: Практики которые я возьму с собой