

Чем занимаются кодеры?
#1
Отправлено 21 December 2016 - 18:49
#6
Отправлено 21 December 2016 - 19:26
VovakaShashlik (21 December 2016 - 18:49) писал:
Кодеры закодили нормальную систему крафта? Ха-ха.
А зависаний нет уже года два, проблема в тебе.
"[usr] весь такой кодер."
#7
Отправлено 21 December 2016 - 19:34
VovakaShashlik (21 December 2016 - 18:49) писал:
Код те в жопу, пару раз проверни, да стартуй кодить сам.
Пиздеть не мешки ворочать.
VovakaShashlik (21 December 2016 - 18:49) писал:
Уж лучше хоть что-то делать через жопу, чем вообще ничего.
Цитата
dm-startup.sh - для удобного запуска билдосиков
#9
Отправлено 21 December 2016 - 20:20
Написать действительно работающий код, без багов, тупо сложнее. На это нужно тупо больше усилий.
Эта сложность множится на хуевую IDE, фактическое отсутствие модульных тестов, динамическую типизацию, огромную хуевую кодовою базу ссочки.
Вот и получается, что запилить несломанную фичу в разы сложнее, чем просто запилить фичу.
Я бы сказал, что кодеры сс еще неплохо справляются в этих тяжелых условиях.
#10
Отправлено 21 December 2016 - 20:37
Цитата
Остальные случаи как правило уже дань кривожопости конкретного кодера и помочь этому может лишь огонь.
#11
Отправлено 21 December 2016 - 20:57
24twelve (21 December 2016 - 20:20) писал:
Эта сложность множится на хуевую IDE, фактическое отсутствие модульных тестов, динамическую типизацию, огромную хуевую кодовою базу ссочки.
Если руки из жопы - вали все на ИДЕ.
"[usr] весь такой кодер."
#12
Отправлено 21 December 2016 - 21:19
24twelve (21 December 2016 - 20:20) писал:
Написать действительно работающий код, без багов, тупо сложнее. На это нужно тупо больше усилий.
Эта сложность множится на хуевую IDE, фактическое отсутствие модульных тестов, динамическую типизацию, огромную хуевую кодовою базу ссочки.
Вот и получается, что запилить несломанную фичу в разы сложнее, чем просто запилить фичу.
Я бы сказал, что кодеры сс еще неплохо справляются в этих тяжелых условиях.
#13
Отправлено 21 December 2016 - 22:41
ucnaHez (21 December 2016 - 20:57) писал:
Neray (21 December 2016 - 20:37) писал:
Остальные случаи как правило уже дань кривожопости конкретного кодера и помочь этому может лишь огонь.
#14
Отправлено 21 December 2016 - 23:01
Neray (21 December 2016 - 20:37) писал:
Ты делал хоть что-нибудь в коде станции сложнее правки опечаток? Если бы ты пытался ингейм проверить все, на что могла повлиять твоя правка, ты бы не говорил таких глупостей. Ты бы знал, что это нереально сделать за разумное время.
Ты, вроде, айтишник? Про Pairwise testing знаешь? Под это дело разработана и как-то доказана теория, что 95% отказов ПО - это следствия single-mode и double-mode дефектов. Дефектов, которые порождены одной или двумя ошибками разработчика. Т.е. если в твоем коде не находят single-mode дефектов, то ты уже поймал почти все баги.
Посмотрим на код тг, например. На первой странице багтрекера тг я не увидел ни одного single-mode бага (кроме нескольких рантаймов на карте). Это может говорить о том, что тгшники в большинстве своем хотя бы по минимуму тестируют свои правки.
Neray (21 December 2016 - 20:37) писал:
#15
Отправлено 22 December 2016 - 03:38
24twelve (21 December 2016 - 23:01) писал:
Ты делаешь некую фичу, ну не знаю, допустим учишь космонавтиков ползать. Ты перепроверил код на банальные рантаймы и очипятки, устаревшее взаимодействие с другим кодом, всё запустилось. Затем (если ты нормальный человек который кодит и для себя тоже, а не просто на отвалите) ты самостоятельно пробегаешь всё это как тестировщик. Лезешь в неочевидные ситуации, тыкаешь всё подряд. И вот только когда сделал всё это - отдаёшь миру. Быстрофиксы, к слову, тоже не считаются.
У меня горит, что народ даже в плане маппинга страдает той же хуйнёй. Месяц переделывают кусок карты, а в итоге неправильно метят апц, не меняют направления труб, забывают убрать космос из под дверей - и прочие очевидные штуки которые обнаруживаются буквально ОДНИМ тестом. И да, ТГшники тоже этим страдают, просто их много (aka у них по сути есть команда для бетатеста обновления на любой случай) и обычно кто-нибудь один да находит ошибки.
#горящийлюбительтестировки
P.S. Всегда остаётся вариант, что человек всё вышеописанное сделал, но всё равно не нашёл очевидные баги. Тут уж либо баги не такие очевидные как кажется, либо человек просто глупенький. В случае с ССочкой - чаще всего второе.
#16
Отправлено 22 December 2016 - 03:40
1. Отсутствие продвинутых возможностей, вроде хотя бы функций высшего порядка, ебучих пространств имен и вообще какой-либо группировки функций, не привязанных к объекту. Не, вызывать какие-то функции непрямо можно через call, но эта возможность сделана через лютейшую жопу. Я не могу вложенные функции объявлять также. Может я и ФП-ёб, но эти возможности есть уже в большинстве стандартных языков. Вложенные функций также нет.
2. Уебанский IDE, представляющий из себя в буквальном смысле блокнот с небольшой подсветкой синтаксиса.
3. Уебищнейший сборщик. Точнее его принципиальное отсутствие. Даже небольшое изменение в коде требует ПОЛНОЙ РЕКОМПИЛЯЦИИ всего проекта и это просто невероятнейше сильно замедляют разработку и тестирование. Эта проблема является, пожалуй, наиболее острой.
4. Практически полное отсутствие каких-либо тулз для отладки кода. Запустить какой-то код "по отдельности" и просмотреть его выполнение пошагово просто невозможно. Вкупе с 3 проблемой это означает, что отладка будет настоящим адом.
5. Отсутствие какой-либо модульности. Хотя с другой стороны кодинг бы был в миллион раз веселее, если бы она была при тех средствах, которые есть сейчас.
Я уже представляю себе этот макросный ад.
[специфичная проблема] 6. Отсутствие доступа к ядру. Все вещи приходится каким-то образом создавать используя только те средства, которые ядро бъонда тебе дало и совершенно невозможно как-либо на него влиять. Давно бы уже букву я пофиксили, если бы такой доступ был. Или создали в ядре некоторые функции, которые бы позволили распараллелить расчеты в атмосе.
Все вместе это образует самую главную проблему всего кодинга для ДМ: то, что тебе постоянно необходимо изобретать ебаные велосипеды. Велосипеды достаточно сложные для понимания (отсутствие каких-либо продвинутых средств), занимающие очень много времени чтобы их отладить (3&4) и занимающие прилично времени на то, чтобы их даже написать (2)
Ну и принципиальная проблема ООП в целом: при отладке необходимо учитывать очень много внешних параметров, которые могут влиять на поведение объекта. И изолировать объект легко также невозможно.
#17
Отправлено 22 December 2016 - 03:49
Цитата
Если брать мой пример с ползанием - ну допустим он забыл, что по тайлам космоса ползать нельзя. Или не добавил проверку на стэйт моба на пути, из-за чего ползать по тайлу где кто-то лежит невозможно.
Цитата
#18
Отправлено 22 December 2016 - 08:23
Neray (22 December 2016 - 03:38) писал:
Например, каким тестированием ты бы нашел вот такое?

Editor TEH Chaos-neutral (22 December 2016 - 03:40) писал:
#19
Отправлено 22 December 2016 - 08:25
Цитата
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных