Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
А еще, даже если этот классный разработчик собрался писать код, пусть не забудет про комментирование этого самого кода. Чтобы другие классные разработчики могли сразу «въехать» в проект с минимальными трудозатратами.
Лучше писать код понятным и простым, чтобы не требовались комментарии. А если возникали вопросы по поводу того как он работает, то можно было обратиться к модульным тестам и быстро это понять.
Бывает так что и не все в проекте тестами покрыто. Как раз сейчас достался такой Java-проект
В 80% случаев я с вами согласен. Но иногда комментарии всё же требуются. Недавно смотрел код Twisted (к примеру, код Deferred), там довольно много комментариев, объясняющих суть происходящего (т. е. почему полняется та или иная операция). В таких случаях комментарии мне кажутся весьма полезными.
И этот классный разработчик не сможет пройти собеседования в классную компанию, потому что его там попросят реализовать велосипед, который он обычно брал из библиотек.
Видать не такая классная компания. Меня вот не просили на собеседовании реализовать велосипед в компании, которая в топ-5 компаний украины. Я интенсивно использовал knockout, что и нужно было.
Классные разработчики не проходят собеседования. Они их проводят ;-)
Ох уж эта генерация кода через IDE… В книжке «Pragmatic Programmer» такие вещи называют evil wizards.
Обычно лучше подумать, как сделать так, чтобы код не нужно было генерить. Однако в java приходится возиться с equals и hashCode, либо платиться производительностью за глубокое сравнение через рефлексию.
Обычно лучше подумать, как сделать так, чтобы код не нужно было генерить. Однако в java приходится возиться с equals и hashCode, либо платиться производительностью за глубокое сравнение через рефлексию.
Либо, для java, можно воспользоваться наработками вот этого проекта: projectlombok.org. Ни разу не пожалел что потратил время и внедрил эту библиотеку в проект.
Заголовок не нравится, можно подумать, что он заставляет других писать код вместо себя. А по сути согласен. меньше кода — меньше багов
Самое главное, не это, классный разработчик — просто пишет меньше кода! Какими средствами? Да может пойти и убедить заказчика/PO, что ему эта фигня не нужна или предложить потратить меньше и купить готовое и т.п.
А библиотеки пишут классные разработчики? Да и подключение билиотеки в свой проект — это ведь тоже код? Классный разработчик пишет достаточно кода, просто он мастерски владеет бритвой Оккама.
Имхо, все гораздо проще. Классные разработчики, прежде всего, пишут классный код. Точка. Реюзинг — да, он суть плод классного кода. IDE? Можно создавать классное решение не в IDE, а в душе, во сне, на клочке бумаги, на маркерной доске. Потом уже передать классную разработку классному кодеру и уж он пусть реализует ее в IDE. Ну а первый пункт вообще не выдерживает никакой критики. Немалое число библиотек, которые Вы советуете подключать, никогда бы не появились на свет, если бы их разработчики действовали согласно Вашему принципу. Хотя, может они и не классные. Но определенно такие люди обеспечивают рост индустрии, а не занимаются просто интеграцией.
По поводу написания классного кода я с вами и не спорю. А вот на тему «передать решение классному кодеру, который реализует ее в IDE» — так это вы сейчас про «бумажных архитекторов» рассказываете. Которые могут строить воздушные замки и бла-бла-бла по любому поводу, но идеи свои на практике не воплощают, а просто отдают их «челяди», которая потом с ними мучается.
По поводу первого пункта вы видимо не совсем осознали. Рекомендуется не писать велосипеды без надобности. Библиотеки как раз появились закономерно, потому что отсутствовали публичные решения в этой области. Но писать их заново на каждом проекте смысла нет вообще. Рост индустрии за счет написания библиотек??? Вы о чем? Рост индустрии происходит от роста количества реализованных решений, сервисов и услуг. И чем быстрее они будут реализованы, тем быстрее будет расти рынок. Поэтому те, кто умеет интегрировать и решать поставленную проблему — это правильные разработчики.
По поводу первого пункта вы видимо не совсем осознали. Рекомендуется не писать велосипеды без надобности. Библиотеки как раз появились закономерно, потому что отсутствовали публичные решения в этой области. Но писать их заново на каждом проекте смысла нет вообще. Рост индустрии за счет написания библиотек??? Вы о чем? Рост индустрии происходит от роста количества реализованных решений, сервисов и услуг. И чем быстрее они будут реализованы, тем быстрее будет расти рынок. Поэтому те, кто умеет интегрировать и решать поставленную проблему — это правильные разработчики.
> Библиотеки как раз появились закономерно, потому что отсутствовали публичные решения в этой области.
На рынке практически не осталось «перворожденных» библиотек. Большинство является результатом того, что некий программист рискнул написать велосипед. Сейчас, скажем, на этой странице работает велосипед под велосипедом по имени jQuery. Альтернатив у Ресига было предостаточно.
> Рост индустрии за счет написания библиотек??? Вы о чем?
Библиотеки — это фактическая инкапсуляция идей. Иидустрия, очевидно, растет не за их счет, а за счет их содержимого, библиотека — сосуд.
Давайте так. Вы мне приведите примеры своих классных программистов, ну и я озвучу фамилия всемирно известных деятелй, которые не увлекались IDE, делали велосипеды, но их имена у многих прочно в сознании. И посмотрим, чемй список длинней.
На рынке практически не осталось «перворожденных» библиотек. Большинство является результатом того, что некий программист рискнул написать велосипед. Сейчас, скажем, на этой странице работает велосипед под велосипедом по имени jQuery. Альтернатив у Ресига было предостаточно.
> Рост индустрии за счет написания библиотек??? Вы о чем?
Библиотеки — это фактическая инкапсуляция идей. Иидустрия, очевидно, растет не за их счет, а за счет их содержимого, библиотека — сосуд.
Давайте так. Вы мне приведите примеры своих классных программистов, ну и я озвучу фамилия всемирно известных деятелй, которые не увлекались IDE, делали велосипеды, но их имена у многих прочно в сознании. И посмотрим, чемй список длинней.
Ага, как-то получили ответ от «классного разработчика» по поводу того как он будет решать задачу:
— Я погуглю, если не решения нет, то скажу начальству, что задача не решается.
— Я погуглю, если не решения нет, то скажу начальству, что задача не решается.
Вот это 5 баллов! Думаю, финал истории предугадать нетрудно… :)
> так это вы сейчас про «бумажных архитекторов» рассказываете. Которые могут строить воздушные замки и бла-бла-бла по любому поводу
Во-первых, сразу хочется Вас пожалеть, что вы такого мнения об архитекторах. Вам, видимо, с ними не везло. Да, это люди, которые могут много просчитать в уме, до того как притронутся к клавиатуре, но благодаря им проект не превращается в чан со спагетти-кодом. Сочувствую, что Вам не доводилось работать с достойными представителями. Во-вторых — нет. Классный программист может работать в сфере далекой от архитектуры. Скажем, неделю вынашивать план по оптимизации участка в 100 строк, которой потом будучи раскатанными на тыщи серверов даст миллионные снижения в TCO. Так кто для Вас будет более классным? Программист который дал снижение на $10млн/месяц, но в текстовом редакторе или который не осилил, но сделал это круто, с помощью IDE?
Во-первых, сразу хочется Вас пожалеть, что вы такого мнения об архитекторах. Вам, видимо, с ними не везло. Да, это люди, которые могут много просчитать в уме, до того как притронутся к клавиатуре, но благодаря им проект не превращается в чан со спагетти-кодом. Сочувствую, что Вам не доводилось работать с достойными представителями. Во-вторых — нет. Классный программист может работать в сфере далекой от архитектуры. Скажем, неделю вынашивать план по оптимизации участка в 100 строк, которой потом будучи раскатанными на тыщи серверов даст миллионные снижения в TCO. Так кто для Вас будет более классным? Программист который дал снижение на $10млн/месяц, но в текстовом редакторе или который не осилил, но сделал это круто, с помощью IDE?
Это не я такого мнения, а большая часть людей. Я сам уже много лет занимаюсь архитектурой, но в то же время и реализую ее с командой, а не только «отдаю приказы». Речь шла о архитекторах-теоретиках, которые спускают вниз диаграммы и теоретические решения.
По поводу точечного решения с оптимизацией вы не туда. Речь в статье идет о ежедневной работе, а не о «выстреле», которых у вас может быть за карьеру пару штук всего. А может и не быть.
По поводу точечного решения с оптимизацией вы не туда. Речь в статье идет о ежедневной работе, а не о «выстреле», которых у вас может быть за карьеру пару штук всего. А может и не быть.
Правильно я понял то, что для того чтобы стать «классным разработчиком» лучше поменьше читать про алгоритмы, ООП и про то, как всё устроено внутри, а то, вдруг, захочется что-нибудь написать самому, а не срастить с десяток либ ради примитивной функциональности и не разгребать баги на взаимодействии между либами?
В одной компании, один «классный разработчик» получил задание внедрить проверку орфографии. Проект был на C++, а первая либа в гугле оказалось на Java. Проект стал зависть от JDK инсталлятор увеличился в 10 раз, а проблемы межъязыкового взаимодействия ещё долго вымораживали мозг.
Мне кажется, что «классным разработчиком» вы называете классного прототиписта, который быстро выдаёт черновой функционал, но так и не может добиться приемлемого уровня качества.
В одной компании, один «классный разработчик» получил задание внедрить проверку орфографии. Проект был на C++, а первая либа в гугле оказалось на Java. Проект стал зависть от JDK инсталлятор увеличился в 10 раз, а проблемы межъязыкового взаимодействия ещё долго вымораживали мозг.
Мне кажется, что «классным разработчиком» вы называете классного прототиписта, который быстро выдаёт черновой функционал, но так и не может добиться приемлемого уровня качества.
Отнюдь не так. Как раз читать про алгоритмы, ООП, шаблоны проектирования и т.д. надо побольше. Цель остается прежней — не городить велосипеды там, где это ненужно. Как все устроено внутри вы ознакомитесь, когда будете отлавливать проблемы. А до этого тратить несколько дней рабочего времени на «дай-ка я разберусь как оно там устроено внутри» пока все прекрасно работает просто нет смысла.
Остальные выводы про прототиписта не понимаю с чего вы сделали.
Остальные выводы про прототиписта не понимаю с чего вы сделали.
Автор, Вы сами поняли, что Вы написали?
И, чуть ранее:
Автор, это гениально! Один классный разработчик общается с другими классными разработчиками (ну, а с кем же еще?), а в свободное от взаимоприятственного общения время все эти классные разработчики мечутся в информационном пространстве в поиске готовых решений!
Это называется — провести патентный поиск. Но, в отличие от ПП, коллеги очень постараются вникнуть в идею проекта со всеми вытекающими в условиях рынка и конкуренции последствиями.
Кода должно быть столько, сколько требуется.
Вот поэтому, когда кнопишь код сам, лично, еще попутно и соображаешь.
Если при этом еще использовать технику работы головой — то не очень…
Откуда у описанного Вами разработчика будет интеллект, если он стремится использовать уже готовое — то есть не нарабатывает собственного опыта, рефлексов, интуиции и т.п.?
… Когда он [классный разработчик] сталкивается с новой задачей, то прежде всего анализирует, не получится ли взять сразу готовое решение из существующих.
И, чуть ранее:
Для этого классный разработчик много читает и общается с другими разработчиками, чтобы знать чем богат мир open source решений.
Автор, это гениально! Один классный разработчик общается с другими классными разработчиками (ну, а с кем же еще?), а в свободное от взаимоприятственного общения время все эти классные разработчики мечутся в информационном пространстве в поиске готовых решений!
Он не стесняется спросить совета своих коллег, чтобы воспользоваться еще большим объемом опыта и знаний
Это называется — провести патентный поиск. Но, в отличие от ПП, коллеги очень постараются вникнуть в идею проекта со всеми вытекающими в условиях рынка и конкуренции последствиями.
чем больше кода, тем тяжелее его поддерживать;
Кода должно быть столько, сколько требуется.
чем больше кода, тем вероятнее в нем допущена ошибка;
Вот поэтому, когда кнопишь код сам, лично, еще попутно и соображаешь.
чем больше делается однотипного кода, тем больше вероятность использования техники copy-paste, что стремительно отражается на качестве кода;
Если при этом еще использовать технику работы головой — то не очень…
все задачи не такие уж уникальные, что их никто не реализовал хотя бы частично до текущего момента;
в разработчике ценится его интеллект, а не скорость набора кода;
Откуда у описанного Вами разработчика будет интеллект, если он стремится использовать уже готовое — то есть не нарабатывает собственного опыта, рефлексов, интуиции и т.п.?
Автор, Вы сами поняли, что Вы написали?
Нет конечно, куда мне до уровня понимания того, что пишу…
Автор, это гениально! Один классный разработчик общается с другими классными разработчиками (ну, а с кем же еще?), а в свободное от взаимоприятственного общения время все эти классные разработчики мечутся в информационном пространстве в поиске готовых решений!
А вы в компании общаетесь о разработке с теми, кто в ней совсем не смыслит? Тогда вы так и останетесь на том же уровне. Или у вас нет хороших разработчиков, с которыми можно обсудить решение и пообщаться на тему библиотек, фреймворков, инструментов? Тогда сочувствую…
Это называется — провести патентный поиск. Но, в отличие от ПП, коллеги очень постараются вникнуть в идею проекта со всеми вытекающими в условиях рынка и конкуренции последствиями.
Вы что сидите на каких-то наркотиках, искажающих сознание? Речь шла о том, чтобы перед реализацией своей задумки поделиться ей с коллегами и спросить совета, провести дизайн-сессию. Благодаря этому часто решение становится гораздо лучше, а бывает что и меняется в корне. ПРИ ЧЕМ ТУТ ПАТЕНТНЫЙ ПОИСК И РЫНОК С КОНКУРЕНЦИЕЙ???
Кода должно быть столько, сколько требуется.
Гениально! Это как совет «надо писать только хороший код, а плохой вовсе не писать»…
Вот поэтому, когда кнопишь код сам, лично, еще попутно и соображаешь.
Если при этом еще использовать технику работы головой — то не очень…
Опять КЭП в вас заговорил. Да ну, неужели еще и соображаешь??? Не может быть! Это в корне меняет дело!
Откуда у описанного Вами разработчика будет интеллект, если он стремится использовать уже готовое — то есть не нарабатывает собственного опыта, рефлексов, интуиции и т.п.?
Опыт, интуицию, рефлексы и прочие навыки он нарабатывает на полезном коде, а не на велосипедах, которые не помогают продвигаться к решению задачи. Я видел столько раз самописные ORM-фреймворки, интерграционные решения, кеши, разнообразные утилиты, которые мало того что сожрали кучу проектного времени и не принесли пользы, но и сидели потом как шило в ж… у следующих поколений разработчиков на этом проекте. Зато их авторы наработали себе опыт, рефлексы и интуицию… Чего и вам желаю!
Последнее насчет ORM вообще в точку. Работал в таком проекте, где написали какое-то подобие ORM для дотнета, когда еще не было EF. Потом появился могучий EF, который конечно же со старта давал намного более чем самописная ORM, но проект уже жестко подсел на нее и на EF перейти просто никаких шансов нет. Не спасает даже то, что проблем хватает с этой ORM, их будет еще больше при переходе на EF.
Автор, это гениально! Один классный разработчик общается с другими классными разработчиками (ну, а с кем же еще?), а в свободное от взаимоприятственного общения время все эти классные разработчики мечутся в информационном пространстве в поиске готовых решений!
Именно так! А поскольку «готовые решения» написаны теми, кто «классным разработчиком» ещё не является, то мы имеем то, что имеем… Правда, непонятно, откуда иногда возникают хорошие библиотеки.
Откуда у описанного Вами разработчика будет интеллект, если он стремится использовать уже готовое — то есть не нарабатывает собственного опыта, рефлексов, интуиции и т.п.?
Он их наработал, пока продвигался к своему уровню. А теперь пользуется плодами своего труда. И это вполне естественно.
Всё это давным, давным, давным давно описано у Стива МакКонелла в «Совершенном коде». И там это дано в такой сбалансированной и аккуратной форме, что поспорить невозможно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Классный разработчик не должен писать код, за него пишут другие