Комментарии 17
Как разработчик, вы услышите много сумасшедших, невероятных теорий о значении «строк кода».
Мне кажется, автор преувеличивает с самого начала. Я как разработчик, конечно, иногда что-то слышал про метрики, основанные на строчках кода, но уже только в контексте рассказов про то, какие в природе бывают идиотские метрики. Вживую в работающем ИТ-бизнесе не сталкивался ни разу, и не видел, кто бы сталкивался.
Больше кода — дольше читать и сложнее разбираться.
Если исправление достаточно простого дефекта вместо 3-4 строк в одном файле требует изменений 5-6 строк кода в 10-ти файлах — то это вполне может быть поводом задуматься о рефакторинге, например.
Сами по себе строки кода не так интересны, как необходимые на исправления затраты по времени и сложности работы (но это сложно считать).
Строки, коммиты, изменения очень легко измерять, составлять всякие красивые отчёты и рисовать диаграммы. Некоторым нравится подобная бюрократия, она создаёт красивую картинку «контроля», ни одно одно изменение не прошло незамеченным, каждая строчка посчитана :)
Очень немногие кодируют более четырёх часов в деньДовольно спорное заявление. Когда тебе еще не 40, карьера на подъеме, руководство ждет результатов «вчера» и проекты относительно увлекательные, то вполне нормально кодить и по 10 часов в день годами. Чем еще заняться на работе? За 4 часа даже не успеешь нормально в поток войти, это не серьезно.
Странно про код ревью — искать им опечатки, пропуски… Линтеры, тесты, CI. Зачем этим заниматься вручную мне неясно.
На мой взгляд, ревью важный инструмент, если в команде есть недавно нанятые программисты. И для того, чтобы пройти по списку требований в задаче и сличить их со списком новых тестов и затем с кодом. Большего делать не стоит. А если делается, то надо искать способ автоматизировать эти действия.
Просто для ясности, я не предлагаю вам работать только четыре часа в день. Остальные четыре часа, как правило, лучше потратить на:
Исследования, как связанные с работой, так и не связанные
Ой, по острию ножа ходите. Совет, конечно, хороший, но лучше не вслух )))
Типа гуру втирал дуру
Хотя, одна девочка у нас переодически делала упражнения возле туалета. Но что-то бросила
Код не должен быть излишне сложным
Код не должен быть неэффективным (не пишите намеренно медленный код)
как начинающим изучать программирование, которые не владеют в нужной степени матчастью, соблюдать эти правила?
- Код должен быть информативным
- Код не должен быть излишне сложным
Самая весёлая часть написания кода — это баланс и приведение к нему своего стиля написания программы. А вот он уже достигается планированием. Лично мой образ мышления (который я никому не навязываю) — спланируй поведения кода максимально большими по содержанию абстракцией. Потом по мере необходимости дели этот образ на составляющие. И запомни, между абстракцией A и абстракцией B всегда есть некая абстракция C, которую можно заметить только после первого применения программы на «боевой ситуации». Но именно она и будет твоей «Ахиллесовой пятой». А автор статьи правильно написал — Вы никогда не напишете «идеальный» код». Именно по этому всегда храни исходники на «всякий случай».
Выходит из третьего пункта, но все же — учить что либо связанное с проектом исключительно в рабочее время, а не дома, если конечно вас не прет от изучения очередного фреймворка или недоязыка. Я к примеру отказался в свое свободное время учить Coffee Script, предложил либо сходить искать фрилансера для задачи, либо скомпилить и работать с js.
Если у вас в резюме чего-то не было и вас взяли на работу, то все что сверх изучено — должно быть оплачено.
Если у вас в резюме чего-то не было и вас взяли на работу, то все что сверх изучено — должно быть оплачено.
А кем должно? Если вам предлагают изучить не что-то совсем уж экзотическое, а вполне себе востребованную платформу, и у вас реально есть свободное время, то вы не развалитесь, если сделаете это и в нерабочее время. Эти знания вы не вернёте работодателю, они остаются с вами, и повышают вашу же ценность. Понятное дело, что вопрос добровольный, и принуждать к этом работодатель не может, но занимать принципиальную позицию «раз вы не платите — я это делать не буду», это тоже глупо.
Что каждому разработчику следует знать с самого начала