ну изолировать то модули можно а вот как изолировать от них базу? все таки БД это общий ресурс, и любому классу позволенно юзать любую таблицу. вот и получилось по невнимательности, что я писал в поле, которое предназначенно для другого. но это все рабочие моменты, ничего страшного.
кстати подобных ошибок помогают избежать функциональные тесты, которые по хорошему должны писаться тестерами или заказчиком. но у нас даже тестеров нет какие уж тут тесты.
Вы поняли правильно. Роль да, ведущий программист, но это название ничего не значит, никаких отличий или полномочий нет.
я не хочу пока общаться с новым техдиром. Я думаю что первая задача техдира познакомится с разработчиками. Каюсь, он раз меня позвал познакомится, точнее для того что бы я объяснил ему архитектуру. Меня и одмина. Я сказхал что не плохо бы было пригласить и других программистов. Пригласили, ребята хотя бы познакомились.
Но что-то он внедрить пытается. Хотя что я понятия не имею. ОН с нами не общается и даже не здоровается пока сам руку не протянешь.
Не в обиду но если вы оправдываете то что не пишете тесты ДО кода потому что не удается спроектировать то вы не понимаете для чего нужны тесты. Полное покрытие это только 1 причина из трех основных.
А баги возникать могут еще по причине
1. Недопонял задачу
2. Тестовая структура БД отличается от реальной
3. Ошибка в интерфейсе
4. Ошибка в функциональной логике а не программной
5. Не полное покрытие тестами
6. Несоответствие реального окружения тестовому
В моем случае была банальная невнимательность, неверно сформированный URL, что относится к причине #3, а второй раз из за того что тесты невзаимосвязанны (это так и должно быть), поэтому ошибка не всплыла, Я просто случайно записывал данные в поле, необходимое для другого. Мой код херил данные другого модуля.
а третьего не дано?
наверное сообщение стоило бы построить немного подругому, с использованием слова «может» вместо «либо»
можно вопрос, вы тесты пишете?
Эту практику внедрить не успели, пока итераций мало, можно просто вводить поправочный коэфициент для каждого программиста на основе результатов последней итерации. Получилось, кстати, очень интересно. По итогам первой итерации, из 4-х, на тот момент программистов, 2 уложились в сроки, что называется, на флажке, один отстал, и один сделал все быстрее. Это четко было видно по плану. Но так как один человек из команды справился раньше, он помог тому кто не уложился. При анализе стало понятно причины такого расклада. Опоздавший просто последние года два программировал на C++, и подзабыл Java, а тот кто сделал быстрее лучше всех нас знает те фреймворки что мы применяем. Поэтому решил на следующую итерацию не вводить коэфициентов. Тот кто опоздал уже Java вспомнил, значит сделает быстрее. А наш гуру пусть будет как подстраховка, если опять сделает раньше, поможет другим. На следующую итерацию мы все опять успели в сроки к презентации, правда пришлось покоцать задачи из за 5-и дневного рефакторинга непонятно с какого перепугу проведенного.
Потом отдал процесс в руки ПМ-а и все. С тех пор никто не видел ни одного плана.
Но если бы понадобилась точная статистика, а она бы понадобилась со временем, то получить её всегда несложно из старых планов, хранящихся в свн. Так же можно удобно использовать wiki для хранения планов по итерациям и статистики.
1. Было XP. Но не полностью, а то что позволяют мои полномочия. Игра в планирование проводилась без участия заказчика. Но все равно это эффективнее чем обычное последовательное выполнение задач без итераций и контрольных точек.
2. Похерил ПМ. Я распланировал, и уехал в отпуск, передав расписанные планы ему. Когда вернулся увидел что за 5 дней из плана не сделано ничего, а люди занимались рефакторингом. Пришлось за последнюю неделю вкалывать полной что бы успеть к концу итерации сделать хотя бы основные задачи. На мои вопросы почему похерили план ПМ невнятно промычал что итак все нормально. Ну раз нормально, давай работать без плана сравним эффективность. После этого все пошло через жопу.
3. По Скраму не знаю. В принципе XP включает почти все техники скрама, разница в деталях.
4. Можно, ктож против. Вот пусть сам и вносит если это ему надо. Но я бы ему не советовал так как по хорошему план надо бы показывать заказчику и вешать на стену что бы он всегда мог посмотреть, а каждый день обновлять и JIRA и план это двойная работа. Тем более мне непонятно как в JIRA удобно отмечать прогресс по задаче. Но это уже не мои проблемы, если ПМ мазахист, это его проблемы.
только что была ситуация. вроде бы проверил, работает. закомитил код. выгрузили на тестовый сервер, ошибка. Посмотрел логи, нашел ошибку, исправил, проверил что исправлено — закомитил. Нашел еще одну, пришлось менять логику, добавлять поле в БД… И теперь вопрос, как же так я такой падлец комитил 3 раза нерабочий код! Не надо было?
то что мы пишем вкрации это социальная сеть
вопщем вы вывод сделали правильный. даже лучше меня все знаете.
а вообще мне этот диалог несколько поднадоел. вы просто напросто не понимаете многих вещей, но уверенны что вы крутой программист. но вы правильно скзали что кодить это не одно итоже что программировать
отстаньте от меня. я ничего не понимаю в этой кухне. было сказанно что отчеты нужны для аудиторских проверок, я склонен в это верить, но наверное вы лучше знаете.
вы просто ничего не поняли. обьясняю вам подробно. если есть желание понять, то подумайте над этим. если нет, то дальше не читайте, все равно не поймете.
Итак. В чем приемущество частых апдэйтов и комитов. В том что локальные копии остаются примерно одинаковыми и далеко не расходятся. Таким образом шанс конфликтов снижается. И конфликты разруливать гораздо проще.
Кстати, если вы не знаете то конфликт, это не ошибка, это нормальное явление для svn. Потому что svn это система основанная на конфликтах, и конфликт это то что является неотемлимой частью свн.
Но если локальные версии слишком сильно разойдутся, то часто конфликты разрулить будет сложно а иногда практически невозможно. Поэтому для того что бы не создавать проблем другим, комитя результаты недельной работы, комитить нужно чаще, несколько раз в день, что бы они вовремя могли получить ваши изменения.
Простой пример:
Вася и Петя работают над одним проектом. Допутим они комитятся редко. Итак Вася правит некий файл, но не комитит. Петя апдейтится, но не получает правок Васи. На следующий день Петя правит тот же файл в том же месте. Теперь можно принимать ставки кто из них получит конфликт. В любом случае тот кто первый проапдейтится.
А теперь допустим что они комитятся часто. Вася правит файл и сразу его комитит. Петя апдейтится часто, поэтому сразу получает изменения Васи. На следующий день он правит тот же файл и тут же его комитит. Никто конфликт не получит.
Конечно не надо доводить до фанатизма, и не комитить каждые 5 минут. Нормально комитить более или мение завершенные части системы, конечно если это не нарушает работоспособности кода. Обычно комититится нужно 2-5 раз за день в зависимости от задачи. Это на порядок снижает вероятность конфликтов. У нас они редкость.
У нас этого не внедрено. Было но похерили. Теперь новый техдир пытается внедрить свои методы.
Почему исключает объясняю. Дело в том что если есть скрам-митинги то не нужно то что предлагает техдир. В этом просто нет никакого смысла. Так что дополнять оно их не может. Оно может только дублировать.
просто вы путаете организацию планирования, которыми занимаются менеджеры, и организацию разработки, которой занимаются программисты. так вот в организации разработки у нас все нормально. у нас собраны грамотные программисты которые могут сами для себя выбрать эффективные методы разработки такие как разработка через тестирование, рефакторинг. применить нужные паттерны проектирования, разработать архитектуру, выбрать правильные эффективные инструменты. если у вас этого нет, я вам сочувствую. А вот организовать грамотное планирование не в наших силах, тут нужна воля менеджмента. Я пытался оргнаизовать сам, и до тех пор пока я этим занимался все шло хорошо. Но это требует большого времени, а на мне еще задачи разработки висят. Пришлось повесить все на ПМ-а который на уже внедренные процессы забил. Так все и развалилось.
Итак, повторяю. Разработка у нас налажена более или мение. Конечно некоторые забивают на тесты, не создают вовремя веток, не любят писать внятные комменты, я пытаюсь влиять как могу, но опять же я не уполномочен настаивать. Но я лично разрабатываю так и как могу обьясняю приемущества своих подходов другим.
А вот планирования у нас нет никакого вообще. Так что никаких противоречий в моих словах нет.
да откуда я знаю. нам было сказанно что отчеты нужны для оцкенки капитализации компании которая нужна для аудита. я не экономист и в детали не вникал. аудит не внутренний а внешний.
я не могу представить других источников кроме как генератора случайных отчетов.
Потому что эти 2 пункта ИСКЛЮЧАЮТ игру в планирование, или скрам-митинги. Это означает, что мы меняем все приемущества практик коллективного планирования, на удобство менеджера, который не вставая с места будет получать сроки по задачам. Дело не в том что мне сложно проставить эти строки, а в том что соглашаясь на это, мы теряем кучу приемуществ практик планирования Scrum и XP
ну ПМ-а я как пример привел. Мало что может снижать мотивацию программиста. Может у него место рабочее неудобно, или монитор плохой, или кондиционера нет. Это уже ПМ-у разбираться.
Если это новый класс или новый раздел сервиса, то почему бы и нет? Я комичу на основе тестов. Сработали, значит все ок и можно комитить. Что в этом такого плохого?
кстати подобных ошибок помогают избежать функциональные тесты, которые по хорошему должны писаться тестерами или заказчиком. но у нас даже тестеров нет какие уж тут тесты.
я не хочу пока общаться с новым техдиром. Я думаю что первая задача техдира познакомится с разработчиками. Каюсь, он раз меня позвал познакомится, точнее для того что бы я объяснил ему архитектуру. Меня и одмина. Я сказхал что не плохо бы было пригласить и других программистов. Пригласили, ребята хотя бы познакомились.
Но что-то он внедрить пытается. Хотя что я понятия не имею. ОН с нами не общается и даже не здоровается пока сам руку не протянешь.
А баги возникать могут еще по причине
1. Недопонял задачу
2. Тестовая структура БД отличается от реальной
3. Ошибка в интерфейсе
4. Ошибка в функциональной логике а не программной
5. Не полное покрытие тестами
6. Несоответствие реального окружения тестовому
В моем случае была банальная невнимательность, неверно сформированный URL, что относится к причине #3, а второй раз из за того что тесты невзаимосвязанны (это так и должно быть), поэтому ошибка не всплыла, Я просто случайно записывал данные в поле, необходимое для другого. Мой код херил данные другого модуля.
наверное сообщение стоило бы построить немного подругому, с использованием слова «может» вместо «либо»
можно вопрос, вы тесты пишете?
Потом отдал процесс в руки ПМ-а и все. С тех пор никто не видел ни одного плана.
Но если бы понадобилась точная статистика, а она бы понадобилась со временем, то получить её всегда несложно из старых планов, хранящихся в свн. Так же можно удобно использовать wiki для хранения планов по итерациям и статистики.
2. Похерил ПМ. Я распланировал, и уехал в отпуск, передав расписанные планы ему. Когда вернулся увидел что за 5 дней из плана не сделано ничего, а люди занимались рефакторингом. Пришлось за последнюю неделю вкалывать полной что бы успеть к концу итерации сделать хотя бы основные задачи. На мои вопросы почему похерили план ПМ невнятно промычал что итак все нормально. Ну раз нормально, давай работать без плана сравним эффективность. После этого все пошло через жопу.
3. По Скраму не знаю. В принципе XP включает почти все техники скрама, разница в деталях.
4. Можно, ктож против. Вот пусть сам и вносит если это ему надо. Но я бы ему не советовал так как по хорошему план надо бы показывать заказчику и вешать на стену что бы он всегда мог посмотреть, а каждый день обновлять и JIRA и план это двойная работа. Тем более мне непонятно как в JIRA удобно отмечать прогресс по задаче. Но это уже не мои проблемы, если ПМ мазахист, это его проблемы.
А для еще большей пользы от общения, посоветую вам бросить это гиблое занятие в виде техзадания. Простой перевод времени.
вопщем вы вывод сделали правильный. даже лучше меня все знаете.
а вообще мне этот диалог несколько поднадоел. вы просто напросто не понимаете многих вещей, но уверенны что вы крутой программист. но вы правильно скзали что кодить это не одно итоже что программировать
Итак. В чем приемущество частых апдэйтов и комитов. В том что локальные копии остаются примерно одинаковыми и далеко не расходятся. Таким образом шанс конфликтов снижается. И конфликты разруливать гораздо проще.
Кстати, если вы не знаете то конфликт, это не ошибка, это нормальное явление для svn. Потому что svn это система основанная на конфликтах, и конфликт это то что является неотемлимой частью свн.
Но если локальные версии слишком сильно разойдутся, то часто конфликты разрулить будет сложно а иногда практически невозможно. Поэтому для того что бы не создавать проблем другим, комитя результаты недельной работы, комитить нужно чаще, несколько раз в день, что бы они вовремя могли получить ваши изменения.
Простой пример:
Вася и Петя работают над одним проектом. Допутим они комитятся редко. Итак Вася правит некий файл, но не комитит. Петя апдейтится, но не получает правок Васи. На следующий день Петя правит тот же файл в том же месте. Теперь можно принимать ставки кто из них получит конфликт. В любом случае тот кто первый проапдейтится.
А теперь допустим что они комитятся часто. Вася правит файл и сразу его комитит. Петя апдейтится часто, поэтому сразу получает изменения Васи. На следующий день он правит тот же файл и тут же его комитит. Никто конфликт не получит.
Конечно не надо доводить до фанатизма, и не комитить каждые 5 минут. Нормально комитить более или мение завершенные части системы, конечно если это не нарушает работоспособности кода. Обычно комититится нужно 2-5 раз за день в зависимости от задачи. Это на порядок снижает вероятность конфликтов. У нас они редкость.
А вы называетете меня безответвенным.
Почему исключает объясняю. Дело в том что если есть скрам-митинги то не нужно то что предлагает техдир. В этом просто нет никакого смысла. Так что дополнять оно их не может. Оно может только дублировать.
Итак, повторяю. Разработка у нас налажена более или мение. Конечно некоторые забивают на тесты, не создают вовремя веток, не любят писать внятные комменты, я пытаюсь влиять как могу, но опять же я не уполномочен настаивать. Но я лично разрабатываю так и как могу обьясняю приемущества своих подходов другим.
А вот планирования у нас нет никакого вообще. Так что никаких противоречий в моих словах нет.
я не могу представить других источников кроме как генератора случайных отчетов.