Comments 13
Знавал я в конце прошлого века одного дядечку, который специально запутывал свой код так, что без бутылки не разберешься. Эдакая ручная обфускация.
На вопрос — «а зачем?» был шикарный ответ: «Чтобы меньше криворуких смогло разобраться в моих идеях и скопировать их».
Хотя дяденьке на тот момент было за 40, подростковая глупость и гордыня так и не покинули его.
Не будьте такими дядечками.
На вопрос — «а зачем?» был шикарный ответ: «Чтобы меньше криворуких смогло разобраться в моих идеях и скопировать их».
Хотя дяденьке на тот момент было за 40, подростковая глупость и гордыня так и не покинули его.
Не будьте такими дядечками.
На прошлой работе у нас была интересная задача. Я был сотрудником ЦНИИ в Санкт-Петербурге, который писал прошивку для микроконтроллера. Само изделие должен быть изготавливать завод в Нижнем Новгороде. Соответственно всю документацию (включая исходный код) надо было передать ему.
На заводе было своё КБ, которое всё чаще задавалось вопросом «Зачем нам ЦНИИ? Мы же и сами может разрабатывать изделия!». И вот тут то и возникла задача, как бы им передать исходный код, который работает, но который они не смогут понять и использовать в качестве отправной точки своих разработок. И скилы такого дядечки нам бы пригодились.
На заводе было своё КБ, которое всё чаще задавалось вопросом «Зачем нам ЦНИИ? Мы же и сами может разрабатывать изделия!». И вот тут то и возникла задача, как бы им передать исходный код, который работает, но который они не смогут понять и использовать в качестве отправной точки своих разработок. И скилы такого дядечки нам бы пригодились.
В этом случае нет. Разобраться как работает — однократно и профит высок, можно сделать. Поддержавать постоянно — профита мало, а сил заметно больше (если не свести к пункту 1).
Такие вещи решаются другим путём: если не хотите, чтобы кто-то обогнал вас на ваших разработках — двигайтесь вперёд сами.
В данном случае не получилось бы. У нас не было производственных мощностей чтобы изготавливать серийное изделие. А у заводчан они были.
На мой взгляд нанять дополнительных инженеров всё же проще, чем организовать промышленное производство. Поэтому в этой «гонке» преимущества были не на нашей стороне.
На мой взгляд нанять дополнительных инженеров всё же проще, чем организовать промышленное производство. Поэтому в этой «гонке» преимущества были не на нашей стороне.
Решить эту ситуацию можно, лишь убедив менеджеров, что плохой (хотя и рабочий) код грозит увеличением затрат на его обслуживание уже в ближайшем будущем.
Если Вы скажете менеджеру, что код который пишет команда плохой, то вся команда проклянет Вас. А так и код плохой и вся команда убеждает менеджера, что код идеален, просто сложный, но ведь современный продукт всегда сложный, поэтому трудно обслуживать и т.д…
UFO just landed and posted this here
Мне очень сильно помогло, то что в проекте практиковалось полное покрытие юнит тестами. То есть 2-5 тестов на каждую строчку кода.
Очень дисциплинирует и заставляет писать тестируемый код.
Pre-review не позволит попать коду в репозиторий, а post-review в рабочий проект.
Очень дисциплинирует и заставляет писать тестируемый код.
Pre-review не позволит попать коду в репозиторий, а post-review в рабочий проект.
Вот список практик моего текущего проекта, которые в разной степени направлены на поддержание понятности кода.
Я, наверное, что-то упустил, но это не важно. Важно то, что всех этих практик все равно оказывается недостаточно. )))
- Придерживаться общего для проекта стиля. Да, его нужно выработать, задокументировать и автоматизировать контроль.
- Давать осмысленные названия переменным, классам, функциям, пакетам.
- Выровнять уровни абстракции. В том числе в рамках одного файла.
- Стремиться сохранить линейный формат кода на каждом уровне абстракции. Считайте, что вам удалось, если возможно сделать близкое к реальности предположение о том, что делает функция, прочитав её всего лишь раз сверху вниз.
- Избегать повторяющихся проверок. В идеале — вытеснить неопределенность в данных на максимально высокий уровень абстракции и сделать некорректное состояние невыразимым на нижележащих.
- Написать тесты, которые как минимум демонстрируют замысел.
- Зачищать ненужный код, комментарии, и т.д..
- Хороший комментарий в коде — это ссылка на документацию или объяснение, почему сделано именно так, а не иначе.
- Снабжать commit'ы внятными комментариями.
- Не объединять в одном commit'е разрозненные по смыслу вещи.
- Делать обзор собственного кода перед созданием pull-request'а.
- Не создавать слишком большие pull-request'ы. Если изменений слишком много — лучше создать несколько pull-request'ов.
- Делать code review. Никакого merge до консенсуального исправления всех значимых замечаний.
Я, наверное, что-то упустил, но это не важно. Важно то, что всех этих практик все равно оказывается недостаточно. )))
Это что, эликсир?
Не ожидаешь увидеть его на Хабре
Не ожидаешь увидеть его на Хабре
Странная статья без каких-то общих подходов.
Код должен быть такой, чтобы было понятно за чем (по какой причине) так написано, а не что код делает.
Код должен быть такой, чтобы было понятно за чем (по какой причине) так написано, а не что код делает.
Sign up to leave a comment.
Как написать код, который будет понятен всем?