Пффф, раньше думал что переписывать чужой код сложно. НО НО потом пришлось работать с cms битриксом с чистой версией, еще не переписаной и скажу вам что лучше бы там кто то уже что то переписал, это какое то Г за 72 к )) Забавно думать что за такие деньги там должно быть все готово, но потом приходится нанимать программиста платить ему еще как за стоимость интернет магазина, очень экономная вещь
По хорошему, нужно писать код, который будет понятным без комментариев: называть переменные, сущности и их свойства так, чтобы имя отражало содержание. Имя методов - глаголом в повилительном наклонении, булевые переменные и свойства - в вопросительной форме, и так далее. Такой код можно читать, как осмысленный текст на человеческом языке, и с первого прочтения можно примерно понять, что там происходит.
Неа - нужно писать код что бы никто никогда его не понял, чем больше goto и меток, тем лучше, чем больше пустышек, которые нихуя не меняют, тем лучше - тебя уволят, а через неделю вернут с повышением зп
Использую goto для реализации фичи из JS
https://developer.mozilla.org/ru/docs/Web/JavaScript/Referen...
Нене, не так. Пишешь понятный код. Например, class User с методами setPassword и setEmail. Вроде все понятно, только User -> setPassword на самом деле например отвечает за вывод списка товаров, а setEmail - цену на конкретный товар. Ну и дальше в таком же стиле.
Ты-то привыкнешь (особенно если себе укромную сносочку сделаешь), а тот кто потом будет этот код читать, испытает дичайшую анальную боль.
Блядь, какая же я мразь.
Безусловный переход на заранее указанную точку кода из любого другого места программы. Очень запутывает логику и понимание программы или функции.
Отличие джампа - он переходит на указанную ячейку памяти. И в этой ячейке не обязательно может храниться кусок исполняемого байткода, это могут быть данные, которые интерпретируются процессором как инструкции, что приведет к непредсказуемым последствиям (гусары, молчать, я знаю про readable/executable)...
Согласен, но это только именование. Другое дело - вспомнить логику приложения, при этом всякие getProduct() или isValid не всегда помогают.
Да, соглашусь. Особенно в андроиде такая штука. Куча бродкастов, куча фрагментов, все это взаимодействует. Пока пишешь - помнишь. Прошел год - сам разбираешь свой код. То же самое с асинхронными запросами к сети - там гавкнул, в другом месте отлавливаешь и реагируешь. Пока всю цепочку не пройдешь - фиг вспомнишь.
SOLID решает описанную вами проблему. Если придерживаться этих принципов, то любое изменение системы потребует от вас работы только с ее малой изолированной частью, где разобраться будет просто. Знать, как работает остальная система, для решения задачи вам будет не обязательно.
Ну и конкретно в java лучше уж тесты писать вместо комментариев. По ним логику работы понять намного проще.
Это стандартная отговорка разработчиков от написания тестов: "я что, должен больше работать за те же деньги?". Если бы мне платили по доллару каждый раз, когда я это слышу, я бы уже купил бы одну из башен в москва-сити) Да я и сам так думал когда-то.
Но если опираться на статистику, то TDD при разумном применении сильно повышает качество кода, и сокращает затраты времени на его тестирование и поддержку. Так что в перспективе выигрывает от этого разработчик, так как он быстрее решает свои задачи, меньше косячит (привет, KPI), и у него остается время "для себя". Тут главное начать, потом втягиваешься. Главное - без фанатизма.
Я ж говорил про рефакторинг с нуля. Так-то да, когда тесты параллельно с кодом создаются, рефакторить потом проще.
Я самоучка. Все время работаю в маленькой команде. И часто жалею, что не поработал в фирмах побольше и не понял всю кухню изнутри.
А чем плох фреймворк андройда? Из плохого могу отметить только обилие херовых багов, по моему не особо богатому опыту.
Скорее солид плохо ложится именно на Java, так как ребята к восьмой версии, судя по всему, подзабыли, что такое ООП. Недавно начал один небольшой проектец под андроид, и, снова истекая кровью из глаз, решил попробовать котлин. Очень понравилось, рекомендую, и солид с ним отлично работает.
Я не знаю, не удаётся даже выделить одну главную проблему D:
Меня просто бесит ВСЁ, что связано с андроидом. Оно всё выглядит так, будто сделано за 20 минут перед дедлайном, а потом тщательно задокументировано, чтобы точно никогда это говно не исправили. Хз.
Простой пример - банальнейший системный TextView.java, например. В этом файле, мать его, 11 тысяч строк. Когда у текста включена прокрутка, TV создаёт внутри себя холст шириной 1024*1024 точек (это уже ппц из-за расхода памяти и потенциальных проблем отрисовки на устройствах с высокой плотностью точек). Когда у текста со включенной прокруткой выставлено выравнивание по правому краю, он рендерится с правой стороны холста, и TV появляется прокрученным до упора вправо. И ты уже не можешь переопределить onDraw и, например, нарисовать рамку вокруг текста, потому что он нарисован на этом холсте хер знает где. И - вишенка на торте - если сделать текстовое поле однострочным, то у него автоматически включается прокрутка, и начинается вот это вот всё. Просто минное поле из стрёмных побочных эффектов.
D:
А что не так с Java и с ООП?
Был в бане.
А что не так с Java и с ООП?
Например, штуки типа вложенных классов, как и анонимные реализации с полным доступом к this родителя, несколько нарушают принцип инкапсуляции, на мой взгляд. Понятно, что котлин - полностью транслируемый в Java язык, и там все это тоже имеет место, но он таки накладывает некоторые ограничения на разработчиков, снижая риск выстрела себе в ногу. Т.е. та же лямбда из котлина по сути - это та же анонимная имплементация, но она не дает разработчику надобавлять туда лишней логики, и поля в ней ограничены тем, что закапчурится из скоупа. Java выстрелы в ногу наоборот, поощряет, как мне кажется.
банальнейший системный TextView.java
Если говорить про 11 тысяч строк запутанного кода, то для решения этой проблемы отлично подходит паттерн "декоратор", позволяющий отделить платформозависимые детали реализации от основной логики приложения. Таким образом, при внесении изменений в логику приложения (происходит часто) не нужно вносить изменения в код взаимодействия с фреймворком (меняется редко), который условно работает, и трогать его рисково.
А баги и логические нестыковки фреймворка - это да, непредсказуемые сюрпризы каждый день. И в новых версиях их исправляется не намного больше, чем привносится.
Ну это уже вкусовщина, как по мне. Можно даже при сильном желании скастовать OuterClass.this в соответствующий интерфейс/класс и играться с ним, не трогая приватных кусочков, но особого смысла я в этом не вижу. Это такое, примерно как советы "не писать никогда this.data = data, тут очень легко ошибиться!". В реальности я всю жизнь сделал 2 таких ошибки. Удобство использования перекрывает возможные негативные эффекты.
А толку абстрагироваться от глючного кода, если менее глючным это его не сделает?
Сравни эти 2 файлика:
https://github.com/aosp-mirror/platform_frameworks_base/blob...
https://github.com/aosp-mirror/platform_frameworks_base/blob...
Разрабы андроида мало того что сделали горизонтальную прокрутку, тупо скопипастив код вертикальной в отдельный файл и пропатчив, так ещё и зеркальные изменения зачастую забывают вносить в один из них. Первая ошибка такого рода аж на первой строке после объявления класса находится.
Ну это уже вкусовщина, как по мне.
Это не вкусовщина, а ошибка проектирования. По сути, компьютер можно программировать как угодно, а принципы ООП, как и многие другие - это искусственно созданные для программистов ограничения, целью которых является повышение качества (условно, тестируемости) кода и упрощение его поддержки. Никто не заставляет программиста следовать этим принципам, но если уж начал - следуй им до конца, иначе смысл теряется.
Анонимные имплементации вложенные классы в Java, при их использовании "во зло", очевидно усложняют поддержку кода и снижают его тестируемость, так как снижают уровень изоляции между сущностями, т.е. нарушают принцип инкапсуляции. При этом фреймворки типа андройдовского никак не мешают программисту использовать их "во зло", иногда даже стимулируя его их так использовать, а значит программисты будут это делать постоянно, по моему опыту.
А толку абстрагироваться от глючного кода, если менее глючным это его не сделает?
Я же писал: смысл в том, чтобы отделить логику самого приложения от платформенных особенностей. Это позволяет не трогать платформозависимый код при внесении изменений в логику приложения, и не трогать логику, когда нужно внести изменения в механизм взаимодействия с платформой. Это и есть реализация SOLID, с которого начался наш разговор, а именно - принципа единой ответственности.
Если не абстрагироваться, то, условно говоря, у вас будет ваше "сраное глючное приложение". А если абстрагироваться - то будет ваше "охрененное надежное приложение" и "сраный глючный андройд".
Такая ситуация говорит о необходимости выполнить декомпозицию. Правило семи и все такое. И не нужно бояться трудоемкости такого процесса, как и неизбежной денормализации данных в результате, потому что человеческие ошибки, порождаемые работой с такой перегруженной сущностью, гарантированно обойдутся дороже. Проверенно на собственном опыте неоднократно.
Да, это пиздец. Хотя этот пример кода вообще никак не соответствует рекомендации, которую я дал выше. Скорее, он как раз подтверждает ее на примере "как неправильно".
Слишком простой вариант=). Это никогда не избавит от традиционного вопроса "нахуя". Старые добрые костыли, которые были вставлены давным давно, либо вообще другим разрабом, по только ему известной причине. И не дай боже ты решишь поиграть в умного и прочитав весь остальной код решить что это тут не нужно. С высокой вероятностью огребешь кучу проблем. В итоге в "прочтенном" коде остаются участки с темной магией.
Другой вариант старый проект со старыми уже не использующимися фреймворками. Даже если он красиво написан, не освежив память документацией по нему, трудно будет разобраться.
Опять же идеальный вариант. Хорошо, что ваш заказчик платит за рефакторинг уже рабочего кода , не у всех такие.
Рефакторинг - это работа, которая нужна разработчику, а не бизнесу, так что нет ничего удивительного, что бизнес за нее не платит. С точки зрения бизнеса, вы должны сразу писать идеальный код.
ls -hl /mnt/*/*.ru/$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -1 day")/ft-v0[57].$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -1 day").2300*|cut -d/ -f6 > /tmp/VarA
ls -hl /mnt/*/*.ru/$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -${tIme} day")/ft-v0[57].$(/usr/local/bin/date '+%Y-%m-%d' --date="(date) -${tIme} day").2300*|cut -d/ -f6 > /tmp/VarB
DiFF=`/usr/bin/diff /tmp/VarA /tmp/VarB|grep .ru`
echo $DiFF
Да прост нужно побольше методов и классов использовать. А то в одном классе в двух методах напишут 500+ строк кода и сиди ковыряй.
Ну дык. =) И это нормально - всё камментить ящитаю. ;)
Жопка потом спокойней, не пылает, аки Солнышко в небе ясном. ;)
"
Среди разработчиков системной библиотеки Glibc разгорелась дискуссия, которая привела к противостоянию между Ричардом Столлманом и сообществом и заставила задуматься над применяемыми в проекте методами управления и полномочиях по принятию решений.
Дискуссия началась с утверждения патча, удалившего из описания функции abort() шутку о том, что рассматриваемый правительством США законопроект о цензуре может трактовать информацию о данной функции как пропаганду абортов, поэтому пользователи должны иметь в виду, что функция abort() не является приемлемым способом преждевременного прерывания выполнения программы. Некоторые разработчики посчитали данную шутку излишне политизированной, засоряющей руководство и вызывающей негативные воспоминания у людей, которым пришлось столкнуться с проведением абортов.
В ответ в списке рассылки Glibc появился Ричард Столлман, который указал, что движение GNU не является чисто техническим проектом и попросил вернуть назад шутку, которую он добавил в 1990-х годах и считает вполне уместной и важной с идеологической точки зрения. Он заявил, что документация GNU, как курс по истории, не должна быть безопасным местом, а также в шутку предложил довести дело до абсурда и добавить предупреждение в текст о функциях создания дочерних процессов, так как роды могут быть гораздо более травматичны, чем аборты. Например, как неплохой вариант отмечено предупреждение "создание детей может занять до 9 месяцев и привести к исчерпанию всех ресурсов".
В конечном счёте, натолкнувшись на большое число возражений Столлман заявил, что как руководитель проекта GNU он отвечает за то, что публикуется в руководствах GNU, и он лично определяет критерии, на основании которых принимаются решения. Разработчики попытались возразить, что решения в Glibc в основном принимаются на основании консенсуса, на что Столлман указал, что Glibc не является независимым проектом, а представляет собой часть проекта GNU и официальные мэйнтейнеры утверждаются лично им.
В подавляющем большинстве случаев назначенные мэйнтейнеры сами принимают решения, связанные с их проектами, но иногда возникают исключения, которые заставляют Столлмана вмешиваться в процессы принятия решений. По сложившейся практике в Glibc возникла система принятия решений на основании достижения консенсуса между всеми участниками разработки, но некоторые концептуальные вопросы остаются прерогативой проекта GNU и не могут быть делегированы отдельным подпроектам. Именно таким является вопрос оставления шутки, привлекающей внимание к возможному усилению цензуры.
Торвальд Ригель (Torvald Riegel), один из мэйнтейнеров Glibc из компании Red Hat, входящий в комитеты ISO по стандартизации C++, указал, что пренебрежение коллегиальным мнением сообщества разработчиков является неплохим поводом для форка. Решение об удалении посторонней шутки, которая не имеет отношения к описанию работы функции abort(), было принято коллегиально большинством разработчиков, но Столлман отказался прислушаться к чужому мнению в пользу личных пристрастий.
Несколько мэйнтейнеров Glibc призвали не возвращать шутку пока продолжается обсуждение и не выработано общее соглашение. Тем не менее один из мэйнтейнеров (Alexandre Oliva), несмотря на то, что большинство разработчиков высказались против шутки, уже отменил удаление, сославшись на решение лидера проекта. В качестве компромисса, Столлман разрешил добавить примечание "Предупреждение от Столлмана"."
В документации к функции abort() - было шутливое примечание о том, что эта функция не является приемлемым способом преждевременного прерывания выполнения программы.
Собрались серьёзные дядьки и сказали, мол, хули это делает в нашей технической документации, мы тут чо, Петросяны? Ну и удалили это примечание.
Пришёл головный паерень, глянул на всё это и сказал:"Вы тут ёбу дали? Верните всё как было. Я это ещё в 1990 написал, когда вы титьку мамину смоктали! Мой проект не чисто технический, это вам не это!"
Ему ответили, мол:"Так-то это наша юрисдикция, пшёл отседава!".
На что он уместно возразил:"Псы позорные, берега попутали?! Так-то вы все под моим начало ходите и ваша компашка - это часть моей компашки".
Ребята поворчали, попричитали, мол, ты, конечно, прав, но как-то нехорошо же выходит...
На что головный пояснил им, что помимо этой шутки может добавить в текст хоть тысячу и один анекдот про их мамок.
Ну и под шумок, пара ведущих спецов вернули всё как было, дабы не нагнеть ситуацию, да и за мамок боязно.
Конец.
Разработчики выпили функцию abort(), потому что она оскорбляет чувства абортируемых, а биг-босс сказал верните обратно, идиоты. Они разосрались между собой, но abort() вернули
Всё осталось так, как было изначально :) Фактически, ничего не произошло, просто воздух посотрясали
Один из мейнтейнеров, несмотря на договоренность, по велению самого главного, который объяснил решение историческими причинами, вернул шутку в комментарии к функции abort() в документации, которую удалили другие мейнтейнеры, ошибочно посчитавшие, что имеют на это право и руководствующиеся нежеланием потенциальных проблем в связи с законом о цензуре.
Столлман создал проект и дал возможность другим поучаствовать. Эти другие охуели от ЧСВ и посылают Столлмана нахуй по некоторым вопросам. Столлман культурно напоминает, что вообще-то он владелец проекта и эти некоторые пидарасы и малость охуели, и вообще идите нахуй со своей толерантностью и политкорректностью.
На что эти другие угрожают, что скопируют весь проект и сделают свой проект с блэкджеком и шлюхами.
Иллюзия безопасности.
Проблема комментов в их устаревании, и далее отсутствие внятного источника правды.
Иногда даже стоит какой то кусок кода засунуть в новую функцию с именем, даже если она будет вызываться один раз чисто для повышения читаемости.
А вообще если код не понятен без комментариев, часто это признак, что его стоит переписать/зарефакторить, либо добавить еще один уровень абстракции.
Терпеть не могу вложения функций друг в друга, при том, что эти подфункции ничего по сути не делают.
Легче прочитать описание класса/функции/метода, чем пытаться по его названию и содержимому вдуплять что тут происходит, сколько бы ты красиво не писал
https://vk.com/wall-30666517_796260
На у серьезно - это считается хорошим показателем достижения своего личного барьера как программиста. Если ты читаешь свой код годичной давности, и у тебя не пригорает со словами "А это точно я писал это уебанство?!" - то ты достиг своего предела, и дальше не развиваешься.
S.O.L.I.D., K.I.S.S и другие принципы вам в помощь. Не брезгуем патернами и тогда код в 200 000 строк читается без комментариев. Проверенно на 8 проектах.
Не забываем о код ревью, статистический код анализ, юнит/интегрейшин/е2е тестах, этапах обязательного рефакторинга("рефакторинг с использованием шаблонов" в помощь), код гайдлайнах;)
И ещё меньше из них способны документировать код
IT-юмор
5.6K постов52.5K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору