то есть надо свернуть так же и бухгалтерскую отчетность, не просить заявлений на отпуск, увольнение, забить на больничные, командировочные талоны? Это ведь тоже бюрократия. Тогда точно шансы выжить в кризис повысятся.
Если вы не знает то есть такой принцип работы с svn при котором комитятся и апдейтятся часто. Это позволяет как раз таки избегать конфликтов. Это очень распространенная а не мной придуманная практика. Если вы о ней не знаете, то учитесь лучше, потому что ваше замечание выглядит очень странно. Все что ниже я не понял как относится к svn
сударь, вы меня обидеть хотите?)))
я знаю команду svn log и svn blame. Я могу увидеть кто когда и что менял. Зачем меняли — указанно в комменте. Они не настолько подробны насколько хотелось но во всех ситуациях когда я хотел узнать зачем и кто менял код я это выяснял.
Насчет именования переменных, это вы тут зачем приплели? Но если интересно отвечу. Да. И не только переменных но и классов и функций. Как и вообщем есть и стандарты кодирования.
Документация тоже есть, но основная документация это наши тесты, и имена классов, методов и переменных.
Еще вопросы есть?
речь вроде об одном инструменте — svn. Уточните как конкретно неправильное по вашему мнению использование этого конкретного инструмента влияет на сроки.
Насчет догадок вы не правы. У нас ветки создаются на большие задачи длительностью более 1 дня и удаляются сразу по завершении. На данный момент в хеаде две ветки.
Не переживайте. Апдейтится тожа надо часто, а кто не апдейтится сам дурак. У нас все нормально, и такой стиль разработки работает отлично, конфликты редкость, и проблемы не создают. Комменты я пишу, а за другими следить не моя задача. Хотя конечно стараюсь внушение делать. За ветки тоже не волнуйтесь. Всем объяснено что мержить себе в ветку надо почаще, а кто опять таки не мержит тот сам дурак.
Конечно не совмещает. И когда он был разработчиком не важно, важно что бы он не просто писал говнокод а именно перерос кодинг, когда дальше программировать уже неинтересно, все уже написано по сто раз, все паттерны изучены, все рефакторинги проведены. Когда человек стал ПМ-ом не потому что посчитал что это проще а денег больше, а потому что вырос просто из программистов, потому что интересно шакать дальше, интересно развиваться, учится новому, попробовать себя в этой области. Но не находясь долгое время в тесном коллективе программистов, не испытывая на себе влияние других ПМ-ов, сложно понять самое важное, то как каждое действие влияет на программиста. ПМ должен быть таким же технарем как и программер, понимать все особенности работы программиста, говорить с ними на одном языке. Но главное понять что менеджмент это прежде всего вещь социальная, и максимальный эффект получится только если поставить во главу угла человека, а все остальное должно ему помогать.
А люди не поработавшие долгое время в этой индустрии, они расценивают программистов как винтики, а себя как оператора пульта управления. Они думают что если просто дергать за такие вот рычажки механизм будет работать. Они так думают потому что небыли никогда внутри этого механизма.
Я про табличку не просто так написал. Прочтите книгу «Рабы майкрософт», и посмотрите как нормальные программисты относятся к подобного рода подачкам. За что премия, если программист может сделать что, то то он сделает. Если нет, то нет. Если ему не хочется работать потому что ПМ мудак, то проще сменить ПМ-а, и программист будет больше доволен и ПМ на долго а 40% один раз. Проще всего купить программиста деньгами, чем понять почему он не может работать так же хорошо и без денежной стимуляции. Ведь получается если ему денег не предлагать, он будет халявить? А если нет, то значит за эти 40% он работает на износ, значит будут у него проблемы в семье, недосып, что в итоге приведет к падению мотивации. Но да, проще не думать а дать человеку эти 40%, как в топку уголька подкинуть.
я знаю команду svn log и svn blame. Я могу увидеть кто когда и что менял. Зачем меняли — указанно в комменте. Они не настолько подробны насколько хотелось но во всех ситуациях когда я хотел узнать зачем и кто менял код я это выяснял.
Насчет именования переменных, это вы тут зачем приплели? Но если интересно отвечу. Да. И не только переменных но и классов и функций. Как и вообщем есть и стандарты кодирования.
Документация тоже есть, но основная документация это наши тесты, и имена классов, методов и переменных.
Еще вопросы есть?
Насчет догадок вы не правы. У нас ветки создаются на большие задачи длительностью более 1 дня и удаляются сразу по завершении. На данный момент в хеаде две ветки.
А люди не поработавшие долгое время в этой индустрии, они расценивают программистов как винтики, а себя как оператора пульта управления. Они думают что если просто дергать за такие вот рычажки механизм будет работать. Они так думают потому что небыли никогда внутри этого механизма.