Comments 81
Уважаемые читатели! Что вы посоветовали бы освоить тому, кто стремится к профессионализму в программировании?Идти своим путем. Выработать те практики и навыки, которые будут максимально эффективны именно для него.
Если вы читаете чужой код и встречаете в нём что-то такое, что вам не нравится, постарайтесь не молчать об этом. Это поднимет ваш авторитет в глазах сослуживцев.
— Вы все говно! (с)
Всегда думал, что сначала стоит узнать — почему выбрано такое решение. Предложить своё, обсудить возможные вариант.
Думаю «не молчать» как раз об этом.
Авторитет зависит не только от факта обсуждения чужого кода, но и от тона, с которыми это делалось и ещё от множества не технических факторов.
Мне вот следующий абзац ещё больше понравился.
Оно вроде как бы и не враньё — статус оно таки упрочит. Вот только вам этот статус не понравится, скорее всего.
Самое мягкое, что вы услышите от программиста в ответ на претензии к недостатку хороших комментариев в его коде — «ну так возьми и напиши».
То же самое про поддержку — чаще всего есть причины, по которым некоторый код тяжело поддерживать. Например, потому что система мгновенных транзакций делалась из системы заявок, которая делалась на основе чата, который делался на основе форума (которым проект был N лет назад). И автор этих переделок вас, конечно, выслушает, но вряд ли согласится с предположением о том, что все проблемы от недостатка планирования наперёд.
Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии. Это ещё сильнее упрочит ваш статус в команде.
Оно вроде как бы и не враньё — статус оно таки упрочит. Вот только вам этот статус не понравится, скорее всего.
Самое мягкое, что вы услышите от программиста в ответ на претензии к недостатку хороших комментариев в его коде — «ну так возьми и напиши».
То же самое про поддержку — чаще всего есть причины, по которым некоторый код тяжело поддерживать. Например, потому что система мгновенных транзакций делалась из системы заявок, которая делалась на основе чата, который делался на основе форума (которым проект был N лет назад). И автор этих переделок вас, конечно, выслушает, но вряд ли согласится с предположением о том, что все проблемы от недостатка планирования наперёд.
«Красота в глазах смотрящего.» © Оскар Уайльд
Когда уже все эти советчики научатся отличать GitHub от git.
Как только выполнят пункт 4
Bitbucket? Не, не слышали. А там что-то свое?
UFO just landed and posted this here
Да. Вы не понимаете отличия конкретной реализации системы контроля версий, от целой категории такого софта.
Учить надо не столько гит, сколько в целом системы контроля версий. Чтобы небыло попаболи когда приходите в новую контору, а там вместо гита пластик или меркуриал.
Учить надо не столько гит, сколько в целом системы контроля версий. Чтобы небыло попаболи когда приходите в новую контору, а там вместо гита пластик или меркуриал.
Тогда будьте добры — напишите название для
Я вот читаю(https://en.wikipedia.org/wiki/Git#cite_note-linusGoogleTalk-11):
системы контроля версийиспользуемой Git, если Git — это только название конкретного приложения.
Я вот читаю(https://en.wikipedia.org/wiki/Git#cite_note-linusGoogleTalk-11):
These criteria eliminated every then-extant version-control system, so immediately after the 2.6.12-rc2 Linux kernel development release, Torvalds set out to write his own
Где вы в моем ответе увидели слово «приложение»?
Разжую чутка. Есть такое понятие — «система контроля версий». Их есть много реализаций — svn, git, mercurial, plastic, TFS. Git — конкретная реализация этого понятия. Которая имеет общие черты с другими реализациями — так же как и автомобили имеют общие черты, несмотря на конкретные реализации.
Так вот. Лучше всего учить и понимать как работает абстрактная система контроля версий. А потом уже спроецировать эти знания на конкретную реализацию. Грубо говоря — вы учитесь ездить на автомобиле, а не на конкретной модели. И еще грубо говоря — в резюме вы сможете написать «умею работать с системами контроля версий», а не конкретно с гитом. Который вообще не панацея.
Разжую чутка. Есть такое понятие — «система контроля версий». Их есть много реализаций — svn, git, mercurial, plastic, TFS. Git — конкретная реализация этого понятия. Которая имеет общие черты с другими реализациями — так же как и автомобили имеют общие черты, несмотря на конкретные реализации.
Так вот. Лучше всего учить и понимать как работает абстрактная система контроля версий. А потом уже спроецировать эти знания на конкретную реализацию. Грубо говоря — вы учитесь ездить на автомобиле, а не на конкретной модели. И еще грубо говоря — в резюме вы сможете написать «умею работать с системами контроля версий», а не конкретно с гитом. Который вообще не панацея.
Да вы, мсье, хамло. И, видимо, ответить не сможете.
А чтобы не быть голословным по поводу хамства:
1) В компьютерном сленге часто используется слово софт, произошедшее от английского слова «software», которое в этом смысле впервые применил в статье журнала American Mathematical Monthly математик из Принстонского университета Джон Тьюки в 1958 году.
Wiki
2) «software» переводится как «программное обеспечение»
3) Прикладное ПО — программа, предназначенная для выполнения определённых задач и рассчитанная на непосредственное взаимодействие с пользователем. В большинстве операционных систем прикладные программы не могут обращаться к ресурсам компьютера напрямую, а взаимодействуют с оборудованием и другими программами посредством операционной системы.
Ну и раз уж вы редактируете свои ответы, то и я себе позволю:
так что ваше добавленное оправдание по примеру автомобилей — совсем не оправдание.
А чтобы не быть голословным по поводу хамства:
1) В компьютерном сленге часто используется слово софт, произошедшее от английского слова «software», которое в этом смысле впервые применил в статье журнала American Mathematical Monthly математик из Принстонского университета Джон Тьюки в 1958 году.
Wiki
2) «software» переводится как «программное обеспечение»
3) Прикладное ПО — программа, предназначенная для выполнения определённых задач и рассчитанная на непосредственное взаимодействие с пользователем. В большинстве операционных систем прикладные программы не могут обращаться к ресурсам компьютера напрямую, а взаимодействуют с оборудованием и другими программами посредством операционной системы.
Ну и раз уж вы редактируете свои ответы, то и я себе позволю:
отличия конкретной реализации системы контроля версий, от целой категории такого софта.
так что ваше добавленное оправдание по примеру автомобилей — совсем не оправдание.
Шутка была в том, что github это не только Git, а целая инфраструктура.
Кстати checkout оттуда можно сделать и при помощи SVN, хотя это другая система контроля версий.
В частности git это лишь одна из систем контроля версий.
P.S. А ещё git это контент-адресуемое по SHA-1 хранилище объектов
Кстати checkout оттуда можно сделать и при помощи SVN, хотя это другая система контроля версий.
В частности git это лишь одна из систем контроля версий.
P.S. А ещё git это контент-адресуемое по SHA-1 хранилище объектов
напишите название
DVCS ?
Вы не в тренде :)
Сейчас модно тупо лоббировать переход на Git вместо изучения других систем контроля версий, даже если они уже вполне успешно используются.
P.S. Оригинальной статье сарказм не чужд
Сейчас модно тупо лоббировать переход на Git вместо изучения других систем контроля версий, даже если они уже вполне успешно используются.
P.S. Оригинальной статье сарказм не чужд
Mercurial, SVN...
Понятно что они путают теплое с мягким, но в защиту хочу сказать что в плане Git Гитхабу альтернативы по сути нет, ибо Гуглокод уже ридонли официально, остальные проекты полумертвые, а с тем же Гитлабом лично у меня как-то не сложилось, не знаю, какой-то он не такой, я хотел на него пересесть, ибо люблю альтернативы, но как-то не зашло, поэтому в мире Git это уже стало нарицательным по сути, как ксерокс или джип, уже же никто не говорит, мол, да когда уже эти обыватели научатся отличать копир от ксерокса?)
UFO just landed and posted this here
Ни одного проекта на нем не встречал, каким бы крутым бы он ни был. Возможно изначально Гитхаб был популярнее, и разрабы не видят смысла поддерживать несколько проектов в разных системах одновременно. Я просто констатирую факт, что есть — то есть.
UFO just landed and posted this here
По проектам — Unity держит всякое-разное на битбакете.
По популярности — да, гитхаб более раскручен.
Про поддержку проектов — ерунда. Сделать пуш не в один remote а в два требует ровным счетом ничего.
По факту — битбакет и гитлаб круты тем, что их можно поставить на локальные сервера. В первую очередь.
Ну а так да, сравнение с ксероксом — прям в точку.
По популярности — да, гитхаб более раскручен.
Про поддержку проектов — ерунда. Сделать пуш не в один remote а в два требует ровным счетом ничего.
По факту — битбакет и гитлаб круты тем, что их можно поставить на локальные сервера. В первую очередь.
Ну а так да, сравнение с ксероксом — прям в точку.
Сделать пуш не в один remote а в два требует ровным счетом ничего.
Возможно, просто та же IDEA вроде как может только в одну SVC коммитить за раз. Во всяком случае насколько я знаю. У меня только GitHub, поэтому его подключил и лью все на него, может и в несколько можно…
По факту — битбакет и гитлаб круты тем, что их можно поставить на локальные сервера.
Это да, это да, тут спорить не буду, самому очень не хватает своего Гитхаба, люблю все хранить у себя. Пока в виде компромисса храню все в приватных репозиториях, надеясь что однажды они не станут публичными :/ Утешаю себя что для Гитхаба это могут быть многомиллиардные потери, ибо в Штатах очень любят получать компенсации за моральный ущерб, поэтому всяко думаю у них все в порядке с этим, а взломать можно все, было бы желание.
UFO just landed and posted this here
IDEA вроде как может только в одну SVC коммитить за раз. Во всяком случае насколько я знаю.
Да, я тоже за одну оправку могу запушить в один из репозиториев. Но повторить дело для другого репозитория — дел меньше чем на минуту.
Занудство QA
VCS
только в одну SVC коммитить за раз
VCS
Все наши проекты (фирмы, где я работаю) на битбакете. Другое дело, что проекты «закрытые». Но они есть, кода очень много.
*сугубо свои «домашние, R&D» держу сразу и на гитхабе, и на битбакете. Но опять же, репозитории закрытый характер носят.
*да, локальный битбакет был одним из плюсов
*сугубо свои «домашние, R&D» держу сразу и на гитхабе, и на битбакете. Но опять же, репозитории закрытый характер носят.
*да, локальный битбакет был одним из плюсов
Вообще-то еще GitLab есть. И вообще не обязательно пушить репозиторий куда-то.
Похоже на краткий пересказ книги Clean Coder
Как стать высокоэффективным программистом (если верить статье) — приходи пораньше, хреначь, не отвлекаясь, и не забывай пушить :)
Сам процесс написания кода — это лишь часть работы по решению некоей задачи. Нетрудно создать программу, которая хорошо работает на вашем компьютере. Но код, с которым работает кто-то другой, легко может вести себя совсем не так, как изначально ожидалось. Как код, который вы пишете, будет использоваться в продакшне? С какими системами ему придётся взаимодействовать? Частью каких процессов он может стать? Не покажется ли он слишком примитивным и ограниченным программисту, которому придётся поддерживать его через несколько лет? Это — очень непростые вопросы.
Вопрос откуда взялись вопросы, если в оригинале их не было :)
Simply coding and programming is only part of the problem. It’s easy to create software that works well on your computer. But there are a lot of ways deploying code can go wrong. Once in production, it’s hard to say how code will be used and what other code will be attached to your original code. Five years from now, a future programmer might get frustrated at the limitations of your code.
Пишите простой код, который легко поддерживать
Или как шутил наш техлид: «Подходит ко мне заказчик, смотрит мне в глаза и спрашивает: Ребята, просто скажите — сколько? (драматическая пауза) я все пойму, просто скажите — сколько? (еще одна драматическая пауза с заглядыванием в глаза) сколько стоит, чтобы вы писали код без багов ?»
без багов не бывает.
«У вас столько нет»(с)
Помнится в ВУЗ-е самую первую лекцию по АиЯП лектор начал с фразы: Программирование без ошибок есть теоретическая абстракция. -)
Мы не знаем.
Это не к нам.
Мы не знаем к кому это.
Это не к нам.
Мы не знаем к кому это.
Вопрос «сколько?» напомнил мне вопросы типа «когда?». Типа сколько времени на разработку? Когда программа будет готова? Вопросы начальства/заказчика вроде бы справедливые, но точно ответить бывает не всегда легко. Вот вопрос «за сколько секунд поднимешь мешок цемента на 3-й этаж» — всегда простой — ответ на него легко вычислить, а если даже не вычислить, то уж засечь время на примере. А «кагда завершишь программу?» — не для каждой программы ответ однозначен и точен.
coub.com/view/1s775f
Кстати полная лекция очень даже ничего. Анекдот про обезьяну и бильярдный шар можно цитировать при каждом старте нового проекта.
Кстати полная лекция очень даже ничего. Анекдот про обезьяну и бильярдный шар можно цитировать при каждом старте нового проекта.
А можно ссылку на полную лекцию, пожалуйста?
Держите youtu.be/XDF02KmgJFE
Без багов — это ему в NASA надо.
TDD, будет почти без багов. На каждый чих, TDD. Время разработки взлетит раза в три, а количество сильно багов уменьшится.
5. Пишите простой код, который легко поддерживать
Уважаемый филин, а есть у вас тактические рекомендации, как мышкам стать ёжиками?
Ужасный перевод — давайте читать в оригинале, и его обсуждать.
Можно тогда уж и на оригинале обсуждать.
Причём даже комментарии аналогичны:
Причём с ответом автора что да — это статья-шутка
Вообще это мысль — к переводу статьи вставлять переводы комментариев :)
Причём даже комментарии аналогичны:
GitHub is not Git.
Not including any documentation is horrible advice.
This article is a joke, right?!
Причём с ответом автора что да — это статья-шутка
Вообще это мысль — к переводу статьи вставлять переводы комментариев :)
UFO just landed and posted this here
Это был «юмор», в оригинале сарказм был выделен зелёным, но при переводе выделение потеряли, как и это:
Все кроме вас пишут ужасный код.
Everyone but you writes terrible code.
Все кроме вас пишут ужасный код.
UFO just landed and posted this here
UFO just landed and posted this here
Декларативный — декларативный. Другой вопрос в том, чтобы с ним хорошо работать, надо еще иметь хотя бы среднее понимание того, что творится под капотом. Например, те же рекурсивные и аналитические функции мы в нем все-таки декларируем, а вот как их база внутри реализовывает — это лучше знать, чтобы не понаписать тормознутого говна.
UFO just landed and posted this here
- Избегайте совещаний
- в чат входит Agile
Agile: Ха. Хаха. Хахаха. ААААаааааааххахааахахахахахаха....
«чутьё на неудачные проекты» — это типа чтобы боссу сказать, что «мне проект не нравится, и я над ним работать не буду»? Ну-ну. Гораздо полезнее тогда чутье на неудачные команды или компании.
«приходить на работу раньше других для того, чтобы успеть справиться со своими делами» — если уходить тоже пораньше, то тогда нормально, но повод боссам задуматься что что-то организовано не так, если сотрудники не имеют возможности эффективно работать в стандартные часы.
«Научитесь говорить «нет»» — я всегда считал, что программист, как солдат, должен работать над тем, что скажет начальник. Начальнику нельзя сказать нет, но нужно донести до него мое экспертное мнение, и возможно он примет другое решение. Если задание идет от параллельной команды, то пусть обращаются через начальника, он заодно и назначит приоритет. Иначе начинается переработка и стресс.
«приходить на работу раньше других для того, чтобы успеть справиться со своими делами» — если уходить тоже пораньше, то тогда нормально, но повод боссам задуматься что что-то организовано не так, если сотрудники не имеют возможности эффективно работать в стандартные часы.
«Научитесь говорить «нет»» — я всегда считал, что программист, как солдат, должен работать над тем, что скажет начальник. Начальнику нельзя сказать нет, но нужно донести до него мое экспертное мнение, и возможно он примет другое решение. Если задание идет от параллельной команды, то пусть обращаются через начальника, он заодно и назначит приоритет. Иначе начинается переработка и стресс.
Золотые слова.
Даже солдат не должен выполнять прямо уж любой приказ, тем более программист. По моему имеется в виду, что начальнику надо уметь объяснить что он хочет хрень и что потом эта хрень будет хреново работать.
не имеют возможности эффективно работать в стандартные часы
Ну, ради объективности, не всегда есть какая-то в этом проблема. Даже на примере самого себя могу сказать, что иногда есть банальное желание прийти «с зарей», пройдясь по пустым улицам и обдумать в такой «романтичной» прогулке план работ на день. А бывает хочется банально выспаться.
По мне так максимально гибкое расписание — ощутимый плюс работ\команды.
P.S. Всегда на связи — если есть необходимость, со своей стороны так же готов проявить гибкость :)
Неплохие советы, но, как известно, проэкты не проваливаются из-за программистов, а из-за плохого руководства проектами. Вот из-за плохого руководства пишется говнокод, который потом не то чтоб понять, прочесть невозможно. Переписать его тоже практически невозможно, т.к. все переплетено и находится в продакшене. Тестов естественно нет никаких. Поэтому надо хорошо продумывать архитектуру перед написанием кода и не давать никому из «талантов» ее нарушать. Для этого можно использовать code-review подход чтобы изменения контролировались и следовали задуманной архитектуре.
Обращайте внимание тех, с кем вы работаете, на то, как важно писать код, который легко поддерживать, на то, как важны хорошие комментарии.
На самом деле, у хороших программистов не возникает нужды в документировании кода. Это — пустая трата времени, того времени, которое лучше было бы потратить на программирование и на проведение совещаний.
Избегайте совещаний
Мне очень помогает написание документации к своей программе, UserGuide.
«3. Избегайте совещаний» — очень сомнительный пункт. Он может работать только тогда, когда команда очень маленькая. Когда команда состоит и более чем 5-ти человек, есть необходимость регулярного обмена состояниями (например: чтобы не искать решения уже решенных проблем, чтобы код у команды имел единую архитектуру, чтобы быть в курсе изменения требований и т. д.).
«4. Освойте GitHub» — реклама GitHub'а? Я слышал что на этом ресурсе банят за прямую рекламу! Но если имеется в виду любая система контроля версий (о чем говорится в описании пункта), то совет не плохой (но в этом случае пункт должен называтья «4. Освойте систему контроля версий»).
«6. Научитесь говорить «нет»» — такой совет многие начинающие разработчики могу понять неправильно и в дальшейм сильно недоумевать почему у них проблемы на работе (или уже на бывшей работе). Возможность сказать «нет» есть далеко не всегде, не везде и не у всех. А если ты начинающий разработчик, то лучше всего научится всегда говорить «да».
«4. Освойте GitHub» — реклама GitHub'а? Я слышал что на этом ресурсе банят за прямую рекламу! Но если имеется в виду любая система контроля версий (о чем говорится в описании пункта), то совет не плохой (но в этом случае пункт должен называтья «4. Освойте систему контроля версий»).
«6. Научитесь говорить «нет»» — такой совет многие начинающие разработчики могу понять неправильно и в дальшейм сильно недоумевать почему у них проблемы на работе (или уже на бывшей работе). Возможность сказать «нет» есть далеко не всегде, не везде и не у всех. А если ты начинающий разработчик, то лучше всего научится всегда говорить «да».
- Совещание это не про обмен опыта, а обмен состояния это дейлики по 15-20 минут, они много времени не жрут. А вот когда кучу дней подряд идут совещания по три часа, где из 5 человек только двое в теме, а остальные слушают и пытаются ухватить контекст это не обмен опыта а трата времени и сил. Особенно весело в какой-то момент вначале потерять контекст а потом еще 2 часа с умным видом хлопать глазами.
- Насчет сказать нет ведь не имеется в виду послать начальство, а высказать свое мнение, почему так нельзя.
Статью писал точно не программист. Ставлю, что это ПМ, который таким нехитрым образом поднимает эффективность своей команды, заставляя гребцов работать с раннего утра. В топку.
~~~ T.D.D. ~~~
Просто надо понять, что написание программы в любом достаточно большом и долгом проекте (практически все, которые существуют в объективной реальности) или делается через TDD или покрывается мерзкими и неожиданными багами и медленно в муках умирает на руках обессиливших и потерявших всякую надежду вдохнуть жизнь в эту кучу сочащейся всеми жидкостями плоти программистов. Третьего варианта нет.
Это как строить дом вслепую, просто завязываем глаза и начинаем класть кирпичи, всё же просто. Даже какие-то приемы у людей появляются, как ловчее кирпичи эти класть, паттерны там всякие, бросаются всё это изучать, применять, называют себяпрограммистами строителями. А надо в первую очередь контролировать получающийся результат, контролировать отсутствие его деградации от разных возмущений, обратная связь нужна, как для любой системы, от которой нам надо получить некое устойчивое состояние.
Просто надо понять, что написание программы в любом достаточно большом и долгом проекте (практически все, которые существуют в объективной реальности) или делается через TDD или покрывается мерзкими и неожиданными багами и медленно в муках умирает на руках обессиливших и потерявших всякую надежду вдохнуть жизнь в эту кучу сочащейся всеми жидкостями плоти программистов. Третьего варианта нет.
Это как строить дом вслепую, просто завязываем глаза и начинаем класть кирпичи, всё же просто. Даже какие-то приемы у людей появляются, как ловчее кирпичи эти класть, паттерны там всякие, бросаются всё это изучать, применять, называют себя
Не любая система с тестами (что вы описали, по-моему) построена по TDD. Система, построенная по TDD, может быть в итоге недотестирована (особенно это касается уровня интеграции компонентов).
Я к тому, что любая система без тестов обречена на неудачу. А все руководства по программированию делают упор на то, как половчее извернуть код, не акцентируя внимание на том, что код без тестов == половина кода. Инь без янь, белка без стрелки, и т.п. В итоге имеем, что имеем, а насмотрелся я уже на всякое. Мы программисты, мы пишем код, а вон там где-то в подвале у нас вроде тестировщики должны сидеть, пусть тестируют наши творения, вообще не наша забота уже, мы своё дело сделали, дайте нам много денег, посмотрите как хитро извёрнут и отформатирован наш прекрасный код.
Однажды я попросил очень опытного водителя научить меня правильно водить машину. А он говорит:
— Едь как в автошколе учили, не нарушай правила.
— Ну это понятно. А как быстро разгоняться и проходить повороты, как выходить из заноса?
— Если будешь ехать по правилам, то не будет разгонов и заносов. И с машиной меньше хлопот.
— А если…
— Если скучно нормально ездить — иди с парашютом прыгай.
Ну, вот я отмотал мильон километров и написал мильон строк кода. Да, все так. Чем спокойнее едешь, тем меньше износ (машины и организма), тем больше можешь проехать. Больше внимания уделяется маршруту, цели поездки. Чем аккуратнее пишешь код (с говорящими именами, соблюдением стиля и правил безопасности), тем легче его читать и дорабатывать, тем больше кода и крупнее проекты можно поддерживать. То есть, код сам по себе перестает быть проблемой, можно сосредоточиться на решаемых задачах, взаимосвязях, архитектуре.
— Едь как в автошколе учили, не нарушай правила.
— Ну это понятно. А как быстро разгоняться и проходить повороты, как выходить из заноса?
— Если будешь ехать по правилам, то не будет разгонов и заносов. И с машиной меньше хлопот.
— А если…
— Если скучно нормально ездить — иди с парашютом прыгай.
Ну, вот я отмотал мильон километров и написал мильон строк кода. Да, все так. Чем спокойнее едешь, тем меньше износ (машины и организма), тем больше можешь проехать. Больше внимания уделяется маршруту, цели поездки. Чем аккуратнее пишешь код (с говорящими именами, соблюдением стиля и правил безопасности), тем легче его читать и дорабатывать, тем больше кода и крупнее проекты можно поддерживать. То есть, код сам по себе перестает быть проблемой, можно сосредоточиться на решаемых задачах, взаимосвязях, архитектуре.
Sign up to leave a comment.
7 привычек высокоэффективных программистов