Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 150
То ли мне не везет, то ли это все только теория. Мне попадаются только те программисты, которые никогда ничего на листке не рисуют и не чертят, они сразу начинают кодить и через какое то время оказывается что логика где то не сходиться и что то не так.
платишь арахисом, получаешь обезьян
Я Вам сочувствую. В моей команде мы постоянно перед тем как начать решать какую-то задачу, садимся за стол без компьютера, каждый берет по листку бумаги, кладем перед собой описание задачи (ТЗ, пользовательские сценарии) и начинаем обсуждать задачи, дробить всю задачу на мелкие, выделять подзадачи и блоки.
В итоге на бумаге, а самое главное, в голове каждого участника беседы складывается стройное представление последовательности решения задачи, разложены по полочкам подзадачи. И только после этого можно садиться за компьютер и начинать реализовывать проект.
В итоге на бумаге, а самое главное, в голове каждого участника беседы складывается стройное представление последовательности решения задачи, разложены по полочкам подзадачи. И только после этого можно садиться за компьютер и начинать реализовывать проект.
Бумага — не признак хорошего программиста, я раньше часто «думал на бумаге», но уже давно этого не делаю. Я часто начинаю проектировать систему в phpMyAdmin, мне так удобно и наглядно. А программировать начинаю с вставки комментариев типа «инициализация структур хранения», «формирование обработанного документа», «создание индекса» и т.п., потом пишутся эти блоки…
Автор правильно заметил, что кодирование занимает процентов 10% времени, в остальное время думаешь и ищешь решение. Мне, к примеру, лучше всего думается за чисткой картоши и глажкой, благо работаю дома и можно «подумать утюгом» в любое время :)
Автор правильно заметил, что кодирование занимает процентов 10% времени, в остальное время думаешь и ищешь решение. Мне, к примеру, лучше всего думается за чисткой картоши и глажкой, благо работаю дома и можно «подумать утюгом» в любое время :)
Т.е. начинаете проектирование с БД?
во многих случаях это оправдано, особенно в вебе, и особенно, если заранее ориентироваться на определенный фреймворк.
только на счет phpMyAdmin не соглашусь, гораздо удобнее и нагляднее какой-нить визуальный «Database Designer», имхо.
только на счет phpMyAdmin не соглашусь, гораздо удобнее и нагляднее какой-нить визуальный «Database Designer», имхо.
Я не имею ничего против такого подхода, как и любого другого который дает результат.
Я лично — делаю это в дизайнере базы данных EMS SQL Manager, причем в нем сразу можно нажать одну кнопку и вся схема базы ляжет на реальный MySql сервер.
Просто сейчас понемногу этот подход меня уже не так устраивает, потому что приходится менять структуру слишком часто. Я хочу что-то такое чтобы я в одном месте поменял нажал одну кнопку и везде где использовалась эта схема, все поменялось. К этому ближе всего XSD, а к ней ближе всего UML. Но пока что не сообразил как все выстроить.
Я лично — делаю это в дизайнере базы данных EMS SQL Manager, причем в нем сразу можно нажать одну кнопку и вся схема базы ляжет на реальный MySql сервер.
Просто сейчас понемногу этот подход меня уже не так устраивает, потому что приходится менять структуру слишком часто. Я хочу что-то такое чтобы я в одном месте поменял нажал одну кнопку и везде где использовалась эта схема, все поменялось. К этому ближе всего XSD, а к ней ближе всего UML. Но пока что не сообразил как все выстроить.
как минимум MicroOLAP Database Designer и DBDesigner умеют создавать базу по схеме.
symfony с орм Doctrine или Propel умеют генерить базу из схемы в xml или yml из коробки, и кроме того, генерируют ОРМ-классы.
а вот толковые генератоы UI мне не попадались, для реальных пользователей их слишком сильно приходится допиливать, проще самому админку написать.
symfony с орм Doctrine или Propel умеют генерить базу из схемы в xml или yml из коробки, и кроме того, генерируют ОРМ-классы.
а вот толковые генератоы UI мне не попадались, для реальных пользователей их слишком сильно приходится допиливать, проще самому админку написать.
Я когда-то давно пользователся всякого рода программами для проектирования баз данных, но программы часто перегружены излишним функционалом, универсализмом, фичами, которые реально не нужны, а вот по части сторости создания структуры базы данных они, как правило, не выигрываются у phpMyAdmin. Зато phpMyAdmin удобный, заточен под MySQL (другие базы давно не использую), можно поставить на сервере. В общем он мне удобен :)
Да, мне удобно таким образом «визуализировать» систему.
О. Не я один с комментариев сложные алгоритмы начинаю делать :)
ИМХО это лучший способ, когда не знаешь с чего начать задачу.
Эдакий Comment Driven Development.
ИМХО это лучший способ, когда не знаешь с чего начать задачу.
Эдакий Comment Driven Development.
Для этого есть ORM разные. Если модель данных меняется, то тогда удобно применять миграции — очень удобно. Хотя тут, возможно как раз моторика важна — надо мышкой возюкать.
Я, например, часто беру бумажку и рисую «каляки-маляки», пока в голове разные параметры и объекты крутятся, собираются в разные структуры, «тестируются», разбираются и собираются снова… трудно объяснить, как это происходит, т.к. процесс не формализуемый с не формализованными данными, но потом садишься, и код пишется легко и непринужденно. Еще хорошо думается в ванной и за рулем, хотя заметил, что за рулем это делать небезопасно, т.к. иногда бывает, что отключаешься на пару секунд от восприятия действительности (в ванной или сидя за столом этого не замечаешь), и можно аварийную ситуацию создать.
Я, например, часто беру бумажку и рисую «каляки-маляки», пока в голове разные параметры и объекты крутятся, собираются в разные структуры, «тестируются», разбираются и собираются снова… трудно объяснить, как это происходит, т.к. процесс не формализуемый с не формализованными данными, но потом садишься, и код пишется легко и непринужденно. Еще хорошо думается в ванной и за рулем, хотя заметил, что за рулем это делать небезопасно, т.к. иногда бывает, что отключаешься на пару секунд от восприятия действительности (в ванной или сидя за столом этого не замечаешь), и можно аварийную ситуацию создать.
во насрали)) так держать)) ещё разок, пожалуйста! а хуле?
Это как раз таки нормальный рабочий процесс. Такие вот бумажкомаратели очень часто тратят кучу времени на всякие графики, схему и прочую бесполезную хрень, в результате чего создают совершенно зубодробительную и избыточную архитектуру, которую потом реализуют в виде тонн говнокода. Я считаю, что если программист не может удержать архитектуру своей системы в голове, значит её, архитектуру, можно и нужно упрощать.
Это когда проект одного программиста, а когда команда? Где та голова, которая будет содержать связи между кусками? Вот ему то и требуется бумажка с моделями, что бы свою команду поделить и процесс программирования шел одновременно у всех, и они бы не мешали друг другу, а так же не задавали глупых вопросов.
Значит, вам не попадались приложения с действительно сложной архитектурой.
О, поверьте, я бы не стал говорить, если бы не попадались :) В течение года я работал над проектом, который изначально делала аутсорсинговая фирма. Там было несколько толстенных, и абсолютно бесполезных документов, описывающих архитектуру и взаимодействие компонентов (с юзкейсами, sequence диаграммами и прочими атрибутами серьёзной системы. Когда я только пришёл на проект, я очень впечатлился этими фолиантами и даже распечатал их. Как выяснилось позже, я только зря потратил бумагу с тонером, так как эти документы абсолютно ничего не проясняли, и даже наоборот — запутывали. Кроме того, система была спроектирована так, будто разработчики поставили себе целью использовать абсолютно все технологии и паттерны, которые только нашлись в их конспектах с курсов по Java. В результате, фирме-заказчику постоянно приходилось наращивать серверные мощности, из-за того, что по мере заполнения БД этот монстр работал всё медленнее и медленнее. А на то, чтобы сделать глобальный редизайн, не было времени и ресурсов.
Я, конечно, немножко погорячился в первом камменте :) При работе в команде нужно вырабатывать какие-то общие правила и основы архитектуры. Только всё это должно проходить без фанатизма. А то бывает так, что абстракшн гики разрисовывают красивые иерархии наследования, интерфейсы и прочую муть в то время, когда от них всего лишь требуется написать “Hello world”.
Я, конечно, немножко погорячился в первом камменте :) При работе в команде нужно вырабатывать какие-то общие правила и основы архитектуры. Только всё это должно проходить без фанатизма. А то бывает так, что абстракшн гики разрисовывают красивые иерархии наследования, интерфейсы и прочую муть в то время, когда от них всего лишь требуется написать “Hello world”.
Когда читаю такие текста и вижу что Отличный Программист — он как минимум спаситель вселенной.
Чак Норис курит в стороне, а одной кнопокой они переворачивают жизни людей. А женщины сами падают на колени перед ними.
Чак Норис курит в стороне, а одной кнопокой они переворачивают жизни людей. А женщины сами падают на колени перед ними.
Дэвид Векслер = Кэп.
Статья мотивирует меньше писать, но больше делать. А для этого надо становиться лучше.
Малоизвестные?! Ну это смотря кому… да любой программист это знает, просто не говорит.
я себе сформулировал 3 проблемы программистов:
1. не умеют читать (часто не видишь или не понимаешь то что написано в коде)
2. не умеют считать (индексы в массивах и номера символов в строках — неиссякаемый источник ошибок)
3. пишут код методом копирования (копипаст убивает любоцй дизайн и код)
1. не умеют читать (часто не видишь или не понимаешь то что написано в коде)
2. не умеют считать (индексы в массивах и номера символов в строках — неиссякаемый источник ошибок)
3. пишут код методом копирования (копипаст убивает любоцй дизайн и код)
>1. не умеют читать (часто не видишь или не понимаешь то что написано в коде)
ну ИМХО это ваша проблема что вы не видите что написано в их коде, или иначе они не могут писать, но никак не читать
>3. пишут код методом копирования (копипаст убивает любоцй дизайн и код)
сейчас чувствую начнутся холивары (мое мнение копипаст в малых дозах безвреден при любом количестве :) нужно просто видеть картину целиком того что делаешь, чтобы знать где его уместно применить, а где нет)
ну ИМХО это ваша проблема что вы не видите что написано в их коде, или иначе они не могут писать, но никак не читать
>3. пишут код методом копирования (копипаст убивает любоцй дизайн и код)
сейчас чувствую начнутся холивары (мое мнение копипаст в малых дозах безвреден при любом количестве :) нужно просто видеть картину целиком того что делаешь, чтобы знать где его уместно применить, а где нет)
На этапах багфикса я почти всегда могу свести проблему к 1 из указанных 3 проблем.
Поскольку участвую в проектах, где занято более 1000 человек, то прихожу к выводу что везде так, ибо 1000 программеров — выборка довольно репрезентативная.
Поскольку участвую в проектах, где занято более 1000 человек, то прихожу к выводу что везде так, ибо 1000 программеров — выборка довольно репрезентативная.
1000 программистов в одном проекте? Можно проект озвучить? :-)
Проект разрабатывался несколько лет и конечно не сразу 1000 программистов поучаствовали. Но в среднем столько приложили к нему руку.
Проект был связан с разработкой Java ME virtual machine.
Проект был связан с разработкой Java ME virtual machine.
Солидно :-) Завидую :-)
Вот пример из жизни 1 мин назад произошел.
Сидит чувак — втыкает в код. Код не работает. Зовет меня и кричит, что код не работает хрен знает почему, а должен работать.
Я подхожу. Он тычет пальцем в строку
int length = (arr[i] > 0? 0: arr[i])
Ошибка простая — ему показалось, что стоит знак «меньше», а в коде явно написано «больше».
сработал 1 принцип — программист не умеет читать.
Сидит чувак — втыкает в код. Код не работает. Зовет меня и кричит, что код не работает хрен знает почему, а должен работать.
Я подхожу. Он тычет пальцем в строку
int length = (arr[i] > 0? 0: arr[i])
Ошибка простая — ему показалось, что стоит знак «меньше», а в коде явно написано «больше».
сработал 1 принцип — программист не умеет читать.
видимо этому программисту пора в отпуск или хотя бы домой
Иногда и умея читать можно допускать страшные косяки.
Восклицательный знак после скобки совсем не бросается в глаза, а результат выполения меняется на прямо противоположный
К слову строка
if (!length!=3) doSomething();
Восклицательный знак после скобки совсем не бросается в глаза, а результат выполения меняется на прямо противоположный
К слову строка
not length!=3 and doSomething()подобных минусов не имеет
>Восклицательный знак после скобки совсем не бросается в глаза, а результат выполения меняется на прямо противоположный
поэтому я приучил себя писать
if (! length != 3 ) doSomething();
Отсутствие ошибок не гарантирует, но как минимум заметить проще.
поэтому я приучил себя писать
if (! length != 3 ) doSomething();
Отсутствие ошибок не гарантирует, но как минимум заметить проще.
>К слову строка
> not length!=3 and doSomething()
> подобных минусов не имеет
Строка
минусов не имеет, а два отрицания — от лукавого.
> not length!=3 and doSomething()
> подобных минусов не имеет
Строка
if (length == 3) минусов не имеет, а два отрицания — от лукавого.
Не бедные индийские юноши, случайно? А то и мне кажется подозрительным, что «не умеют читать» :)
В такой громадине и ни разу не возникло хотя бы проблем совместимости компонентов между собой? Только индексы?
В такой громадине и ни разу не возникло хотя бы проблем совместимости компонентов между собой? Только индексы?
Почитайте книгу про анти-паттерны, там есть это и многое другое.
Плохие же пишут код, которому недостаёт концептуальной целостности, лаконичности, иерархичности, шаблонов проектирования, и его невероятно сложно рефакторить.
Код ни в коем случае не должен считаться плохим из-за того что в нём не хватает паттернов. Паттерны — это не цель, а средство.
Иерархичность — есть немало фанатов которые доводят здесь дело до полного абсурда и городят иерархии там где это явно излишне.
Проще выбросить плохой код на помойку и начать заново, чем что-то менять в нём.
Это верно, но опять-таки — главное, без фанатизма. Часто бывает так, что проект переписывается с нуля на том основании что «там всё криво». Хотя на само деле — не все так плохо, просто не любит программист изучать чужой код.
Было бы замечательно, если бы вы написали это автору статьи в виде комментария к оригиналу статьи. Паттерны разумеется не цель, но плохой код обычно их не содержит. С другой стороны, хороший код их содержать не обязан, однако я слышал интересную мысль о том, что хороший программист использует паттерны автоматически, возможно, даже не подозревая о них. Об этом, кстати, в статье тоже есть намёк.
По поводу помойки скажу одно — я лично видел код, который проще переписать, и не раз :) Но да, конечно без фанатизма.
По поводу помойки скажу одно — я лично видел код, который проще переписать, и не раз :) Но да, конечно без фанатизма.
«Иерархичность — есть немало фанатов которые доводят здесь дело до полного абсурда и городят иерархии там где это явно излишне.»
Это точно. Ну и в любом случае, как по мне, если говорить про иерархичность — было бы здорово следовать принципу «Composition over Inheritance».
Это точно. Ну и в любом случае, как по мне, если говорить про иерархичность — было бы здорово следовать принципу «Composition over Inheritance».
По любому, каждый лентяй, прочитав статью подумал: «Да, это про меня».
программисты думают о работе 24 часа 7 дней в неделю
Сомнительное утверждение, т.к. все таки неэффективно круглосуточно думать о работе. Но статья хорошая, напомнила эту статью из Joel on Software .
Парсер лохонулся. Ссылка не прикрепилась.
russian.joelonsoftware.com/Articles/HighNotes.html
russian.joelonsoftware.com/Articles/HighNotes.html
Ни разу не сомнительное. Чтобы создать что-то действительно хорошее, надо быть увлеченным идеей, надо её обдумывать по дороге на работу, по дороге домой, надо прогонять множество вариантов в уме (и не обязательно это делать перед монитором).
Чтобы реализовать что-то действительно «красиво», надо потратить много времени на проектирование и обдумывание, а это проще делать, когда не видишь перед собой экран. В идеале лучше сесть в кресле, закрыть глаза, расслабиться и просто думать. Потом взять листок бумаги и на нём изложить свои мысли. И только после этого садиться за компьютер.
Более того, обдумывание в режиме 24\7 позволяет не упускать проблему из головы, потому что стоит отвлечься и уже надо заново вспоминать на чем остановился. У меня не раз было такое, что решение проблемы, которую пытался решить несколько недель приходило во сне!
Чтобы реализовать что-то действительно «красиво», надо потратить много времени на проектирование и обдумывание, а это проще делать, когда не видишь перед собой экран. В идеале лучше сесть в кресле, закрыть глаза, расслабиться и просто думать. Потом взять листок бумаги и на нём изложить свои мысли. И только после этого садиться за компьютер.
Более того, обдумывание в режиме 24\7 позволяет не упускать проблему из головы, потому что стоит отвлечься и уже надо заново вспоминать на чем остановился. У меня не раз было такое, что решение проблемы, которую пытался решить несколько недель приходило во сне!
Речь идёт скорее не о работе, а о размышлениях о текущей задаче. Я регулярно ловлю себя на мыслях о текущих проектах, о том, что вот это было бы неплохо сделать так-то, а вот то, наверное, лучше убрать, здесь переписать, а там подправить. Общие абстракции, только и всего. Реально помогает найти правильное решение.
гм, в ващем варианте отладка равна кодингу.
а обычно случаются резкие перекосы как в одну, так и в другую сторону.
Зависит от первоначального обдумывания и подготовки
а обычно случаются резкие перекосы как в одну, так и в другую сторону.
Зависит от первоначального обдумывания и подготовки
В пределе высокоуровнеый программист просто сидит в кресле и медитирует, да.
Венец эволюции, да :)
эх, а у нас отчетность по времени :(
Надо справа в график добавить маленький треугольник медитации надо своим кодом
И в реальной жизни не существует. Это такое же понятие, как КПД=100% или абсолютно чёрное тело.
ॐ
Техническая система идеальна, если ее функция выполняется, но самой системы нет. :)
Техническая система идеальна, если ее функция выполняется, но самой системы нет. :)
Это называется программирование без сайд-эффетов
Очень и весьма неправдоподобная схема. Хороший программист дает больше (годных) результатов, и плевать какое у него отношение чего к чему. Иначе говоря, если у программера больше кодинга+отладки, чем обдумывания, это еще не значит что он хуже, чем тот который ТАК много (долго?) думает. Есть в конце концов TDD, в котором обдумывание происходит во время кодинга (попробовал — получилось — оставил).
Опять же, чем выше уровень тем меньше думать над тривиальными решениями, ановые велосипеды сложные задачи не так часто попадаются.
Считаю что при увеличении уровня пропорции остаются такими же, а растет только количество результатов за единицу времени.
Опять же, чем выше уровень тем меньше думать над тривиальными решениями, а
Считаю что при увеличении уровня пропорции остаются такими же, а растет только количество результатов за единицу времени.
Как вы заметили на схеме результатов нет, поэтому ваш вывод о неправдоподобности неверен.
Можно добавить третье измерение — качество результата, но там ничего особо интересного не будет — просто растущая кривая.
Можно добавить третье измерение — качество результата, но там ничего особо интересного не будет — просто растущая кривая.
Качество результата (субъективное понятие) должно быть уже включено в кодинг. Ведь в результате мы считаем полностью готовый код, нет? Иначе это всё равно как сказать «я набираю 300 знаков в минуту, только херня выходит».
Мне кажется что правильная схема выглядит так:
И, имхо, это вполне логично, что кодинг, он же результат (!) работы программиста, тем выше, чем выше его скилл. И наоборот, будь ты хоть семи пядей во лбу, без результатов ты только теоретик. Любой практик (пускай и наступающий на свои грабли, но выдающий в итоге больше результата) окажется полезнее чем такой «высокоуровневый» философ.
Мне кажется что правильная схема выглядит так:
И, имхо, это вполне логично, что кодинг, он же результат (!) работы программиста, тем выше, чем выше его скилл. И наоборот, будь ты хоть семи пядей во лбу, без результатов ты только теоретик. Любой практик (пускай и наступающий на свои грабли, но выдающий в итоге больше результата) окажется полезнее чем такой «высокоуровневый» философ.
не путайте кодеров и программистов. для кодера ваша схема верна.
А какие же у программистов цели? разве не получение кода?
Не путаете ли вы программистов и «архитекторов»?
Не путаете ли вы программистов и «архитекторов»?
Зависит от размера проекта и его структуры. Если проект маленький — на человека, или модульный, где отдельные модули пишутся отдельными программистами, то там программистом сам себе архитектор и сам себе кодер.
Как утверждает википедия
«Программист — специалист, занимающийся написанием программ для ЭВМ[1], т.е. программированием.»
Собственно написание кода это и есть плод работы данного специалиста.
OleGG как-то нездорово дифференцирует «кодеров» (типа обезьяна с печатной машинкой) и «программистов» как высокоуровневых существ управляющих осмысленным поведением первых.
Хотя на самом деле это одно и тоже.
«Программист — специалист, занимающийся написанием программ для ЭВМ[1], т.е. программированием.»
Собственно написание кода это и есть плод работы данного специалиста.
OleGG как-то нездорово дифференцирует «кодеров» (типа обезьяна с печатной машинкой) и «программистов» как высокоуровневых существ управляющих осмысленным поведением первых.
Хотя на самом деле это одно и тоже.
мне почему-то казалось, что у программистов цель достичь результата, а не процесс (читайте как способ) достижения результата (код).
Как правило каждый новый проект на 80% состоит из рутины, которую писать неинтересно, но надо. И если большую часть времени над этой рутиной думать, то ресурсов нужно будет нереально много. При этом поручить рутину младшеньким тоже не правильно — совокупность мелких решений влияет на общий дизайн и нужно учитывать все эти ньюансы.
Такое впечатление, что никто из минусовавших не пробовал TDD. Мозгование в TDD не занимает много времени — пиши работающий код с тестами, потом рефактори — а результаты обычно выходят скоро и качественно. Легко тестируемая архитектура и есть обычно самая лучшая. А все эти «неделю мозгую а потом за день напишу больше чем все вместе взятые» — ерунда, таких программистов нужно гнать в шею. Их «рожденный теорией идеальный» код обычно не идеальнее, чем «быстро написанный и отрефакторенный», но определенно в два-три раза дольший по времени.
Нет я не говорю что всегда надо писать быстро, но комплексные решения не каждый день перепродумывается, чтобы 6/8 времени в день просиживать на кухне.
Такое впечатление, что никто из минусовавших не пробовал TDD. Мозгование в TDD не занимает много времени — пиши работающий код с тестами, потом рефактори — а результаты обычно выходят скоро и качественно. Легко тестируемая архитектура и есть обычно самая лучшая. А все эти «неделю мозгую а потом за день напишу больше чем все вместе взятые» — ерунда, таких программистов нужно гнать в шею. Их «рожденный теорией идеальный» код обычно не идеальнее, чем «быстро написанный и отрефакторенный», но определенно в два-три раза дольший по времени.
Нет я не говорю что всегда надо писать быстро, но комплексные решения не каждый день перепродумывается, чтобы 6/8 времени в день просиживать на кухне.
80% рутины получается как раз если не думать. А если думать, то ее будет процентов 20. Как раз самое то, чтобы дать мозгам отдохнуть (или чтобы посадить на эту рутину студента).
И если думать, то и тесты будут куда как более адекватными. Видал я результаты бездумного применения TDD — жалкое, душераздирающее зрелище!
И если думать, то и тесты будут куда как более адекватными. Видал я результаты бездумного применения TDD — жалкое, душераздирающее зрелище!
Я лучше пять часов подумаю и потом за 20 минут напишу более функциональный код, чем получился бы, если бы я все 5 часов просто кодировал. Он еще и в двадцать раз короче при этом получится.
Интересный вы работник. Смотрите, 20 минут писанины и 05:20, разницей будет некоторое увеличение функционала. При этом учитывая то, что за 20 минут вы набросаете скажем максимум 150 строчек, то лишнего функционала у вас там слишком много и не будет, плюс это еще неизвестно нужен ли он (сэйлзам) или нет. А теперь скажите, кто ценнее, вы — который за целый день сделал рядовую фичу «архикачественно» или другой который за то же время сделал 8-16 таких рядовых задач? Если кажется что вы всё еще круты, то ответьте на этот же вопрос учитывая что такой же показатель держится целый год (т.е. условно говоря качество кода других не так уж и далеко от идеального, либо его модно быстро модифицировать под новые требования).
Вы тратите время комманды на то, что интересно лично вам. Другим это тоже было бы интересно, но они в это время заняты рутиной, которая по закону Парето составляет 80% проекта и, соответственно, сдвигает его вперед в 5 раз быстрее чем вы с глубоким копанием.
Вы тратите время комманды на то, что интересно лично вам. Другим это тоже было бы интересно, но они в это время заняты рутиной, которая по закону Парето составляет 80% проекта и, соответственно, сдвигает его вперед в 5 раз быстрее чем вы с глубоким копанием.
Вы о программировании говорите, или о формошлёпстве? К формошлёпству ваши слова еще (с очень-очень большой натяжкой) применить можно. К программированию — нельзя.
Я пишу компиляторы. Так что, соотношение именно такое, как я описал. Или я сяду тупо кодировать какую либо ad hoc оптимизацию, которая мне в башку пришла, или даже известную оптимизацию, но сделаю в лоб, то получится много весьма бестолкового кода. А если я сяду с бумажкой и ручкой, и буду долго думать, то в конце концов получится 100 строк очень качественного, вылизанного кода, которые будут делать ту же оптимизацию, но гораздо эффективнее.
К вопросу о рутине — я её автоматизирую. Я подумаю пару часов и за 10 минут сделаю автомат, который одну и ту же рутинную операцию потом будет месяцами выполнять, и это намного лучше чем если я каждый день на эту же рутину буду тратить час.
Я пишу компиляторы. Так что, соотношение именно такое, как я описал. Или я сяду тупо кодировать какую либо ad hoc оптимизацию, которая мне в башку пришла, или даже известную оптимизацию, но сделаю в лоб, то получится много весьма бестолкового кода. А если я сяду с бумажкой и ручкой, и буду долго думать, то в конце концов получится 100 строк очень качественного, вылизанного кода, которые будут делать ту же оптимизацию, но гораздо эффективнее.
К вопросу о рутине — я её автоматизирую. Я подумаю пару часов и за 10 минут сделаю автомат, который одну и ту же рутинную операцию потом будет месяцами выполнять, и это намного лучше чем если я каждый день на эту же рутину буду тратить час.
TDD на ранних стадиях действительно увеличивает количество времени на кодинг, но это не должно, по-моему, быть в порядке вещей. В целом я пришел к выводу, что TDD может существенно замедлить работу, т.к. начинаешь уже каждую пустяковую функцию и алгоритм, который первый в голову придет, втыкать(отлаженным) в код. По идее этот недостаток больше относится к платформе, на которой работает программер, а не к самому программисту. Это опять-таки мо1 мнение.
Супер-программисту уже не надо писать код!
Он думает-думает-думает, а потом компилирует и исполняет его прямо в голове!
Он думает-думает-думает, а потом компилирует и исполняет его прямо в голове!
По графику видно, что как не крути, с работы пораньше не уйдёшь.
Ну, график несколько некорректный. Многочисленные измерения показывают, что средний инженер продуктивен в лучшем случае 4 часа в день. Остальное время он пинает балду, чаи гоняет, делает вид, что думает (без результата), интернет читает, журнальчики. Если всю эту деятельность исключить, то можно уходить домой и раньше.
Вот самая удачная аналогия программистской работы, с которой я сталкивался.
объясните мне, пожалуйста, как вот это утверждение:
может сосуществовать вот с этим утверждением:
поясню мысль — если любой программист, независимо от уровня, пишет 10-12 строк в день (которые попадают в конечный продукт — !), то откуда вообще берется разделение good — bad — ugly?
Программист тратит 10-20% своего времени на написание собственно кода, и большинство программистов пишут всего 10-12 строк кода в день, которые попадают в конечный продукт, независимо от их уровня.
может сосуществовать вот с этим утверждением:
Хороший программист в 10 раз более продуктивен, чем средний. Отличный программист в 20-100 раз более продуктивен, чем средний.
поясню мысль — если любой программист, независимо от уровня, пишет 10-12 строк в день (которые попадают в конечный продукт — !), то откуда вообще берется разделение good — bad — ugly?
продуктивность программиста вообще никак не зависит от количества линий кода
ага, только вот количество линий кода зависит от продуктивности.
В оригинале написано «большинство программистов», где вы там увидели «любой программист, независимо от уровня»?
Функциональность не пропорциональна числу строк кода.
У трусов популярностью пользуется слудющее изречение: «Искусный полководец одерживает победу без боя. Величайший воин не воюет».
У туповатых программистов, которые не могу писать в день больше 12 строк хорошего кода, теперь тоже есть, что процитировать.
У туповатых программистов, которые не могу писать в день больше 12 строк хорошего кода, теперь тоже есть, что процитировать.
пошёл увольняться…
Я — плохой программист. Пишу много оптимизированного многопоточного SIMD кода. Сложного для понимания и поддержки. Часто много времени трачу на отладку и мало на обдумывания, так как обычно сразу выбираю оптимальный вариант. Без измерений и обоснований.
А можно ссылку на оригинал?
Эта статья заставляет меня верить что я хороший программист.
Восхищаюсь программистами! Еще в Фидо читал рассказ «История одного байта». Производит впечатление!
Написал 12 строк, чувствую себя профессионалом, до вечера буду думать!
Походу, то ли производительность повышается, то ли погрешности измерений…
Лет 10 назад читал исследование, по которому получалось, что средний квалифицированный программист пишет 8 итоговых строк проекта за день. Правда, подразумевалось не буквальное написание за день, а отношение числа строк в готовом проекте, поделённое на время написания и число программистов.
У меня, я как-то, несколько лет назад подсчитывал суммарный объём кода за пару лет работы, как раз 12 строк в день вышло :)
Лет 10 назад читал исследование, по которому получалось, что средний квалифицированный программист пишет 8 итоговых строк проекта за день. Правда, подразумевалось не буквальное написание за день, а отношение числа строк в готовом проекте, поделённое на время написания и число программистов.
У меня, я как-то, несколько лет назад подсчитывал суммарный объём кода за пару лет работы, как раз 12 строк в день вышло :)
10-12 строк кода — это уже во время сопровождения системы.
Когда создается новый функционал, кода неизбежно будет много больше.
Когда создается новый функционал, кода неизбежно будет много больше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Некоторые малоизвестные факты о программировании