Speaker Rabbit

abbra


CIFS: curious information funneled sometimes


Previous Entry Share Next Entry
(no subject)
Speaker Rabbit
abbra
Посредством ЛОРа вышел на замечательную запись в журнале Ярослава Жешутко, в которой он описывает свой опыт общения с интересными и уважаемыми им программистами.

Их ответы, да и сам выбор людей, заставили меня задуматься -- а кого же я считаю своими учителями в Computer Science? Вопрос сложный, на самом деле, потому как, не переставая учиться у каждого программиста, каким бы он не был -- плохим или хорошим -- я в первую очередь учусь не CS, а тому, как работать и жить вместе. А взгляды, алгоритмы, методики программирования, педантичность и умение выдавать код "на гора" лишь способствуют этому.

Например, главным своим коллективным учителем я могу с уверенностью назвать две команды: Samba Team и ALT. Их нельзя рассматривать как единое целое с точки зрения выдаваемого продукта, но со всеми их проблемами, кризисами, разладами, достижениями и прорывами, это все же единые и целые учительские коллективы. Взять хотя бы Samba Team: из порядка двадцати человек, которые в него входят, лишь несколько человек имеют формальные степени (PhD, это прежде всего Dr. Andrew Tridgell), чтобы считать их формальными учителями в научной сфере. Однако примерно за половиной из них стоит история развития свободного программного обеспечения за последние 15 лет, а некоторые (такие, как Jeremy Allison и John Terpstra) непосредственно формировали внутреннее состояние POSIX-овой IT индустрии.

Линус Торвальдс, отвечая на вопросы Ярослава, заметил, что наиболее ценным качеством в программисте является вкус -- умение ценить чужую работу и умение оформить свою элегантно. Вкус является одним из основополагающих умений при работе в коллективе, он позволяет сосуществовать "единству непохожих" (Аристотель), продвигаться в своем развитии и развитии предмета исследования, каким бы он ни был. В Samba Team есть шуточная поговорка -- "членом команды становятся тогда, когда ответственному за тебя и твои патчи становится неудобно быть посредником, который ничего уже не может добавить к твоей работе".

Вкус крайне необходим и для того, чтобы это "единство непохожих" смогло расправить крылья и подняться над недостатками отдельных членов команды. Мы знаем, что часто одержимый идеей Tridge может выдать идею и код, которые совершают фундаментальный прорыв в своей области (как это случилось с тестированием CIFS), но потом вся команда на протяжении годов будет полировать и приводить в общее русло его черновые наброски, пока они не станут работать так, как этого ждут, например, заказчики Пола Грина из Stratus Technologies, у которых Samba обслуживает как биржу, так и мониторинг ядерных реакторов.

С другой стороны, требуется определенная терпимость, чтобы в таком "единстве непохожих" не разругаться и уйти до того, как твои идеи будут приняты. Многие из подходов, которые используются сегодня в Samba 4, предлагались 4-5 лет назад, но не были приняты. Потом они были "переоткрыты" другими членами команды и на их энтузиазме "въехали" в репозитарий как базовые подходы -- может быть немного в другом изложении, конечно.

Похожее было в ALT с наработками в области автоматической сборки приложений в изолированных средах. Потребовалось несколько лет, чтобы успешно применяемые реализации идей, будучи неиспользуемыми масштабно в рамках проекта, все-таки повлияли на создание следующего поколения автоматических собирателей, а теперь -- и системы совместной разработки. Правда, последнее стало возможным в том числе и благодаря конфликту между разработчиками, в котором появился git и, так уж вышло, создатель которого был в том конфликте не прав.

С другой стороны, я могу твердо назвать одним из своих учителей Юкихиро Мацумото, создателя Ruby. Его тезис о том, что язык программирования должен помогать беречь мысленную энергию программиста и то, что он должен быть естественным, а не простым, произвел со мной крайне серьезное преобразование. Результатом его стало не использование каких-то конкретных средств программирования (того же Ruby, например), но скорее образование какого-то целостного подхода к "станку", почти как у Мацуэ Басё:

Ирис на берегу.
А вот другой — до чего похож! —
Отраженье в воде.


Этот целостный взгляд на проект, индустрию в целом, кстати, позволяет прогнать ту юношескую горячность, которая сопровождает "быстре, выше, сильнее" в IT -- чтобы компьютеры были самые новые, программы -- самые свежие, технологии -- самые прогрессивные. Да, все это надо в определенной степени, но не более того. А иногда технологии и прорывы просто должны постоять и подождать на перекрестке, дождаться своего времени.

Возвращаясь к опроснику Ярослава, хотелось бы отметить еще замечание Дэйва Томаса о том, что же полезно для программиста -- знание формальной математики, физики или чего еще. Дэйв обратил внимание, что выдаюющиеся программисты часто обладают музыкальным слухом. Видимо, цепляются общие области мозга, а музицирование и сочинение в чем-то близки к программированию -- по крайней мере, и музыканты, и программисты большую часть своего внутреннего зрения тратят на напряженное балансирование на невидимых, но от того не менее реальных небесных струнах.

  • 1
Неплохая заметка

код должен быть красивым :-)
а знание физики/теор. химии очень сильно помогает думать.

Понятие красоты у всех разное. То, что считают красивым в Японии или Китае, не совпадает с понятием красоты в Европе. Также и с кодом. Но при этом наличие вкуса позволяет наслаждаться как японским, так и европейским кодом, и писать в том стиле, который наиболее подходит для указанного проекта.

:-)

ну красота кода и вкус здесь совпадают (ИМХО), в отличии от понятия красоты мира

  • 1
?

Log in

No account? Create an account