Уж простите пожалуйста, но моя цель была не порадовать людей красивым тайпсетом (термин мне не знаком, но как я понимаю, речь идет о шрифте?), а донести до той части хабра, что не читает бегло по-английски и/или не следит за публикациями на xkcd.com весьма остроумный, на мой взгляд, комикс.
Для меня в этом коде бредового — сравнение с false. Но это, как говорится, классика.
На тему валидации чисел — в Java я бы делал регуляркой, не знаю, как с этим в шарпах. Но это уже больше дело вкуса.
Да что вы говорите, подумать только, какое элегантное решение! (Уж простите за сарказм). Это во-первых. А во-вторых, оно неправильное ;) Как должно быть понятно из названия переменной, documentsMap — это мап. Попробуйте так создать ArrayList — и вы увидите.
Лично я не вижу тут излишней формализации.
Имхо, это просто подход отличный от вашего, о котором вы знаете, что он эффективен. Что и вызывает у вас неприятие. И я вас прекрасно понимаю. Может, стоить обсудить с техдиром? Иди это невозможно?
Я кодирую в свое удовольствие, а как следствие — меня не очень волнует как оно в ие6
Мои апплодисменты :)
*Надо взять этот дисклеймер на вооружение* :)
почему нельзя руководствоватся данными планов?
потому что есть планы, а есть реально потраченное время.
В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем.
А вы уверены, что через месяц вы вспомните подробности итерации? Какие задачи были недооценены, а какие наоборот — переоценены?
Для чего здесь понятие компонент? Подзадач?
На это уже ответил выше suglosta
Эти вещи вообще каккой имеют практический смысл?
Имхо, да
Вот как раз читаю славного дядьку Стива Макконнелла и его руководство по выживанию. Он предупреждал, что формализация процесса разработки будет вызывать сопротивление людей, с ней не сталкивавшихся. Я ему в принципе верил, но теперь вижу воочию.
Имхо, классный мужик — этот ваш техдир. И продуктивносьт команды увеличится. Если, конечно, все будет применено на практике так, как описано.
Согласен. Подобный механизм позволяет кардинально изменить смысл комментария.
Отображать всю историю по умолчанию — либо прогонит людей, либо фичу использовать не будут.
Предоставлять возможность посмотреть историю — не вариант. Если комменты читаются по диагонали (я обычно так и делаю), то история останется незамеченной. А если на основе комментария возника целая ветка?
Как вариант я бы предложил оценивать степень соответствия редактированного текста исходному. И если она больше опр. значения — не давать сохранить. Ведь обычно правка опечаток затрагивает лишь несколько букв (феерическую неграмотность я не рассматриваю, т.к. такой человек вряд ли будет править свой опус)
П.С. Вы зануда и грубиян (=
На тему валидации чисел — в Java я бы делал регуляркой, не знаю, как с этим в шарпах. Но это уже больше дело вкуса.
Блок-схема не моя, я просто разместил перевод
Спасибо, подправил.
Имхо, это просто подход отличный от вашего, о котором вы знаете, что он эффективен. Что и вызывает у вас неприятие. И я вас прекрасно понимаю. Может, стоить обсудить с техдиром? Иди это невозможно?
Я кодирую в свое удовольствие, а как следствие — меня не очень волнует как оно в ие6Мои апплодисменты :)
*Надо взять этот дисклеймер на вооружение* :)
потому что есть планы, а есть реально потраченное время.
В начале итерации распределены задачи, оценены. Прогресс смотрим ежидненвно. По итогам итерации анализируем.
А вы уверены, что через месяц вы вспомните подробности итерации? Какие задачи были недооценены, а какие наоборот — переоценены?
Для чего здесь понятие компонент? Подзадач?
На это уже ответил выше suglosta
Эти вещи вообще каккой имеют практический смысл?
Имхо, да
Имхо, классный мужик — этот ваш техдир. И продуктивносьт команды увеличится. Если, конечно, все будет применено на практике так, как описано.
Отображать всю историю по умолчанию — либо прогонит людей, либо фичу использовать не будут.
Предоставлять возможность посмотреть историю — не вариант. Если комменты читаются по диагонали (я обычно так и делаю), то история останется незамеченной. А если на основе комментария возника целая ветка?
Как вариант я бы предложил оценивать степень соответствия редактированного текста исходному. И если она больше опр. значения — не давать сохранить. Ведь обычно правка опечаток затрагивает лишь несколько букв (феерическую неграмотность я не рассматриваю, т.к. такой человек вряд ли будет править свой опус)