Чем старше разработчик, тем больше комментариев
Телеграмм: IT Папа
Телеграмм: IT Папа
Комменты всё равно нужны. Почему именно такое решение выбрано, какие еще были альтернативы, на чём это всё базируется и т.д. и т.п. Т.е. комментарии вида ни что написано, а почему именно так, а не иначе, какой алгоритм используется и т.д.
Плюс бывает достаточно сложная бизнес-логика (или асинхронная логика, параллельные вычисления), которую лучше где-нибудь высокоуровневно описать, чтобы следующий человек (или ты сам) не ходил потом по куче "самозадокументированных" переменных/методов, пытаясь понять, как это всё работает.
Мне, например, в постгрессе нравятся комменты. Там они так норм написаны, что понятно, что, где и зачем, хотя сам код тоже написан по-человечески с нормальным неймингом.
А это уже не коменты, а документация. И вот про нее как раз мемчик в тему. Я сам ее пишу и наверное один из пары сотен в компании поддерживаю актуальность, потому что хз когда склероз нападет)
Нет, речь именно о подробных комментариях в самом коде - в блоках, в описании методов и классов. Это сильно ускоряет элементарное чтение кода, причём даже самим программистом.
Хотя конечно, существуют проекты и участки кода, где всё максимально просто и стандартно, там комментарии могут быть даже лишними.
Это сильно ускоряет элементарное чтение кода, причём даже самим программистом
Если код нельзя написать читаемым без портянки комментов, это говно а не код. Еще больше воняет от архитектуры, где нельзя разбить на читаемые без поллитры методы и классы. Есть исключения типа todo комментов или блоков документации (например javadoc), но они то как раз по ситуации используются.
Читабельный код нужно писать в любом случае. Но если комментарии позволяют ускорить чтение хотя бы в 2 раза - их стоит написать.
Кроме того, всегда возможны неясные на первый (и на второй) взгляд моменты. Не потому, что код плохой, а потому что бизнес логика сложная (если даже в ТЗ она расписывается на полстраницы с 1-2 примерами). Поэтому для максимального упрощения жизни читающему смысл действия дублируется в комментарии.
Никогда бизнес логика не пишется в коментах. Она пишется в документации. И на это есть сразу несколько причин:
1. Ее часто пишет аналитик или продакт, который ваще не должен иметь доступ к коду
2. Она не вмещается в конкретный метод или класс
3. Она может меняться и код может меняться и хрен кто все это обновлять будет вовремя, из-за чего получим что по коду одно, а по комменту другое
Я говорю о той части описания бизнес логики, которая дублируется в код.
Впрочем, возможно мой опыт разработки не совпадает с Вашим. Я лично пришёл к абсолютной необходимости комментирования кода, хоть и не сразу. Если что, опыт разработки и код-ревью 10+ лет.
Во многих популярных опенсорс проектах наблюдаю то же самое - комментарии присутствуют, иногда весьма подробные.
Сколько лет работаю, столько лет слушаю от коллег про самодокументируемый код. Ни разу у коллег его не встретил, впрочем.
Так в clean code про него написано же. Посоветуйте коллегам прочитать, и себе и им жизнь облегчите
Самодокументируемый код -- это код со встроенным ChatGPT ?
Ибо код, как вариант, не покажет о намерениях разработчика для чего этот код был написан
Работать надо так, чтобы было не стыдно уволиться одним днем. А если ты пишешь так что никто кроме тебя не поймет код, то тебя скорее всего и не уволят, а вот на новую работу точно не сгодишься. Я не про тебя или кого-то лично, а в целом по больнице хорошо увидел за последний год, когда такие старпеды стали разбегаться с нагретых мест, по резюме там все синьоры-помидоры, а на деле одни жсоны перекладывали.
Я честно говоря, уже давным давно перестал понимать что это за код такой, который кроме тебя никто не понимает.
Есть миллиард различных парадигм типа MVC, принципов типа SOLID, фреймворков, не дающих тебе выстрелить в колено, и подходов к организации типа Code Review, и тебе нужно действительно нужно постараться, чтобы написать кривой код в проекте, который эти подходы поддерживает.
А если сам проект написан так, что не запрещает, или ещё хуже вынуждает тебя писать говно, так это проект говно, а не ты как программист.
Ты конечно тоже так себе, раз не пытаешься сделать лучше, но принцип: "всратокод порождает всратокод" не позволит тебе писать хорошо, если всё вокруг тебя будет против
Это все красиво в теории, а на практике приходит продакт и хочет хуяк-в-продакш и вчера. Написать сразу и правильно могут не только лишь все, а на рефакторинг времени могут и зажопить. И тимлид если тряпка, то под продакта прогнется, так что все эти ваши модные паттерны только в книжках и останутся.
То есть чтобы не писать неподдерживаемый говнокод, нужно иметь не только хард скиллы, но и хард яйца. А это не в каждой конторе позволят.
А если сам проект написан так, что не запрещает, или ещё хуже вынуждает тебя писать говно, так это проект говно, а не ты как программист.
Плюс многа. Только проект -> компания.
Ну тут только посочувствовать. В нормальной-то конторе просто ревью не пройдёт такой код да и всё.
Да и «ещё вчера» не заставят делать, а поинтересуются, сколько времени потребуется.
Вот тут-то и сместился акцент. Написать читаемый код - просто, для этого комментарии к коду не нужны. Забрасывай код в методы и классы с читаемыми названиями, не используй переменные из одной буквы и всего делов. Заебок, если на code smell будешь проверять, но и так уже норм.
Написать расширяемый код - сложно, для этого нужен расширяемый проект в целом, который не будет вставлять тебе палки в колёса на каждой итерации процесса
То есть чтобы не писать неподдерживаемый говнокод, нужно иметь не только хард скиллы, но и хард яйца. А это не в каждой конторе позволят.
Поэтому я теперь прямо на собесах говорю, что хочу чистый код. И отказываюсь от предложения, если его в проекте нет.
Поэтому я теперь прямо на собесах говорю, что хочу чистый код. И отказываюсь от предложения, если его в проекте нет.
И много кто показывает NDA-шный код?
А что мне даст кусок кода на собеседовании? Может он у них такой один из всего проекта? =)
Всегда есть испытательный срок. На собесе верю на слово и задаю много вопросов, знание ревьюера Солида и правильные вопросы от него могут много сказать об отношении в компании к коду
тебе нужно действительно нужно постараться, чтобы написать кривой код в проекте, который эти подходы поддерживаетпроект может быть весь обмазан solidолом, но это никак не повлияет на твой говнокод. единственно, что влияет - это ревью, на котором этот говнокод завернут. всё.
Очевидно, что отсутствие контроля тимлида или самого разработчика за тем, что ты пишешь может привести к плохому коду, что тут спорить-то? Сломать можно всё что угодно.
Я же не утверждаю, что невозможно всратокодить в принципе.
а потом вспоминаешь, что сидишь безработный и дальше свой пет-проект ваяешь... Вот кто глянет на репозиторий на Github, удивлятся!
эх, надо бы вырваться из эникеев в нормальные люди.
Жаль, не могу никак найти инфы что там по следующим проблемам, что будет в 2023-2024, мало ли, вдруг на гос.предприятии будет элементарно надежнее -- бронь, стабильная з/п и вот это вот все. Хотя зп копеечная, в районе 20к, без перспектив к росту...
вроде, на том же C# бэкенд, по слухам, предлагают 30-40к джунам, а мидлам и по 100к отсыпать могут
Изучив немного глубже кроличью нору, увидел, как много проектов очень сильно не хватает чисто для разработки.
Хоть свою CRM писать, с кроссплатформенностью и википедией, а также IDE для прототипирования, ибо те, что есть -- как будто только для девочек-манагеров сделаны клиентов хомутать и в воронку продаж запихивать, на этом полномочия CRM все.
Постановка задач от клиентов через CRM? Не, смотрите 100500 сторонних инструментов, которые между собой интегрируются больше, чем никак.
Хотя да, я тут уже и на ERP замахнулся, и на некоторые другие вещи.
Ибо существующие IDE, вики-движки, системы документирования, мессенджеры, CRM, некоторые ERP и т.д. -- сильно урезаны по функционалу. Соответственно, думаю позаписывать все свои идеи и будет как раз roadmap для разработки))
Но пока вся эта гиганская махина не очень удобна для монетизации на ранних этапах, соответственно, подумываю о мобильной разработке вплоть до текстовых квестов, чтобы хоть какую-нибудь копеечку получать да свои скилы проверить.
Когда-то уже делал для себя игру на развитие интуиции, сейчас как раз есть повод портировать на андроид, накинуть гигатонны графики, а также сделать альтернативный геймплей на развитие, например, музыкального слуха. Помню, что на развитие интуиции в стиле -- есть несколько плит, нужно угадать правильную, неправильная ведет на штрафную территорию, правильная ведет в бонусную комнату.
Делал еще, наверное, в школе, давно было, не помню. Ей лет 15, наверное, для винды.
вроде, на том же C# бэкенд, по слухам, предлагают 30-40к джунам
Не обманывайте себя, 30 тысяч предлагают только мошенники, даже не пишите им никогда. Нормальные конторы начинают от 70 тысяч минимум за джуна.
Я не шучу.
Хоть свою CRM писать, с кроссплатформенностью и википедией
У меня есть своя црм, purecrm.ru, поверьте одному вытянуть свою црмку очень тяжело, нужно прям много опыта, прям тимлидерского.
Когда-то уже делал для себя игру на развитие интуиции, сейчас как раз есть повод портировать на андроид, накинуть гигатонны графики, а также сделать альтернативный геймплей на развитие, например, музыкального слуха.
Вариант заебок, но в мобильной разработке готовьтесь к горению жопы, новичкам в андроид вкатиться очень нелегко, там ну вообще все неочевидно.
Самый кайф - php и питон, для входа они идеальны, и работа всегда найдётся.
По поводу зарплаты:
Бесит пиздец, если пощелкать озвучки можно найти без этой хуйни, но с каждым сериалом все сложнее. Там ещё кнопка есть "другой плеер".
Источники видео не мои, мой только сам сайт. Я хотел в сайт встроить адблок, чтобы хотя бы прероллы блокировать автоматически, но все плееры на айфреймах, не подлезешь.
Таков наш ебаный мир, везде реклама. Даже на своём, блять, сайте.
public int setRegion
public void setRegionAndCheckResult
public boolean isRegionAsExpected
- не надо писать комменты
- можно генерить документацию из кода
- могут читать джуны
А если еще в logger.log умеешь, то тогда твои комменты уже лишние и будут выпилены на любом вменяемом ревью
> setRegionAndCheckResult
Плохой метод, делает больше чем одну вещь. Дядюшка Боб не одобряет)
Можно разделить на два, да. Но если эта идиома повторяется сто раз в проекте и ни разу эти два метода по-отдельности не применяются, и тем более - в силу причин безопасности - их применение по раздельности не допускается? Разделите вы, допустим, а как прогарантируете, что setRegion никто не вызовет без последовавшего вызова checkResilt?
Странно вообще, если обе версии торчат наружу на одном слое.
Как минимум, можно разделить соглашением:
set* - "низкоуровневые" сеттеры
update* - бизнесовые методы
Если это в игре, то придется уточнять даже регион -- регион на большой карте, на миникарте, регион для триггера, регион (ореол) обитания НПС, животных, область в таблице, область на интерактивной карте (планшет в игре), регион для коллизий, регион для босса и т.д.
И из-за этого приходится писать в стиле названий японских аниме "Эта переменная была создана для полиморфизма босса в зависимости от локации, а так босс в остальной игре дружлюбный НПС, которого нужно защищать, иначе игра закочится".getStatus()
Это не в игре, это методы в классе. Когда они все названы так же вменяемо, то и понимаешь что, где и почему. И да, это простой пример, можно открыть гитхаб и посмотреть что поумнее.
Только вместе с классами нужно прописывать еще длинную цепочку какой класс куда вложен, ибо namespaces.
В Java, C#, 1C и куче других языков это вместе с ООП порождают длинные названия до каждого объекта. Типа:
app->module->window->object->canvas->brush->color = #00FF00
Да, мы можем в рамках модуля убрать упоминание программы, модуля и даже окна, если это в рамках одного окна, но вот остальные объекты будут иметь имена намного более длинные, особенно название Object.
И если канва -- это еще более-менее распространенный объект и можно сократить, то коллекции объектов запросто будут именоваться из 3-4 слов, чтобы хотя бы приблизительно понимать о чем идет речь.
Они укорачиваются импортами и алиасами. Т.е. однажды в файле написал, потом много раз используешь короткое и однозначное имя.порождают длинные названия до каждого объекта
коллекции объектов запросто будут именоваться из 3-4 слов, чтобы хотя бы приблизительно понимать о чем идет речь.
3-4 слова - вполне нормально и читаемо, не вижу проблемы. О чем речь - рассказывает сам тип коллекции и остальной контекст. Если этого мало - заводится тип-обертка с говорящим именем.
IT-юмор
5.6K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору