Как стать автором
Обновить

Комментарии 17

Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода».

Мне кажется, автор преувеличивает с самого начала. Я как разработчик, конечно, иногда что-то слышал про метрики, основанные на строчках кода, но уже только в контексте рассказов про то, какие в природе бывают идиотские метрики. Вживую в работающем ИТ-бизнесе не сталкивался ни разу, и не видел, кто бы сталкивался.
Безусловно это не основные метрики, а скорее дополнительные/косвенные.
Больше кода — дольше читать и сложнее разбираться.
Если исправление достаточно простого дефекта вместо 3-4 строк в одном файле требует изменений 5-6 строк кода в 10-ти файлах — то это вполне может быть поводом задуматься о рефакторинге, например.
Сами по себе строки кода не так интересны, как необходимые на исправления затраты по времени и сложности работы (но это сложно считать).

Строки, коммиты, изменения очень легко измерять, составлять всякие красивые отчёты и рисовать диаграммы. Некоторым нравится подобная бюрократия, она создаёт красивую картинку «контроля», ни одно одно изменение не прошло незамеченным, каждая строчка посчитана :)
А есть абстрактный программист Вася, который за эти две недели написал 10 строк кода, а за последующие два дня 500…
С самого начала чего? Профессии, проекта, жизни, устройства на работу? Какие только заманухи не напишут, чтобы народ зашёл почитать.
В оригинале явного «самого начала» не было, но заголовок действительно «завлекательный»:
What Every Developer Should Learn Early On

«Чему каждому разработчику стоит научиться по-раньше» — не сильно лучше :)
Очень немногие кодируют более четырёх часов в день
Довольно спорное заявление. Когда тебе еще не 40, карьера на подъеме, руководство ждет результатов «вчера» и проекты относительно увлекательные, то вполне нормально кодить и по 10 часов в день годами. Чем еще заняться на работе? За 4 часа даже не успеешь нормально в поток войти, это не серьезно.

Странно про код ревью — искать им опечатки, пропуски… Линтеры, тесты, CI. Зачем этим заниматься вручную мне неясно.
На мой взгляд, ревью важный инструмент, если в команде есть недавно нанятые программисты. И для того, чтобы пройти по списку требований в задаче и сличить их со списком новых тестов и затем с кодом. Большего делать не стоит. А если делается, то надо искать способ автоматизировать эти действия.

Просто для ясности, я не предлагаю вам работать только четыре часа в день. Остальные четыре часа, как правило, лучше потратить на:

Исследования, как связанные с работой, так и не связанные


Ой, по острию ножа ходите. Совет, конечно, хороший, но лучше не вслух )))

Типа гуру втирал дуру

Наверное странно будет выглядеть, если я встану в середине дня по середине опенспейса и начну делать зарядку :)
Хотя, одна девочка у нас переодически делала упражнения возле туалета. Но что-то бросила
Наверное, если вам странно, то можно попробовать выбрать другое место. Я в своё время спускался, выходил из БЦ и заходил за угол, там практически никогда никого не было.
Некоторые могут сказать, что чем меньше строк кода в приложении, тем легче его читать.

Интересно, те кто это говорят когда-нибудь видели J?
Код не должен быть излишне сложным
Код не должен быть неэффективным (не пишите намеренно медленный код)

как начинающим изучать программирование, которые не владеют в нужной степени матчастью, соблюдать эти правила?
Пришли джуны, открывают конфлюенс, читают требования к коду и там: «не пишите намеренно медленный код»!!!
Все понятно, не будем.
  • Код должен быть информативным
  • Код не должен быть излишне сложным

Самая весёлая часть написания кода — это баланс и приведение к нему своего стиля написания программы. А вот он уже достигается планированием. Лично мой образ мышления (который я никому не навязываю) — спланируй поведения кода максимально большими по содержанию абстракцией. Потом по мере необходимости дели этот образ на составляющие. И запомни, между абстракцией A и абстракцией B всегда есть некая абстракция C, которую можно заметить только после первого применения программы на «боевой ситуации». Но именно она и будет твоей «Ахиллесовой пятой». А автор статьи правильно написал — Вы никогда не напишете «идеальный» код». Именно по этому всегда храни исходники на «всякий случай».

Выходит из третьего пункта, но все же — учить что либо связанное с проектом исключительно в рабочее время, а не дома, если конечно вас не прет от изучения очередного фреймворка или недоязыка. Я к примеру отказался в свое свободное время учить Coffee Script, предложил либо сходить искать фрилансера для задачи, либо скомпилить и работать с js.
Если у вас в резюме чего-то не было и вас взяли на работу, то все что сверх изучено — должно быть оплачено.

Если у вас в резюме чего-то не было и вас взяли на работу, то все что сверх изучено — должно быть оплачено.

А кем должно? Если вам предлагают изучить не что-то совсем уж экзотическое, а вполне себе востребованную платформу, и у вас реально есть свободное время, то вы не развалитесь, если сделаете это и в нерабочее время. Эти знания вы не вернёте работодателю, они остаются с вами, и повышают вашу же ценность. Понятное дело, что вопрос добровольный, и принуждать к этом работодатель не может, но занимать принципиальную позицию «раз вы не платите — я это делать не буду», это тоже глупо.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории