Comments 30
моему коду это бы помогло, а то от переменных типа
х, хх, ххх1, temp, tmp, xxbw и так далее подустал.
Вот здесь на хабре вроде неплохо написано про именование
Автор приводит Golang как пример, речь вот об этом:
https://dave.cheney.net/practical-go/presentations/qcon-china.html#_identifiers
Я тут нашёл "гениальный" способ.Придумываю неплохое название на русском или англиском, а потом забиваю в перводичик и выбираю лучший вариант слова/подходящего синонима на англиском.
Например место структуры, что очевидно вызвало бы путаницу, использовал слова кластер.
Тут проблема в другом—если с самого начала не начал называть переменные нормально, дальше по инерции делать этого в этом проекте не будешь… это из раздряда теории разбитых окон...
И, конечно же, в ней поднимается тема сложности кода. Вы узнаете о том, откуда она берется, почему ее нельзя убрать и как с ней жить.
*Вот это поворот*
А ничего, что сами языки программирования (и соответственно код, написанный на них), за последние десятилетия стали сильно проще и удобнее? Не говоря уже о тысячах библиотек, которые легко подключаются и дают удобный интерфейс для использования.
Но несмотря на двадцатилетний опыт в программировании, Григорий признается: писать читаемый код до сих пор тяжело.
Этот Григорий пишет юнит тесты, использует DDD-подход? Я вижу в своем окружении программистов, которые не смотря на 10+ летний опыт пишут ужасный код, с которым тяжело работать. Но это происходит только потому, что они и не пытаются писать хороший код. Отсутствие самокритичности — своеобразное проклятье для человека.
P.S.
Складывается впечатление, что автор путает понятия «объем кода»/«читаемость кода»/«сложность кода». Объемы коды — да, убрать трудно, чаще всего его количество только растет за счет использования фреймворков и библиотек, но вот читаемость и сложность решается на ура.
А ничего, что сами языки программирования (и соответственно код, написанный на них), за последние десятилетия стали сильно проще и удобнее? Не говоря уже о тысячах библиотек, которые легко подключаются и дают удобный интерфейс для использования.
Ничего. Вы перераспределяете сложность, а не убираете её. С одной стороны да, можно сказать, что проблемы шерифа не волнуют индейцев (или как-то так), и что вы всё сделали правильно, а проблема не на вашей стороне. С другой стороны, в коммерческой разработке вам за такие фразы денег платить не будут, а чтоб платили — вам таки придётся идти разбираться с тем, что и как сломалось, даже если не у вас.
Вон, Хром — весь такой распрекрасный и отличный браузер, включает в себя тыщи библиотек и всё вот это, но если у вас из-за бага в Хроме будет неправильно работать сайт — разбираться с этим будете всё равно вы. И корень проблемы искать — тоже вы. И думать, как бы обойти проблему — всё еще вы. А те, кто пишут Хром — может быть, когда-нибудь в далеком светлом будущем починят проблему на их стороне.
Вон, Хром — весь такой распрекрасный и отличный браузер, включает в себя тыщи библиотек и всё вот это, но если у вас из-за бага в Хроме будет неправильно работать сайт — разбираться с этим будете всё равно вы.
Вы перескакиваете из одной темы на другую. В программировании есть нормальные и токсичные области. Разработка на Windows или web frond-end — это токсичные области. Даже если человека, по незнанию, занесло в эту область — никто не заставляет там оставаться.
Это тоже самое, что работать программистом в какой-нибудь российской госкомпании, и проблемы этой компании переносить на всю область в целом.
Ой, а можно весь список "токсичных областей", пожалуйста? Ну просто, чтоб знать, в каких таких интересных областях пасутся единороги и каждый несет бесконечно большую ответственность за свой код (в том числе опенсорсный), а в каких мор, глад, и тоска.
Все же просто и очевидно: становитесь ценным специалистом чтобы за вами стояла очередь из HR, закрываете финансовый вопрос (чтобы выбирать работу по принципу «нравится/не нравится»), определяете свои интересы и четко озвучиваете их работодателям (например, если у вас неприятие сторонних библиотек — прямо озвучиваете, что я все что нужно напишу сам, так будет проще и быстрее).
И… готово. Работаете в компаниях и проектах, которые вам нравятся, с технологиями, которые вам нравятся.
А если, этого нет — то, может быть, проблему нужно искать в себе?
Непонятна ваша незамутнённость. Почему незамутнённость? Потому что -
например, если у вас неприятие сторонних библиотек — прямо озвучиваете, что я все что нужно напишу сам, так будет проще и быстрее
Этот тезис может существовать в стране фей и единорогов, но не в реальности. В реальности вы практически нигде не пишете "всё сам" (драйверы? операционная система?), только если очень-очень близко к железу — но и там вы так же зависите от проблем железа.
Попытка заявить что-то про независимое программирование — она очень смешная. Программирование даже в 80-е годы прошлого века было зависимым. В нынешнее время — оно зависимо от труда очень многих других программистов (и производителей железа), причем так, что об очень многих зависимостях вы даже и не подозреваете. Пока у вас с ними что-то не сломается.
Этот тезис может существовать в стране фей и единорогов, но не в реальности
У меня складывается впечатление, что я разговариваю с человеком, который живет в каком-то Подмышкино со средней зарплатой в 15 тысяч рублей, и рассказывает всем о том, как плохо живется.
Ему говоришь о том, что можно жить по другому, но для этого нужно приложить усилия и соответствовать требованиям — начинаются разговоры «ну вот все мои знакомые тоже страдают, значит вы врете»
В реальности вы практически нигде не пишете «всё сам»
Да, обычно, не пишется (хотя на рынке такой дефицит крутых специалистов, что не удивлюсь, если какому-то гению дадут писать все с нуля). Но вот лично я работаю с тем стеком, который мне нравится, который написан качественно. И (возможно это вас удивит) всем работодателям на собеседовании я это сразу говорю, и обозначаю это как приоритет в поиске работы. Если вы работаете с кривым стеком — это ваши проблемы.
Ему говоришь о том, что можно жить по другому, но для этого нужно приложить усилия и соответствовать требованиям
Да, а вам говорят о том, что ваше "по-другому" означает не независимость, и не какое-то другое распределение ответственности за код (о чем в этой ветке комментариев и ведется разговор). Ваше "по-другому" — это "у меня такая же нога, и не болит". У вас никогда в жизни не было проблем из-за внешнего по отношению к вам кода? Рад за вас, но вы — исключение из правил, а не правило. И более того, у меня есть обоснованные подозрения, что у вас не было проблем не в силу тех причин, которые вы живописуете (собственной офигенности), а в силу некоторых куда более банальных вещей:
1) Вы решаете сугубо типовые проблемы проверенными инструментами для решения этих сугубо типовых проблем;
2) Вы решаете их не так долго, чтоб столкнуться с проблемами окружающего вас кода;
3) Вы работаете на достаточно старом проекте, и проблемы окружающего кода уже порешал кто-то другой за вас.
Но это безусловно забавно, что вы этот уютный закрытый мирок с легким запахом тлена описываете как нечто такое, к чему, оказывается, стоит стремиться.
Если вы работаете с кривым стеком — это ваши проблемы.
Я просто напомню, что вы в комментарии пришли с заявлением "нынче со сложностью всё хорошо, есть море всего, написанного до вас".
А теперь ваше заявление как-то усохло до размеров "ну вы прост работайте только с хорошим стеком, а с плохим никогда не работайте))))".
У вас никогда в жизни не было проблем из-за внешнего по отношению к вам кода?
Происходит, на каждой работе. А работ было много. Каждый раз проходит борьба заграницы своей ответственности, за адекватные сроки и прочее. Ничего не дается просто так.
что у вас не было проблем не в силу тех причин, которые вы живописуете (собственной офигенности), а в силу некоторых куда более банальных вещей
Пошло-поехало. Может быть еще про маму мою что-то скажете? Давайте, в лучших традициях разборок школьников.
Я просто напомню, что вы в комментарии пришли с заявлением «нынче со сложностью всё хорошо, есть море всего, написанного до вас».
Я сказал, что сложность решается. Решается в тех компаниях и теми программистами, которые этого хотят.
В тех компаниях, и у тех программистов, которые ищут отговорки, а не способы добиться целей — да, им и известный орган мешает.
Мне надоел этот диалог.
Люблю людей, которые сами придут сверкать белым пальто, и сами тут же обижаются. Passive-aggressive как оно прям по учебнику.
Я сказал, что сложность решается. Решается в тех компаниях, которые этого хотят. Решается теми программистами, которые этого хотят.
Ну да. А еще вы потом с ходу всю веб-разработку записали в "токсичную область". Надо ли это понимать так, что всем разработчикам в этих ваших интернетиках — любым, от тех, кто сайты делает, до тех, кто браузеры делает, и до тех, кто стандарты пишет — насрать на вопросы сложности кода?
Вопрос риторический, можете не отвечать.
Надо ли это понимать так, что всем разработчикам в этих ваших интернетиках — любым, от тех, кто сайты делает, до тех, кто браузеры делает, и до тех, кто стандарты пишет — насрать на вопросы сложности кода?
Сейчас уже наверное многим не насрать, т.к. уже более или менее всем стало очевидно, что сложность современных веб стандартов и браузеров превысила все возможные границы. Но остановиться уже никто не может. Текущее сотояние чем-то напоминает снежный ком, катящийся с горы: он может только расти, пока не развалится под собственным весом.
Внятный доклад, соответствующий, кстати, критериям в нем описанным.
И первые же комментарии: "много букв...".
"Кошелек Миллера" худеет. ;)
Но, в отличие от художника, программисты не могут «отойти на шаг назад».
По моему убеждению, такими "мазками" для программиста являются абстракции (которые могут включать другие абстракции, которые...). Ковыряние с неудачными абстракциями подобно тому, что художнику придётся просчитывать количество наносимой краски вплоть до молекул, чтобы холст не сгорел как только на него кто-нибудь посмотрит. И наоборот, если подобраны удачно, программист может добавить десяток таких "мазков" и получить из них библиотеку "голова" — вполне можно будет отойти назад и посмотреть, какая красивая получилась "голова" и как хорошо она соединяется с экзешником "туловище" через RPC-мостик "шея".
Согласен целиком.
Более того, именно тут часто кроется основная проблема — легко найти хорошо написанный метод или класс, тяжело — хороший модуль или фреймворк.
Целую программу, структурированную хорошо — почти нереально.
Хотя казалось бы — это самое важное.
Многие понятные задачи и фреймворк хороши даже не тем, что все делают красивым, а тем, что все делают "безобразным, но однообразным" формируя хорошие(в смысле единообразные и понятные для команды) правила расширения приложения.
1) Сложность кода растёт вместе со сложностью задачи, но неграмотный разработчик добавляет больше сложности в код, чем прибавилось сложности в задачу.
2) Не зря великие говорили, что если отладка сложнее написания кода, то не получится отлаживать код, который написал на пределе доступной тебе сложности. Но я бы сказал ещё, что грамотный разработчик не создаёт решения сложнее, чем на 90% от своей способности со сложностью справляться.
3) Нельзя сложные программные системы переписывать с нуля потому, что они тебе не нравятся своей сложностью. Если кто-то приходит к тебе и говорит «да тут у вас слишком сложно, мы напишем с нуля» — нельзя его к написанию подпускать, надо чтобы сначала он продемонстрировал, что старую систему срефакторить сможет. Если ты не можешь справиться с той сложностью, которая уже есть, методом постепенного рефакторинга, то когда начнешь писать сам — наворотишь сложность еще хуже и в итоге задачу не решишь. А всё почему? Потому что нельзя понять, что именно ты не понимаешь и недооценивашь, по определению.
4) Главное для опытного программиста — умение управлять сложностью. Обычно мы сложность только добавляем (нельзя же заниматься только рефакторингом), но горе тому, кто так до рефакторинга (по сути, упрощения!) и не доходит. Тогда вместо того, чтобы наводить порядок и упрощать, такой разработчик накручивает костыли на костыли и остановиться не может, потому что костыли писать проще. Со временем костыли писать становится всё сложнее и сложнее, но фишка в том, что в каждый момент времени написать очередной костыль хоть и всё сложнее и сложнее, но всё равно всегда проще, чем расчистить конюшни и навести порядок. И всегда есть эта иллюзия (?), что по причине дедлайнов оптимальное решение — писать костыли. Увы, это оптимальное решение в моменте, но очень неоптимальное в долгосрочной перспективе.
Круто расписали ) спасибо. Насчет последнего так вообще полностью согласен. Круто — не надстраивать систему, а выкидывать из нее лишнее, как скульптору, который отсекает от камня излишнее и получается красивое произведение искусства
В коде есть две составляющие сложности — объективная которая обусловлена решаемой задачей и привнесенная программистом в виде абстракций. Первую мы не можем изменить, хотя часто и тут можно изменить постановку проблемы не меняя конечного результата. Второе мы можем свести к минимуму.
На своем опыте убедился что почти всегда проблемы это результат переусложнения в коде с целью что-то обобщить и т.п. В итоге код всегда становиться трудно понимать — но автор всегда будет доказывает что там скрыт особый смысл который привносит особые свойства — расширяемось, гибкость, и т.п. аргументы можно слышать. На практике все вокруг плюются, кроме автора и каждый кто плюется порождает аналогичное самобытное решение.
Для того чтобы понять как сделать код проще, нужно понимать что сложность комбинаторное явление и если мы хотим уменьшить сложность нужно уменьшать кол-во комбинаций в коде. Т.е. не писать лишних абстракций и т.п.
Статья хорошая.
Но мне кажется, что очень важно подчеркнуть важную концептуальную проблему помимо названных — читать код сложнее, чем писать. Пишется он от иерархической абстракции в голове, которая хорошо масштабируется (не нужно помнить все), а при прочтении требует ровно обратного построения абстракции (нужно осознать очень много, чтобы получить компактное представление)
Не сложно написать программу, которую понимает компьютер, сложно написать, которую легко прочтет человек. Это требует специальных усилий на создание человекочитаемых абстракций. Это сложно, дорого и не обязательно по отношению к основной деятельности, кроме того, часто хватает других проблем — все же работоспособность или производительность все равно важнее.
Как писать читаемый код