Comments 47
Добавлю свои 5 коп.:
Имена — иногда смотришь код и диву даешься, как может писать такое человек, который не один год этим занимается(гляньте на код программ С/С++ в частности). Все эти сокращения, неосмысленные значения имен, а еще к этому приучают с универа и множества книг. Особенно смешно слушать отговорки о том, что это ради производительности. Вы серьезно??? Про компилируемые ЯП и говорить нечего, не буду строить из себя КО, а про интерпретируемые — для этого имеются минификаторы и без них нельзя выпускать код в продакшн!
Книга Мартина — это один из must read для каждого разработчика, вне зависимости от ЯП. Очень жаль, что правильные навыки не прививают с ранних лет.
Имена — иногда смотришь код и диву даешься, как может писать такое человек, который не один год этим занимается(гляньте на код программ С/С++ в частности). Все эти сокращения, неосмысленные значения имен, а еще к этому приучают с универа и множества книг. Особенно смешно слушать отговорки о том, что это ради производительности. Вы серьезно??? Про компилируемые ЯП и говорить нечего, не буду строить из себя КО, а про интерпретируемые — для этого имеются минификаторы и без них нельзя выпускать код в продакшн!
Книга Мартина — это один из must read для каждого разработчика, вне зависимости от ЯП. Очень жаль, что правильные навыки не прививают с ранних лет.
Противоположная крайность тоже плохо, недаром шутки ходят про ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокументИмениНуралиеваБорисаГеоргиевича
С одной стороны да, плохо(скорее всего, это уже ошибка проектирования), однако если в рамках контекста нет возможности сократить без потери смысла, то ничего страшного(но с такими длинными названиями могут быть классы, а не переменные и функции). Длинные и лаконичные названия лучше лишних и бесполезных комментариев
Еще не стоит забывать про документацию к методу.
О какой документации вы говорите? Если метод понятное и осмысленное значение, то он не нуждается в какой-либо документации/комментировании. Мартин этому аж целую 4ю главу посвятил
О какой документации вы говорите?О документации к коду, методы, типы, поля.
C# (Xml documentation ) и Java (JavaDoc) поддерживают документирование «из коробки», на другие языки вроде как есть «примочки».
Если метод понятное и осмысленное значение, то он не нуждается в какой-либо документации/комментировании.Очень сильное и очень спорное утверждение. Я не знаю что там писал Мартин, но хотелось бы посмотреть какой-нить его рабочий код, которму лет 10. В теории всегда все красиво.
Обычно, по необходимости, документацию пишут к публичному(public)/защищенному(protected) контакту фреймворка, или в каких-то широко используемых библиотеках. В legacy коде в принципе всегда понятно что он делает, но непонятно по какой причине написали его именно так.
Хотел бы я посмотреть на людей, которые получают фреймворк без документации, бгг…
Я не знаю что там писал Мартин
А вот вы почитайте и все станет на свои места. Что касается рабочему коду 10 летней давности, то с очень большой вероятностью, равно как и сейчас, большая часть написанного кода будет отвратительной с точки зрения читабельности, просто потому, что мало кто читает подобные правильные книги и еще меньше из читающих тех, кто это понимает и применяет на практике.
Хотел бы я посмотреть на людей, которые получают фреймворк без документации, бгг…
Все мы так или иначе используем фреймворки. Лично я зачастую не обращаю внимание на Javadoc всяких там геттеров, сеттеров и прочих методов, т.к. итак понятно, что они делают, так зачем для них писать документацию? Лишняя трата времени и «шум» в коде. Естественно, в некоторых случаях документация нужна, без нее не обойтись, я же не говорю о тотальном запрете документирования, я говорю о ее минимизации, что лучше подольше посидеть, подумать, обсудить с коллегами/сообществом, как понятнее назвать метод/переменную, либо упростить код без потери функционала
Я повторюсь еще раз, где можно посмотреть код Мартина. Биография на вики очень скудна.
Кстати сказать, Роберт сам говорит что документация к API это хорошо и с таким кодом приятно работать.
Проглядывая быстро некоторые главы почитаю.
Возможно у вас мало опыта и не попадались такие случаи, когда код понятный и хороший, а вот почему сделано именно так, непонятно. Код не объясняет бизнес особенностей, он всего лишь отражает некоторую бизнес модель.
А иногда очень хочется знать почему сделано именно так, а не иначе.
Самый ппц это когда получаешь код проекта, программисты которого уже все ушли.
Да и далеко не все упирается в сам код. Бывает неудачный дизайн, когда код красивый, но цепочки вызовов такие, что хочется застрелиться. Или поначитавшись паттернов лепят фабрики, стратегии, бездумно отделяют интерфейсы от реализации.
Попробуйте для интереса разобраться в коде, который работает в высокопроизводительных системах.
Кстати сказать, Роберт сам говорит что документация к API это хорошо и с таким кодом приятно работать.
Проглядывая быстро некоторые главы почитаю.
Возможно у вас мало опыта и не попадались такие случаи, когда код понятный и хороший, а вот почему сделано именно так, непонятно. Код не объясняет бизнес особенностей, он всего лишь отражает некоторую бизнес модель.
А иногда очень хочется знать почему сделано именно так, а не иначе.
Самый ппц это когда получаешь код проекта, программисты которого уже все ушли.
Да и далеко не все упирается в сам код. Бывает неудачный дизайн, когда код красивый, но цепочки вызовов такие, что хочется застрелиться. Или поначитавшись паттернов лепят фабрики, стратегии, бездумно отделяют интерфейсы от реализации.
Попробуйте для интереса разобраться в коде, который работает в высокопроизводительных системах.
1)Код не обязан и не должен содержать комментарии, которые относятся к бизнес-требованиям, для этого есть ТЗ и прочая документация. Если ее нет, необходимо ее написать, опять же не в коде. Код, а вернее его сущности(классы, методы и пр.) должны только отражать требования из документации
2)
3)по высокопроизводительным системам — тут должен быть у разработчика бекграунд, т.е. оптимизации и т.п. в коде должны быть понятны. Если вы их не понимаете, уточните или изучите. Если вы считаете, что они неуместны, а выяснить, почему так сделали — нет возможности, поменяйте на свою и убедитесь в правильности своего решения(также используйте п.2). Представьте, что каждая оптимизация/реализация, которые разбросаны по всему проекту и имеют один и тот же тип, будет иметь комментарий с пояснением. Подумайте, насколько код будет замусорен только ради того, чтобы новые разработчики, которые не владеют знаниями, загрязняли код еще больше, вместо того, чтобы учиться
2)
А иногда очень хочется знать почему сделано именно так, а не иначе— если реализация потребовала не столь очевидного решения, то это должно быть отражено в виде заметки как минимум, возможно в той же системе, где и документация по п.1, в крайнем случае как комментарий к классу/модулю, но это не должно быть повсеместно, иначе вы придете к тому, что у вас плохой дизайн
3)по высокопроизводительным системам — тут должен быть у разработчика бекграунд, т.е. оптимизации и т.п. в коде должны быть понятны. Если вы их не понимаете, уточните или изучите. Если вы считаете, что они неуместны, а выяснить, почему так сделали — нет возможности, поменяйте на свою и убедитесь в правильности своего решения(также используйте п.2). Представьте, что каждая оптимизация/реализация, которые разбросаны по всему проекту и имеют один и тот же тип, будет иметь комментарий с пояснением. Подумайте, насколько код будет замусорен только ради того, чтобы новые разработчики, которые не владеют знаниями, загрязняли код еще больше, вместо того, чтобы учиться
1) Чем больше информации о бизнесе (предметной области) в коде и комментариях к нему, тем лучше. В идеале вся информация о бизнес-требованиях должна быть в коде, с генерируемыми по нему представлениями для бизнеса или представленная в коде в виде непосредственно понятным бизнесу. Код тестов приравнивается к основному коду. ТЗ может не быть в принципе в используемых методологиях разработки.
Код тестов приравнивается к основному коду— ага, это типичное заблуждение, согласен с вами(хотя вы так не считаете)
Что-то мне подсказывает, что вы смешиваете мух с котлетами, приравнивая методологии разработки с бизнес-требованиями. Вы уж определитесь для себя, что вы хотите, быть заказчиком и исполнителем в одном лице или все — таки быть разработчиком, код которого потом не «пахнет». Бизнесу по барабану на ваш код и методологии, ему важно, чтобы приложение работало и приносило деньги
Ну так бизнесу должно быть и всё равно где и как я фиксирую его требования, если он может:
а) ознакомиться с тем, что именно я счёл его требованиями
б) проверить, что они исполняются
Тесты типа формализованных User Story с использованием какого-то DSL в этом отношении практически идеальны. Бизнес может ознакомиться с ними непосредственно в коде или через более удобное автоматически сгенерированное по коду описанием через, например, веб-морду. И может как довериться результатам автоматического тестирования, так и вручную пройтись по шагам сценария на, например, стейдж-среде, а то и прод.
Чем функциональные тесты хуже функциональной части ТЗ?
Ну так бизнесу должно быть и всё равно где и как я фиксирую его требования— да, так и должно быть в идеале, главное, чтобы для него это было понятно и удобно
Чем функциональные тесты хуже функциональной части ТЗ?— А кто сказал, что они хуже? Тесты могут описывать ТЗ и требования в целом, но не кодовую базу, используемые технологии, ЯП и прочие низкоуровневые вещи с точки зрения бизнеса
Не только бизнесу должно быть понятно и удобно, но и разработчику. Более того, между "удобно бизнесу" и "понятно разработчику" однозначный выбор в пользу последнего. Ну или бизнес должен платить за перевод.
Функциональные тесты могут достаточно хорошо показывать используемые технологии, если не учитывать возможность того, что разработчик обернёт свои любимые технологии в технологии требуемые заказчиком. С другой стороны, если это вещи низкоуровневые, то какая бизнесу разница: "Бизнесу по барабану на ваш код и методологии, ему важно, чтобы приложение работало и приносило деньги"
Всегда пишите код так, будто сопровождать его будет склонный к насилию психопат, который знает, где вы живете.
— Martin Golding
Ну, а это 1с, там это считается нормальным, так думают разработчики языка.
Камень в огород С/С++ скорее относится к «студенческим» работам, со всеми их прекрасными транслитами и прямым переносом формул в код.
Общее правило — имя переменной должно быть тем длиннее и подробнее чем шире область ее видимости.
Если это счетчик цикла или итератор, то он вполне может называться i, j,…
Чем короче имя переменной/функции, тем компактнее и проще для восприятия код.
Везде нужно соблюдать чувство меры и не впадать в крайности.
Общее правило — имя переменной должно быть тем длиннее и подробнее чем шире область ее видимости.
Если это счетчик цикла или итератор, то он вполне может называться i, j,…
Чем короче имя переменной/функции, тем компактнее и проще для восприятия код.
Везде нужно соблюдать чувство меры и не впадать в крайности.
Столько на эту тему тертоперетерто!
„Совершенный код“ Стива Макконнелла — почти 900 страниц обсуждалова! чуть ли не каждый год переиздается уже изданий 10 точно есть.
Все равно автору спасибо за статью!
„Совершенный код“ Стива Макконнелла — почти 900 страниц обсуждалова! чуть ли не каждый год переиздается уже изданий 10 точно есть.
Все равно автору спасибо за статью!
- Боритесь со сложностью
- Анализируйте процесс разработки
- Пишите программы в первую очередь для людей и лишь во вторую — компьютеров
- Программируйте с использованием языка, а не на языке
- Концентрируйте внимание с помощью соглашений
- Программируйте в терминах проблемной области
- Итерируйте, итерируйте и итерируйте
- И да отделена будет религия от разработки ПО
9. Верхние слои пишите для людей, а нижние для компьютера.
У меня стиль написания сильно улучшился когда стал покрывать юнит тестами.
Причём часто улучшения заметнее, если писать тесты до кода.
Это к принципам разработки… XP habrahabr.ru/post/197760
В экстремальном программировании роль тестирования интереснее: теперь вначале идет тест, а потом код.
Реально, сколько уже по этому поводу сказано, но все никак не могут понять: "самый лучший и чистый код — код, который еще не написан".
А вообще, все уже давно придумано, несколько непонятно, зачем это перефразировать каждый раз (DRY, KISS, YAGNI)
Такие дела
„Совершенный код“ Стива Макконнелла, который упоминали выше — могли бы уже вынести в обязательный перечень при приеме на работу, потому что видеть посты на хабре в которых так или иначе описанное им уже много лет назад… ну как то не весело уже...
Повторение — мать учения
Пока не ввели хотя бы иногда такие посты нужны, чтобы новички в профессии узнали об этой и подобных книгах.
Обратите внимание на кол-во комментариев к статье. Все ведь по делу написано, но никто из новичков не задает уточняющие вопросы. Они еще не понимают зачем это нужно. Зато с удовольствием посмакуют новый плагин к реакту. Так что формат статей нужно менять. Надо разжевывать зачем это нужно. Чтоб и школьнику стало понятно.
А может просто ушли читать книгу :)
Мне пришлось приложить не мало усилий, чтобы мои коллеги осознали, что надо учиться и начали хотя бы статьи читать. Мне повезло с техлидом. Обычно народ боится брать толстую книжку в руки ) А толковая литература обычно 300-1к страниц.
Так что сомневаюсь что они вот так сразу, не дочитав статью, а скорее всего они ее не дочитали, рванули читать что-то :)
Так что сомневаюсь что они вот так сразу, не дочитав статью, а скорее всего они ее не дочитали, рванули читать что-то :)
А чего тут разжевывать, в статье и вышеупомянутых книгах четко прослеживается мысль — все ради «передачи информации», причем быстро и понятно. Новички не задают вопросов и им действительно по боку на такого рода статьи, считая это водой, но и в школе/вузе мы много чего изучаем, тоже знаете ли не понимая, зачем это нужно, и только со временем к нам приходит это понимание. Так и тут, мне кажется базовые правила хорошего написания кода нужно прививать еще в школе на уроках информатики, а в вузе это уже должно быть must have
хз! Я вроде как в теме, но все равно себя новичком считаю. С тестами у меня все совсем плохо
Поддерживаю! Это как чистописание. Прописи для программистов.
Вот только у школ и вузов другая задача стоит.
Школы учат азам, там нет задачи из каждого сделать программиста.
А в вузах все всегда на одноразовых задачках. Преподаватели обычно горе-теоретики, так что скорее всего и код не читают. Главное чтоб работало. А это не способствует развитию хорошего стиля кода/архитектуры. Теоретически это можно автоматизировать сбором метрик, но кто там заморачиваться будет?
Та же ситуация в веб студиях — там проект делается левой ногой на выброс, никто там долго поддерживать его не собирается.
По этому там недостаточно боли от плохого кода. Тесты не пишутся. Призрак архитектуры унаследованный от фреймворка.
Только в компании разрабатывающей свой продукт или там где ценится качество(принципиально), люди могут дойти до осознания что надо что-то менять.
К сожалению, если это дойдет до одного, но он не сможет объяснить другим — все пропало.
Под разжевывать — я предлагаю рассказать про все эти принципы на примере рефакторинга какого-либо типового проекта. Но чтоб там изначально была боль, которую народ не понимает. Рассказать как это влияет на эволюцию проекта, с примерами, как это лечится. Пошагово, вводя принципы и практики по одной. Чтоб новички увидели что-то знакомое, поняли что не так с этим и научились как делать хорошо.
Желательно при этом сделать это на примере JS UI приложения. Ибо имхо это самый большой пласт начинающих разрабов.
Вот только у школ и вузов другая задача стоит.
Школы учат азам, там нет задачи из каждого сделать программиста.
А в вузах все всегда на одноразовых задачках. Преподаватели обычно горе-теоретики, так что скорее всего и код не читают. Главное чтоб работало. А это не способствует развитию хорошего стиля кода/архитектуры. Теоретически это можно автоматизировать сбором метрик, но кто там заморачиваться будет?
Та же ситуация в веб студиях — там проект делается левой ногой на выброс, никто там долго поддерживать его не собирается.
По этому там недостаточно боли от плохого кода. Тесты не пишутся. Призрак архитектуры унаследованный от фреймворка.
Только в компании разрабатывающей свой продукт или там где ценится качество(принципиально), люди могут дойти до осознания что надо что-то менять.
К сожалению, если это дойдет до одного, но он не сможет объяснить другим — все пропало.
Под разжевывать — я предлагаю рассказать про все эти принципы на примере рефакторинга какого-либо типового проекта. Но чтоб там изначально была боль, которую народ не понимает. Рассказать как это влияет на эволюцию проекта, с примерами, как это лечится. Пошагово, вводя принципы и практики по одной. Чтоб новички увидели что-то знакомое, поняли что не так с этим и научились как делать хорошо.
Желательно при этом сделать это на примере JS UI приложения. Ибо имхо это самый большой пласт начинающих разрабов.
Но чтоб там изначально была боль, которую народ не понимает.
Надо строго обратное, чтобы изначально была боль, которую все понимают.
Тех кто понимают, что в коде проблема — не надо уже учить, сами знают что делать. А те кого надо учить — не понимают, им надо показать и рассказать.
Перевести из «не осознанной некомпетентности» в «осознанную»
sergeykorol.ru/blog/competence
Перевести из «не осознанной некомпетентности» в «осознанную»
sergeykorol.ru/blog/competence
чтобы боль приносила пользу, она должна быть у человека лично. чужая боль — не более, чем буквы в учебнике…
Может нужно бороться не с проявлениями, а с причинами?
8. Многие из вас знакомы с достоинствами программиста. Их всего три, и разумеется это: лень, нетерпеливость и гордыня.Из "50 цитат о программировании всех времён"
— Larry Wall
И не забывайте! Совершенный код нужен только программистам, пользователям нужны работающие программы. Эти вещи связаны… как бы это вам сказать… опосредовано.
Пользователям часто нужно ещё и чтобы их "хотелки" воплощались быстро и дешево. А вот тут уже связь не столь опосредованная.
Да что уж там говорить. Иногда удается высунуть голову из безумного потока требований и фичреквестов, вдохнув освежающего рефакторинга, и как-то легче становится. А иногда не удается и приходится затыкать каждую дырку с помощью QA в этом бесконечном дуршлаге дендро-фекальной архитектуры. Так для меня выглядят реальные продукты, которые работают «сейчас», а не «завтра», поскольку для бизнеса «завтра» — это поздно. И дело не в том, что программисты делают что-то не так, дело в том, что хороший бизнес умеет их настолько загрузить, чтобы, с одной стороны, не сломались, а с другой — не углублялись там в свои рефакторинги и архитектуры. Потому что это не понятно бизнесу. Бизнесу нужны фичи.
Я часто думаю о том почему построение ПО не похоже на построение зданий. Наверное, отчасти проблема в том, что заказчики хотят дворец, а платят как гастарбейтерам за постройку, простите, сортира в огороде. И сроки соответствующие. Что ж потом удивляться если их дворец похож на тот самый клозет.
Здесь играет большую роль нелинейность. Если хороший каменщик может класть кирпичи в два, три раза быстрее (ровнее, крепче) в сравнении с обычным, то у программистов это может быть 10x, 100x, 1000000x (если вдруг есть готовое решение). Некоторые программисты тянут в одного то, что десятилетиями делают огромные команды (не миф, я реально такое видел). И здесь очень легко ошибиться в выборе. Ну а некоторые сами виноваты. Однажды мне предложили вакансию в одном стартапе. Задачи были сложные, но опыт у меня релевантный был. Я назвал величину ожидаемой заработной платы, на что получил ответ: да я за эти деньги найму пять индусов, они мне все сделают. Я пожелал удачи.
Главное в написании чистого кода — желание разработчика писать чистый код. Знаю много людей, которые сами могут все эти принципы перечислить, но пишут ужасный код.
Sign up to leave a comment.
Как писать чистый и красивый код