Comments 56
Мне одному кажется что в формулировке заблуждения и выводе есть какая то логическая неувязка?
Под «как писать программы» автор подразумевает изучение «правил языка программирования», после которого обучающимся предлагается писать программный код как им заблагорассудится. Автор приводит в качестве примера литературу — невозможно написать «Войну и мир», не изучив как можно больше примеров творчества умелых писателей. Или другой пример, уже мой личный — когда меня спрашивают умею ли я играть в шахматы, я отвечаю «нет, знаю только правила».
UFO just landed and posted this here
UFO just landed and posted this here
Когда речь идет о шахматах, то «умею играть» предполагает наличие определенных навыков, а не просто знания правил. Вы умеете водить автомобиль? Нет, знаю только правила.
UFO just landed and posted this here
>И что, зная правила шахмат, вы не сможете сделать ход? Вообще?
Человек сказал знать правила и уметь играть — две разные вещи. Причем тут сделать ход ??
К примеру: Есть Каспаров и вы (опытный программист и начинающий) оба знают правила (синтаксис языка) и могут делать ходы (есть возможности для написания программ) — но у Каспарова есть опыт(изучил язык не только азы уже), знание и видение определенных ситуаций (алгоритмы, паттерны и т.п.), так кто выиграет (напишет лучший код), продолжать ???
ИМХО вы точно не туда попали раз не видите различий в знаниях и умениях. Можно смотреть, а можно видеть, также как можно слушать и слышать. А это извините совсем не одно и то же!
Человек сказал знать правила и уметь играть — две разные вещи. Причем тут сделать ход ??
К примеру: Есть Каспаров и вы (опытный программист и начинающий) оба знают правила (синтаксис языка) и могут делать ходы (есть возможности для написания программ) — но у Каспарова есть опыт(изучил язык не только азы уже), знание и видение определенных ситуаций (алгоритмы, паттерны и т.п.), так кто выиграет (напишет лучший код), продолжать ???
ИМХО вы точно не туда попали раз не видите различий в знаниях и умениях. Можно смотреть, а можно видеть, также как можно слушать и слышать. А это извините совсем не одно и то же!
Про писателей не знаю, но художники пачками перерисовывают полотна мастеров. есть широко известное высказывание дали «для начала научитесь рисовать как старые мастера, а уж потом действуйте по своему усмотрению».
> Многие хорошие авторы стараются поменьше читать литературу того же жанра. Просто чтобы не повторяться и быть уникальным
вы правда верите, что если не читать произведения конкурентов, то шансы быть уникальным увеличиваются?
вы правда верите, что если не читать произведения конкурентов, то шансы быть уникальным увеличиваются?
мне кажется что если не читать других авторов, то как раз можно их случайно повторить.
Что-то мне подсказывает, что в «Совершенном коде» упомянуто куда больше подобных (этих же?) фактов и заблуждений.
Ну, и сами по себе все эти числа — средняя температура по больнице. Хоть и интересны сами по себе.
Ну, и сами по себе все эти числа — средняя температура по больнице. Хоть и интересны сами по себе.
PDF в пиздатом качестве (e-book) с оглавлением — rghost.ru/2144500
Зеркало — rapidshare.com/files/324246220/Glass_-_Facts_and_Fallacies_of_Software_Engineering.rar
Зеркало — rapidshare.com/files/324246220/Glass_-_Facts_and_Fallacies_of_Software_Engineering.rar
Спасибо вам, добрый человек, за файлик и за подкупающую прямолинейность.
Присоединяюсь к благодарностям. Надо будет для таких людей тоже придумать название типа К.О. Пусть, например, будет К.П. — Капитан Прямолинейность.
Большое человеческое спасибо.
В понедельник дам почитать своему операционному директору -))
В понедельник дам почитать своему операционному директору -))
Fb2 версия coming soon, на неделе причешу камменты и выложу на флибусту/либрусек. Желающие получить линк- оставляйте заявки в личку.
премного благодарен!
прямолинейность не всегда доводит до добра, вот, с первого адреса книжку уже удалили. хорошо что рапидшара не сгибаемая. :)
UFO just landed and posted this here
Не противоречат — habrahabr.ru/blogs/books/99375/#comment_3067717
Про хороший код, который стоит давать читать новичкам, в обсуждении данного заблуждения так же написано.
Про хороший код, который стоит давать читать новичкам, в обсуждении данного заблуждения так же написано.
Самое интересное, что опубликованы данные по этим исследованиям в 1968 году.
Подозреваю, что за это время разница могла сильно измениться. Вопрос только в том, в какую сторону :)
Технологии движутся вперед, люди почти не меняются =)
«научное исследование» там крайне мутное. «Исследователи пытались определить разницу в производительности между использованием вычислительных ресурсов в пакетном режиме и в режиме с разделением времени и установили, что она может выражаться соотношением вплоть до 28:1» Как из этого следует то, что лучшие программисты до 28 раз превосходят слабейших, непонятно.
Допустим, мы научим слабейшего использовать выч.ресурсы в пакетном режиме.Он сразу станет лучшим?
По-моему, авторы перепутали производительность труда программиста и скорость работы алгоритмов, которые он использует.
Допустим, мы научим слабейшего использовать выч.ресурсы в пакетном режиме.Он сразу станет лучшим?
По-моему, авторы перепутали производительность труда программиста и скорость работы алгоритмов, которые он использует.
На ранних компьютерах нужно было БИОС вбивать руками прямо при загрузке компа в шестнадцатеричных кодах. Известна история о том, как программист Забыл-Как-Зовут диктовал этот БИОС своему коллеге по телефону. По памяти.
В The Jargon File можно найти много таких историй из веков разной глубины.
В The Jargon File можно найти много таких историй из веков разной глубины.
Сталкивался с фактом 16 несколько раз, только не со стороны программиста, а со стороны заказчика. Многие заказчики считают, что если создать программу-конструктор «всё-в-одном», то можно будет посадить людей с более низкой зарплатой и сэкономить на относительно высокооплачиваемых программистах. Скупой платит дважды. Реализация занимает гораздо больше времени, а в конце оказывается, что никто с программой не хочет работать (или требует больше денег), так как она слишком сложная.
Отличная книга. Но многим она может показаться странной :))
Насчет факта #2… Когда то на хабре была статья с названиям типа «Как стать лучшим программистом». Один из советов там был примерно таким:
Замкните всю разработку на себя, постоянно переписывайте чужой код, не рассказывайте другим о своих решениях и т.д. Этот прием позволит вам стать не только незаменимым, но и эффективнейшим сотрудником, т.к. кроме вас никто не сможет ориентироваться в разрабатываемой системе. Однако ясно что пользу это принесет только вам, но не фирме.
Замкните всю разработку на себя, постоянно переписывайте чужой код, не рассказывайте другим о своих решениях и т.д. Этот прием позволит вам стать не только незаменимым, но и эффективнейшим сотрудником, т.к. кроме вас никто не сможет ориентироваться в разрабатываемой системе. Однако ясно что пользу это принесет только вам, но не фирме.
Самая первая цитата (ну или очень близкая к ней) есть в книге «Peopleware» Тома ДеМарко и Тимати Листера.
Вы мне объясните вот что — как можно мерить отличие между программистами «в разах»? В 28 раз, хех… Чего не в 42?
Найдите ссылку на эту работу (даже книгу покупать не придется, ссылка на пдф есть в каментах) и ознакомтесь.
Если вам покажется что методология исследований не является адекватной — напишите об этом.
Если вам покажется что методология исследований не является адекватной — напишите об этом.
Ну, можно считать исходя из:
1. Объема написанного кода
2. Количества багов (абсолютно или относительно объёма написанного кода).
3. Денег, которые компания заработала на продукте.
4. Сроках отставания от запланированного графика.
Много чего можно придумать.
1. Объема написанного кода
2. Количества багов (абсолютно или относительно объёма написанного кода).
3. Денег, которые компания заработала на продукте.
4. Сроках отставания от запланированного графика.
Много чего можно придумать.
28-кратное отличие в производительности явно привлекает внимание, но исследование не вызывает доверия (как годом, так и непосредственно процессом исследования).
Как я представляю себе «правильный» процесс подобного исследования: разработчикам даётся задание, сравниваются сроки разработки и в каких-либо комплексных метриках — качество результата. При этом, задачи должны быть достаточно объёмными, т.к. многие начинающие разработчики достаточно быстро могут писать небольшие тулы, но сталкиваются с проблемами и «тормозят» при проектировании более серьёзных разработок.
Интересно было бы посмотреть на дисперсию результатов в таком исследовании.
Как я представляю себе «правильный» процесс подобного исследования: разработчикам даётся задание, сравниваются сроки разработки и в каких-либо комплексных метриках — качество результата. При этом, задачи должны быть достаточно объёмными, т.к. многие начинающие разработчики достаточно быстро могут писать небольшие тулы, но сталкиваются с проблемами и «тормозят» при проектировании более серьёзных разработок.
Интересно было бы посмотреть на дисперсию результатов в таком исследовании.
Сроки разработки не говорят вообще ни о чем. К примеру, один напишет гостевую книгу в одном файле, используя кучу условий, а второй использует MVC-архитектуру, паттерны, грамотно отформатирует код и напишет комментарии. Первый справится с задачей за час, а второй за три, но результат работы первого не представляет ценности, а результат второго можно использовать в куче проектов и легко поддерживать.
Результат второго тоже может не представлять ценности, когда:
— это надо вчера
— это надо дешево и сердито
— переиспользовать особо нечего, т.к. задачи бывают тупыми
— это надо вчера
— это надо дешево и сердито
— переиспользовать особо нечего, т.к. задачи бывают тупыми
1) иногда, кроме скорости, ничто не имеет значения.
2) чаще это не так :) поэтому и предлагаю расширить измерение, т.е. считать не только скорость, но и качество. Причём качество — это комплекс метрик: функционирование, производительность, поддерживаемость, масштабируемость и т.д.
3) требования к качеству тоже всегда разные. К примеру, иногда поддерживаемость не имеет значения (когда есть 100% уверенность в отсутствии необходимости последующего расширения). Не любой грамотный разработчик в таком случае может перестроиться и начать лабать «дёшево и сердито».
2) чаще это не так :) поэтому и предлагаю расширить измерение, т.е. считать не только скорость, но и качество. Причём качество — это комплекс метрик: функционирование, производительность, поддерживаемость, масштабируемость и т.д.
3) требования к качеству тоже всегда разные. К примеру, иногда поддерживаемость не имеет значения (когда есть 100% уверенность в отсутствии необходимости последующего расширения). Не любой грамотный разработчик в таком случае может перестроиться и начать лабать «дёшево и сердито».
На самом деле ещё проблема в подсчёте такой цифры не только в метрике скорости/качества, но и вы в понятие плохой программист. Это попахивает делением на ноль. Обезьяна — плохой программист?
А кто использовал слово «плохой»? Есть объективные метрики, есть соответствие задачи определённому сотруднику… В оценках «плохой»/«хороший» смысла не вижу.
Если есть задача, с которой обезьяна может справиться с заданным уровнем качества и в заданные сроки — то конечно, она хороший программист :) Хотя я и не верю в наличие таких «реальных» задач, с которыми справится обезьяна ;)
Если есть задача, с которой обезьяна может справиться с заданным уровнем качества и в заданные сроки — то конечно, она хороший программист :) Хотя я и не верю в наличие таких «реальных» задач, с которыми справится обезьяна ;)
> лучшие программисты до 28 раз превосходят слабейших
выбрав в качестве слабейшего обезьяну, мы получим насколько угодно большое соотношение, поэтому я и говорю о делении на ноль. Задача здесь важна постольку поскольку
выбрав в качестве слабейшего обезьяну, мы получим насколько угодно большое соотношение, поэтому я и говорю о делении на ноль. Задача здесь важна постольку поскольку
Ученая обезьяна, которая думает, что она программист, может и справиться, правда потом переделывать будет несколько раз. У нас такой обезьян работает.
Мне кажется, что такое различие вполне естественно, и чем более интеллектуальную работу будут делать люди, тем больше будет эта разница. Если от мойщиков окон странно ожидать такую разницу в производительность, то среди ученых она может быть и еще больше — не все ученые Ньютоны и Эйнштейны.
Я тоже допускаю такое отличие. Более того — на крупных комплексных задачах, скорее всего, оно будет ещё больше. Просто текущая цифра «28» взята скорее с потолка — хочется более авторитетного результата. Специально поискала — не нашла…
Именно так (сказывается разница существующих задач и технологий сейчас и на момент исследования) в зависимости от задачи число «28» может быть как за сотню перевалить, так и быть однозначной…
Что значит с потолка? В книге есть ссылка на исследование — найдите эту статью, изучите, посмотрите какие методы применялись при исследовании, какая была выборка, какие условия проведения исследования. Если что-то покажется вам сомнительным — вы можете указать на это как авторам исследования, так и всему заинтересованному научному и ит-шному сообществу.
Оригинал исследования я смотрела. В нём 2м группам людей (опытные разработчики и учащиеся) дали две задачки и смотрели на разницу трудозатрат по ним на разные части задач. 28 к 1 — это соотношение времени дебага (только) по одной из задач. При этом, «качество» измерялось только по производительности и размеру программ.
Всё это вместе — «с потолка». Представления о качестве нет, задачки не крупные, технологии старые. Как я вижу себе более правильное исследование, написала сверху.
Авторам исследования 42-летней давности врядли будет актуально моё мнение по этой работе :)
Всё это вместе — «с потолка». Представления о качестве нет, задачки не крупные, технологии старые. Как я вижу себе более правильное исследование, написала сверху.
Авторам исследования 42-летней давности врядли будет актуально моё мнение по этой работе :)
Целью автора было всего лишь показать приблизительную величину диапазона. Он нашёл иследование с цифрой и указал её.
Не вижу необходимости проводить правильное исследование. Будет зависеть от технологии, качества и испытуемых, а вывод будет аналогичный. Разброс между очень плохим разработчиком и очень хорошим существенно велик.
Не вижу необходимости проводить правильное исследование. Будет зависеть от технологии, качества и испытуемых, а вывод будет аналогичный. Разброс между очень плохим разработчиком и очень хорошим существенно велик.
Разброс можно снизить, если не набирать студентов, а брать только людей с опытом. Что-нибудь типа: участие в минимум 2-ух проектах, участие в каждом из проектов около 2-ух лет (зависит от сложности проекта).
для этого достаточно сказать «мамой клянусь, разброс большой!» :)))
исследования проводятся не только для подтверждения, но и для опровержения теорий. То есть, мне тоже кажется, что разброс большой… Но подтверждающих фактов нет.
исследования проводятся не только для подтверждения, но и для опровержения теорий. То есть, мне тоже кажется, что разброс большой… Но подтверждающих фактов нет.
Скачал, почитал — понравилось. Узнал много нового, автору обзора спасибо!
Sign up to leave a comment.
Факты и заблуждения профессионального программирования