Comments 75
Прочитал название и взгуснул :'-\
«но писать код с нуля под скептическим взглядом сотрудника!»
А как же парное программирование? Макконнелл этот подход в «Совершенном коде» очень нахваливает. Да и входящая в моду (если уже не вошедшая) agile-разработка при командной работе подразумевает довольно тесную связь членов этой самой команды друг с другом.
А как же парное программирование? Макконнелл этот подход в «Совершенном коде» очень нахваливает. Да и входящая в моду (если уже не вошедшая) agile-разработка при командной работе подразумевает довольно тесную связь членов этой самой команды друг с другом.
Не приучена :-)
От парности, процесс менее интимным не становится %)
Это уже почти эксбиционизм! ;)
Иногда бывает что программирую в паре (редко раз в 3 месяца) но каждый раз это очень полезный опыт и продуктивность однозначно растет…
Парное программирование — это здорово! Мне всегда приходит в голову аналогия, простите, с ралли, когда команда состоит из штурмана и рулевого. В нашем случае рулевой пишет и в этот момент выполняет преобразование типа мысль-код. Для контроля ошибок он должен выполнить обратное преобразование — код-мысль — и сделать diff. Однако, во-первых, когда это случится, он уже успеет немало написать. А во-вторых, подлый моск пытается оптимизировать процесс и сразу подставить исходную мысль как результат. Фиг ли, не мог же он ошибиться в транслировании мысли? Но штурман просто вынужден произвести честное преобразование код-мысль и тут же ловит десяток-другой исключений, о которых и сообщает рулевому, вовремя корректируя его полет маршрут код. Жаль только, что сложно объяснить начальству, почему два программиста заняты одной и той же работой. Поэтому мы у себя пользуемся этим методом редко.
Одна голова хорошо, а две лучше :-) Мы, например, очень широко используем в своей практике парное программирование и обычно код, написанный таким образом, значительнее продуманнее и стабильнее.
2 головы хорошо, а еще больше голов еще продуманнее и стабильнее?
Брукс в «Мифическом человеко-месяце» так не считает (и вполне оправданно):
Если есть N программистов и количество пар программистов N(N-1)/2, то с ростом числа программистов затраты времени на взаимодействие растут квадратично. Поэтому, начиная с какого-то N, рост числа программистов замедляет выполнение проекта.
Есть критическая масса.
Тёплое парно́е программирование. Ммм… Что может быть лучше :)
Есть такое дело. Кстати, касается всех — и программистов, и сисадминов, и даже менеджеров проектов.
Ну, наверное, я жил в другое время. Спасибо доброй памяти моему учителю, который меня очень многому научил. Да и я, надеюсь, хоть что-то дал своим младшим коллегам, которые сейчас в других городах и странах.
Второй абзац — в точку! Порой мне кажется мы и сами иногда не представляем каким огромным багажом знаний и умений мы, как программисты, обладаем. Многие дела которые приходится делать сами по себе настолько рутинны, что становятся просто незаметными, мы не заостряем на них свое внимание.
Не совсем согласен с автором.
Программирование — это во многом поток сознания. Во время написания одной функции я могу внезапно вспомнить, что не дописал что-то в другую, вызов которой только что записал — я кинусь к ее объявлению и начну править. В отличие от сапожника, программисту нужно держать огромное количество информации в голове, а для подмастерья уследить за полетом мысли мастера бывает практически невозможно.
Так что изучать программирование лучше по гайдам вроде Why's Poignant Guide to Ruby или Learn You a Haskell For Great Good!, которые учат получать удовольствие от процесса написания кода, тем самым подталкивая к самостоятельному изучению.
Программирование — это во многом поток сознания. Во время написания одной функции я могу внезапно вспомнить, что не дописал что-то в другую, вызов которой только что записал — я кинусь к ее объявлению и начну править. В отличие от сапожника, программисту нужно держать огромное количество информации в голове, а для подмастерья уследить за полетом мысли мастера бывает практически невозможно.
Так что изучать программирование лучше по гайдам вроде Why's Poignant Guide to Ruby или Learn You a Haskell For Great Good!, которые учат получать удовольствие от процесса написания кода, тем самым подталкивая к самостоятельному изучению.
а по скринкастам изучать еще лучше и приятней :)
и на все 100% соглашусь со словами Nicolette
Вот простой пример со своего прошлого: когда только начал работать в команде сразу же продуктивность написания кода заметно возросла! (я о качестве пока не пишу :) ) Так как работая в команде пришлось наблюдать процесс разработки другими программистами и многому чему учится (это о приемах использования инструментов). А когда уже стал менеджером проектов, то научился разным подходам к проектированию приложений. Конечно можно читать гайды, но это будет намного дольше и менее ефективней, чем просто увидеть работу других. Можно ведь учиться вырезать из дерева и по книжке, но намного проще приятней и проще быть подмастерьем.
и на все 100% соглашусь со словами Nicolette
Вот простой пример со своего прошлого: когда только начал работать в команде сразу же продуктивность написания кода заметно возросла! (я о качестве пока не пишу :) ) Так как работая в команде пришлось наблюдать процесс разработки другими программистами и многому чему учится (это о приемах использования инструментов). А когда уже стал менеджером проектов, то научился разным подходам к проектированию приложений. Конечно можно читать гайды, но это будет намного дольше и менее ефективней, чем просто увидеть работу других. Можно ведь учиться вырезать из дерева и по книжке, но намного проще приятней и проще быть подмастерьем.
Возможно продуктивность возросла из-за «эффекта Зайонца»? Присутствие наблюдателя повышает мотивацию и производительность улучшается (впрочем для некоторых людей эффект обратный). Ничто ведь не мешает учиться и без других людей, причем очень часто это даже более полезно, например когда получается вникнуть в суть и потрать на что-то в разы больше времени, а не на лету перехватить что-то без глубокого понимания (ну или вам забудут рассказать про подводные камни, а сами вы и не догадаетесь).
Странный топик. До того, как нажал на хабракат, думал что это лишь предисловие к чему-то большему. Осталось впечатление как от введения без продолжения.
Про интимность написания кода верно подмечено. Мне, к примеру, гораздо большее удовольствие доставит демонстрация готового результата коллегам или заказчику, нежели выставление на показ процесса… Хотя методом решения той или иной задачи или готовой функцией можно поделиться, когда ты точно знаешь, что код рабочий :-)
Если готовым результатом считать готовый код, то получается сode review:
www.youtube.com/watch?v=sMql3Di4Kgc
И интимность соблюдается и почерпнуть друг у друга из кода можно многое.
www.youtube.com/watch?v=sMql3Di4Kgc
И интимность соблюдается и почерпнуть друг у друга из кода можно многое.
>а все остальные плотники работают в отдельных закрытых комнатах.
совершеннейшая глупость.
>Благодаря качественному открытому ПО мы можем ознакомиться с результатами работы программистов первой лиги — просто загрузите исходники и вчитайтесь. А как насчет составляющих?
в опенсорс прожектах нужно *участвовать*, а не просто загружать исходники — тогда и недоотлаженные версии в репозитарии будет видно и конфигами для вима поделятся и разные интересные истории в irc расскажут.
опенсорц — это не исходники, это люди и культура
совершеннейшая глупость.
>Благодаря качественному открытому ПО мы можем ознакомиться с результатами работы программистов первой лиги — просто загрузите исходники и вчитайтесь. А как насчет составляющих?
в опенсорс прожектах нужно *участвовать*, а не просто загружать исходники — тогда и недоотлаженные версии в репозитарии будет видно и конфигами для вима поделятся и разные интересные истории в irc расскажут.
опенсорц — это не исходники, это люди и культура
Достаточно поработать в команде, чтобы понять, что в посте написан бред.
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
Например, вот здесь sites.google.com/site/petrmitrichevtorrents/all (если я ничего не путаю — ссылка взята из forums.topcoder.com/?module=Thread&threadID=684938).
Для меня эта статейка как раз в сердце. Если чесно никогда не где не учился а все познавал сам, первые пробы программирования на калькуляторе, потом Спектрум. Теперь вот пишу сайты и если чесно регулярно задумываюсь а как оно а что, а делаю ли я правильно, грамотно. Потом конечно по уже результату все в восхищении, сам тащюсь но мне все кажется что все еще все плохо, что та функция или метод которая ранее была на 100 строчек кода а теперь на 3 это еще не оптимизация и все пишу и пишу до бесконечности раз в год понимая что ранее делал все сложно и нужно все еще более упощать и переписываю все с нуля :-) А все от чего такие мысли? Просто не прихожилось не с кем работать, все во круг настроеные только рубить капусту выпуска откровенно некачественный продукт. С такими я и не общаюсь а так поглядеть самое оно — анализировать работы других, чужие классы, отыскивать и в них что переделать — так и учусь.
>>Благодаря качественному открытому ПО мы можем ознакомиться с результатами работы программистов первой лиги — просто загрузите исходники и вчитайтесь
да простит меня глубокоуважаемый переводчик, но смотреть 300+ мб исходников мозиллы только врагу можно пожелать.
а по поводу первой лиги я бы то же не был так уверен. Подумайте на досуге? почему чемпионы мира и чемпионы олимпийских игр далеко не всегда одни и те же люди ;)
да простит меня глубокоуважаемый переводчик, но смотреть 300+ мб исходников мозиллы только врагу можно пожелать.
а по поводу первой лиги я бы то же не был так уверен. Подумайте на досуге? почему чемпионы мира и чемпионы олимпийских игр далеко не всегда одни и те же люди ;)
Посоветуйте хороших скринкастов, где можно на посмотреть на программистов за работой (не соревнования) и не уроки вроде techdays?
Кто-нибудь видел такие?
Кто-нибудь видел такие?
Три года назад, когда я впервые попал на работу, мой супервайзер, опытный разработчик, проводил со мной очень много времени за одним монитором — иногда по пару часов в день. Иногда код писал я, иногда — он, иногда за моим монитором, иногда — за его. Это продолжалось наверное месяца три, на протяжении которых я научился очень многим трюкам, за что ему очень благодарен.
Теперь я старший разработчик, сам пытаюсь практиковать такое с молодыми ребятами, которых берут к нам на проект и это дает плоды. А иногда практикуем парное программирование и с более опытными товарищами — очень полезно.
Кстати, опыт участия в АСМ-олимпиадах очень способствует привыканию к парному программированию ;)
Теперь я старший разработчик, сам пытаюсь практиковать такое с молодыми ребятами, которых берут к нам на проект и это дает плоды. А иногда практикуем парное программирование и с более опытными товарищами — очень полезно.
Кстати, опыт участия в АСМ-олимпиадах очень способствует привыканию к парному программированию ;)
Когда одна часть кода пишется совместно, или когда раздельно, но в тесном взаимодействие с другими, тогда в это эффективно и иногда даже весело.
Другое дело, когда работа одного программиста не пересекается с другими. Сидит он зарывшись в кодирование, отладку и тесты. И тут кто-то сзади начинает пялиться к нему в монитор, причем еще и с активными комментариями. Такая вот «совместная работа» сильно раздражает.
Другое дело, когда работа одного программиста не пересекается с другими. Сидит он зарывшись в кодирование, отладку и тесты. И тут кто-то сзади начинает пялиться к нему в монитор, причем еще и с активными комментариями. Такая вот «совместная работа» сильно раздражает.
Плотник осваивает свое мастерство в процессе работы.
Очень удивился, когда после трех абзацев разумного текста встретил «лазают по меню». Удивление прошло, когда увидел «Комментарии переводчика» :)
Временами в вашей любимой IDE полезно почитать или перечитать раздел Tips&Tricks (и подобное). Там может быть много всего полезного — от хоткеев до практик и неизведанной функциональности.
В NetBeans, до кучи, по умолчанию на стартовой странице (показывается при старте среды) подгружаются новости с блога, в т.ч. и о использовании среды, практиках на разных языках программирования и пр.
Очень полезно проводить хотя бы раз в месяц семинары в рамках коллектива «как мы делаем это». В неформальной беседе после доклада можно коснуться животрепещущих тем и получить адекватные ответы (если ваши сотрудники достаточно адекватны). Ну и скринкасты никто не отменял.
В заключение, если у вас есть что-то наболевшее, и вам кажется, что логично, если выяснится, решение УЖЕ есть — не стесняйтесь спрашивать у окружающих. В 80% случаев из 100 даже в вашей комнате найдется кто-то более компетентный, кто, возможно, сам сможет предоставить вам это решение, либо показать его (если мы говорим о практиках использования IDE, или кастомном решении на определенном языке/фреймворке, с которым конкретный сотрудник «собаку съел» в силу специфики), либо показать к нему наиболее верные пути. Стеснительность в данном случае не идет на пользу ни вам, ни вашим работодателям, ни окружающим: сегодня помогут вам, а завтра, глядишь, и вы что-то толковое подскажете.
Хотя, не скрою, некоторых моих коллег одно время мои «излишние вопросы» раздражали. Но что делать, если объем гигантский, понимание «как должно быть» есть, и ради осознания и последующего грамотного использования 2-3 строчек кода прочитывать раз за разом по 25 кБ документации мозг уже не осиливает?
В NetBeans, до кучи, по умолчанию на стартовой странице (показывается при старте среды) подгружаются новости с блога, в т.ч. и о использовании среды, практиках на разных языках программирования и пр.
Очень полезно проводить хотя бы раз в месяц семинары в рамках коллектива «как мы делаем это». В неформальной беседе после доклада можно коснуться животрепещущих тем и получить адекватные ответы (если ваши сотрудники достаточно адекватны). Ну и скринкасты никто не отменял.
В заключение, если у вас есть что-то наболевшее, и вам кажется, что логично, если выяснится, решение УЖЕ есть — не стесняйтесь спрашивать у окружающих. В 80% случаев из 100 даже в вашей комнате найдется кто-то более компетентный, кто, возможно, сам сможет предоставить вам это решение, либо показать его (если мы говорим о практиках использования IDE, или кастомном решении на определенном языке/фреймворке, с которым конкретный сотрудник «собаку съел» в силу специфики), либо показать к нему наиболее верные пути. Стеснительность в данном случае не идет на пользу ни вам, ни вашим работодателям, ни окружающим: сегодня помогут вам, а завтра, глядишь, и вы что-то толковое подскажете.
Хотя, не скрою, некоторых моих коллег одно время мои «излишние вопросы» раздражали. Но что делать, если объем гигантский, понимание «как должно быть» есть, и ради осознания и последующего грамотного использования 2-3 строчек кода прочитывать раз за разом по 25 кБ документации мозг уже не осиливает?
после двух слов заголовка идет масса текста, ничего не добавляющая к тем двум словам.
а потом еще куча комментариев, ничего не добавляющих к тексту.
а потом еще куча комментариев, ничего не добавляющих к тексту.
По поводу парного программирования — у меня часто выходит так, что больше времени уходит на споры, чем на программирование… :)
Когда что-то делаешь руками — виден процесс, когда головой — процесс можно только рассказать. У программиста на экране текст появляется готовыми кусками. Это примерно как плотник не снимает слой за слоем, а сразу — вжик и снял несколько сантиметров лишнего и вдобавок четко по задуманной форме.
Иногда даже сложно самому понять внутренние механизмы процесса программирования, потому что многие вещи «выскакивают» — то ли интуитивно, то ли ассоциативно — один фиг не осознаваемо.
Так что либо люди срабатываются и за кодом видят задумки другого, либо ты сидишь один и просто видишь иногда результаты других.
Иногда даже сложно самому понять внутренние механизмы процесса программирования, потому что многие вещи «выскакивают» — то ли интуитивно, то ли ассоциативно — один фиг не осознаваемо.
Так что либо люди срабатываются и за кодом видят задумки другого, либо ты сидишь один и просто видишь иногда результаты других.
Во многом правда. Мы сотни раз пишем одни и те же вещи (quicksort!?) и наступаем на одни и те же грабли. А потом приходим на работу, где в основах основ систем тщательно вылизанный отлаженный и лаконичный код… зачастую без единого комментария.
Да, opesource замечательный учитель. Есть еще очень хорошая книга Coders At Work. Там ни строчки кода, зато много опыта и здравого смысла.
Да, opesource замечательный учитель. Есть еще очень хорошая книга Coders At Work. Там ни строчки кода, зато много опыта и здравого смысла.
А про комбинацию клавиш для форматирования кода можно подробнее?
Это Shift+Tab или что-то более серьёзное?
Это Shift+Tab или что-то более серьёзное?
Не только код. Вообще, когда кто-то суёт нос в процесс творческой работы — это как мозг наизнанку. Проверено на музыкантах, художниках, программистах и на себе)
Но вот процесс игры! — совсем другое дело.
Но вот процесс игры! — совсем другое дело.
К «кипы побочных результатов творчества — письма, наброски, черновики и рабочие тетради» пришло тут в голову — а ведь в во всяких VCS вполне себе сохраняются «наброски» и «черновики».
Sign up to leave a comment.
Одинокое программирование