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