Comments 30
По моему в большинство этих мифов итак никто не верит
«И так» в данном случае пишется с пробелом. Искренне недоумеваю, как можно допускать такие ошибки, ведь у слова «итак» совсем другое значение.
Если бы в эти мифы верили рядовые девелоперы, то это было бы половиной беды.
Проблема в том, что в эти мифы в основном верят тим-лиды и менеджеры.
И вот тут начинается самое интересное…
Кто работал(работает) в крупных компаниях — поймет о чем я.
Проблема в том, что в эти мифы в основном верят тим-лиды и менеджеры.
И вот тут начинается самое интересное…
Кто работал(работает) в крупных компаниях — поймет о чем я.
Как и многие другие статьи о философии программирования и абстрактном «как нужно программировать» — тут тоже все зависит в первую очередь от задачи. Это касается пунктов 4, 6, 7.
Миф №4: Современные инструменты обеспечивают лучшие результаты
напрямую зависит от задачи. Многие задачи давно реализованы и нет смысла выдумывать велосипед. А уж выбор языка программирования для проекта тем более.
Миф №6: Крутые разработчики оптимизируют код по максимуму
Я много раз слышал от качественных, на мой взгляд, разработчиков (в том числе книгах, конференциях, форумах) о том, что даже комментарии и лишние пустые строки (актуально для скриптовых языков) иногда увеличивают время запуска или работы приложений. И это тоже оптимизация «по максимуму». Вот «крутые» программисты просто обычно знают как «работает» их язык программирования и исходя из этого «оптимизируют по максимуму»
Миф №7: Хороший код — «элегантный» код
Опять же зависит от проекта. В крупных проектах с большой командой разработчиков на «элегантность» тратится много времени, хотя это часто больше связано с понимаемостью и читаемостью кода, нежели «смотрите как я умею».
С другой стороны мелкий, пусть даже коммерческий проект, цель которого отработать один раз или периодически, но вероятность последующих исправлений которого крайне мала.
Резюмирую:
И Ваши и мои размышления имеют место жить во многих ситуациях, но далеко не во всех.
Миф №4: Современные инструменты обеспечивают лучшие результаты
напрямую зависит от задачи. Многие задачи давно реализованы и нет смысла выдумывать велосипед. А уж выбор языка программирования для проекта тем более.
Миф №6: Крутые разработчики оптимизируют код по максимуму
Я много раз слышал от качественных, на мой взгляд, разработчиков (в том числе книгах, конференциях, форумах) о том, что даже комментарии и лишние пустые строки (актуально для скриптовых языков) иногда увеличивают время запуска или работы приложений. И это тоже оптимизация «по максимуму». Вот «крутые» программисты просто обычно знают как «работает» их язык программирования и исходя из этого «оптимизируют по максимуму»
Миф №7: Хороший код — «элегантный» код
Опять же зависит от проекта. В крупных проектах с большой командой разработчиков на «элегантность» тратится много времени, хотя это часто больше связано с понимаемостью и читаемостью кода, нежели «смотрите как я умею».
С другой стороны мелкий, пусть даже коммерческий проект, цель которого отработать один раз или периодически, но вероятность последующих исправлений которого крайне мала.
Резюмирую:
И Ваши и мои размышления имеют место жить во многих ситуациях, но далеко не во всех.
Спасибо за Ваш отзыв. Да, действительно, Ваши замечания вполне справедливы.
А теперь, товарищ КО, вспомните бедных ученых, которые вынуждены писать софт себе сами. А пишут они на том, что знают — поэтому-то до сих пор основная масса математических пакетов — на фортране. И многие из них о современных библиотеках не знают. И об оптимизации они слыхом не слыхивали. И код у нас обычно такой, что черт ногу сломит.
Но зато работает и поставленные задачи выполняет. И это хорошо, т.к. ждать нужного софта от «крутых программистов» — себе дороже. Так и помереть можно, а софта хрен дождешься…
Но зато работает и поставленные задачи выполняет. И это хорошо, т.к. ждать нужного софта от «крутых программистов» — себе дороже. Так и помереть можно, а софта хрен дождешься…
«Twitter переключился с Ruby на Scala, а потом на Java.»
Можно ссылку на это? Единственное, что я смог найти — это то, что они пишут некоторые части на java, но про отказ от scala — ни чего.
Можно ссылку на это? Единственное, что я смог найти — это то, что они пишут некоторые части на java, но про отказ от scala — ни чего.
Да, все верно, они используют Scala + Java www.readwriteweb.com/hack/2011/07/twitter-java-scala.php. Немножко некорректно сформулировано предложение, поправим. Спасибо.
Мало того, что предложение было сформулировано неправильно, Ваши выводы совершенно не соответствуют тезисам из статьи по линьку, который Вы поставили выше.
Twitter частично перешел на Skala и это связано не с особенностями языка Руби, а совершенно другими соображениями.
Для справки, полно сайтов с огромной посещаемостью, которые были написаны и по-прежнему живут в Руби. hulu.com, vimeo.com, и т.д.
Вы наверно хотели сказать, что язык сам по себе не может писать хорошие программы — для хороших програм нужен хороший програмист. Я правильно понял?
Twitter частично перешел на Skala и это связано не с особенностями языка Руби, а совершенно другими соображениями.
Для справки, полно сайтов с огромной посещаемостью, которые были написаны и по-прежнему живут в Руби. hulu.com, vimeo.com, и т.д.
Вы наверно хотели сказать, что язык сам по себе не может писать хорошие программы — для хороших програм нужен хороший програмист. Я правильно понял?
Не убедили.
Даже более того единственный миф в этой статье содержится в первом предложении и не пронумерован:
Как известно, наш проект Jelastic создан с целью…
Я готов поспорить, что большинству это не просто неизвестно, а глубоко параллельно и будет забыто через 30 минут после прочтения. Так что вот он настоящий МИФ.
Даже более того единственный миф в этой статье содержится в первом предложении и не пронумерован:
Как известно, наш проект Jelastic создан с целью…
Я готов поспорить, что большинству это не просто неизвестно, а глубоко параллельно и будет забыто через 30 минут после прочтения. Так что вот он настоящий МИФ.
> XOR-подкачкой
swap в данном случае не означает подкачку
речь идет о замене значений двух переменных между собой типа a ^= b ^= a
en.wikipedia.org/wiki/XOR_swap_algorithm
swap в данном случае не означает подкачку
речь идет о замене значений двух переменных между собой типа a ^= b ^= a
en.wikipedia.org/wiki/XOR_swap_algorithm
Надеюсь, это перевод, а не креатив автора ;(
Да, перевод, хотя значка не видно. :(
Автор оригинальной статьи, похоже, прочитал Брукса по-диагонали (причем первое издание) и решил поделится радостью с окружающими…
И ладно бы он понял, что прочитал, но ведь иногда просто ересь пишет…
>>Миф №1: Оффшорная разработка программного обеспечения
>>Звучит все вполне логично: можно задействовать больше разработчиков за меньшие деньги. Значит >>можно закончить проект пораньше, да еще и сэкономить.
>>Но погодите! Это классический пример заблуждения из «Мифического человеко-месяца».
А вот и не погодим. Брукс говорил, что добавление людей В ЗАВЕРШАЮЩУЮ стадию проекта может еще дальше отодвинуть дату завершения. Если решение об аутсорсе принимается до начала проекта, и вы выбираете между местной командой в 10 человек и аутсорсной в 20 человек за те же деньги, то при прочих равных (квалификация) аутсорсеры справятся быстрее.
>>Миф №4: Современные инструменты обеспечивают лучшие результаты
Если память не изменяет, это заявил Брукс в первом издании, а во втором извинился, что был не прав. Развитие IDE и различных библиотек / фреймворков ускорило разработку в разы.
>>Миф №5: Чем больше глаз проверит код, тем меньше багов
Тому, кто считает, что это миф — надо прочитать что такое Code Review.
>>Миф №7: Хороший код — «элегантный» код
Если автор не дает определение «хорошего» кода, то это просто демагогия. В этом плане могу посоветовать книжку «Чистый код».
Автор оригинальной статьи, похоже, прочитал Брукса по-диагонали (причем первое издание) и решил поделится радостью с окружающими…
И ладно бы он понял, что прочитал, но ведь иногда просто ересь пишет…
>>Миф №1: Оффшорная разработка программного обеспечения
>>Звучит все вполне логично: можно задействовать больше разработчиков за меньшие деньги. Значит >>можно закончить проект пораньше, да еще и сэкономить.
>>Но погодите! Это классический пример заблуждения из «Мифического человеко-месяца».
А вот и не погодим. Брукс говорил, что добавление людей В ЗАВЕРШАЮЩУЮ стадию проекта может еще дальше отодвинуть дату завершения. Если решение об аутсорсе принимается до начала проекта, и вы выбираете между местной командой в 10 человек и аутсорсной в 20 человек за те же деньги, то при прочих равных (квалификация) аутсорсеры справятся быстрее.
>>Миф №4: Современные инструменты обеспечивают лучшие результаты
Если память не изменяет, это заявил Брукс в первом издании, а во втором извинился, что был не прав. Развитие IDE и различных библиотек / фреймворков ускорило разработку в разы.
>>Миф №5: Чем больше глаз проверит код, тем меньше багов
Тому, кто считает, что это миф — надо прочитать что такое Code Review.
>>Миф №7: Хороший код — «элегантный» код
Если автор не дает определение «хорошего» кода, то это просто демагогия. В этом плане могу посоветовать книжку «Чистый код».
Миф #1: Программирование — это искусство
Миф #2: Один язык лучше другого, а лопата лучше молотка.
Миф #2: Один язык лучше другого, а лопата лучше молотка.
>>Миф №3: Крутые разработчики в 10 раз продуктивнее остальных
Не всё так однозначно — хорошие разработчики действительно работают на порядок лучше чем плохие.
Дело тут во многом: поставленный процесс разработки, использование правильных инструментов, своевременное проектирование, рефакторинг, тестирование, отладки и т.п.
Возможно действительно не стоит гоняться за суперзвездами, но просто жизненно необходимо иметь (воспитывать) хороших разработчиков, а говнокодеров гнать в шею.
В команде разработчиков должны быть лидеры с хорошим уровнем знаний и опыта, для того, чтобы остальные члены команды обучались.
Не всё так однозначно — хорошие разработчики действительно работают на порядок лучше чем плохие.
Дело тут во многом: поставленный процесс разработки, использование правильных инструментов, своевременное проектирование, рефакторинг, тестирование, отладки и т.п.
Возможно действительно не стоит гоняться за суперзвездами, но просто жизненно необходимо иметь (воспитывать) хороших разработчиков, а говнокодеров гнать в шею.
В команде разработчиков должны быть лидеры с хорошим уровнем знаний и опыта, для того, чтобы остальные члены команды обучались.
А ещё если квалификация разработчика совсем не адекватна сложности проекта, то он просто со 100% вероятностью заходит в тупик (полный срыв всех возможных сроков, невозможность исправить проблемы без полного переписывания кода, выход за предельно возможный бюджет) и время и деньги улетают в трубу.
Да есть такая тема, если разработчик уткнулся в предел своей текущей квалификации, то он может потратить недели на безуспешные попытки решения задачи, которую другой разработчик решит за пару дней. И нет никакого мифа в том, что не все команды состоят из ведущих разработчиков.
Тем более, что это было бы тупо неэффективно, т.к. на простых задачах сеньоры будут скучать, да и прирост производительности там будет не столь ощутим, ведь чем проще задача, тем ниже влияние квалификации.
Тем более, что это было бы тупо неэффективно, т.к. на простых задачах сеньоры будут скучать, да и прирост производительности там будет не столь ощутим, ведь чем проще задача, тем ниже влияние квалификации.
UFO just landed and posted this here
Можно еще добавить список этими мифами о программировании: writeabout.tech/programming/25-most-popular-myths-about-programming-and-developers
Sign up to leave a comment.
7 мифов о программировании